[BlueLeaf1336]> PROBLEMS> なぁバーコードを読もうじゃないか>

なぁバーコードを読もうじゃないか > JANコード攻略

historyTOP

2005/04/03:作成
2005/04/04:続き
2005/04/05:続き

2005/04/03TOP

本の裏側のバーコードは、バーコードによると、「書籍コード」と呼ばれているようですが、実体は「EANコード」であり、日本国内では「JANコード」と呼ばれているということです。つまり、JANコードを読めるようになれば、本の裏側のバーコードが読めるようになります。ISBNや価格なども数値に変換した後で取得できるようですが、これは後回しにします。

さて、JANコード規格によると、JANコードには2種類あるようですが、本の裏のは(数えてみると)13桁の方です。構成は、こんなんです。

具体例がないと調べがたいので、ここでは、2004/03/14に700円で購入したまま、未だに読んでいない「ルー=ガルー ― 忌避すべき狼(Amazon.co.jp)」のバーコードを例にとって勉強してみます。

2つのバーコードがありますが、上側のバーコードを見てみます。数値としては、次のようなもので

9784198613648

MiBarcode(Windows95/98/Me/文書作成)で作ってみると、こうなります。わかりやすいように横3倍で作っています。

2005/04/04TOP

これを少しだけわかりやすいように加工したりしたものがコレです。別にわかり易くないですけど。

バーコード直下の数字は、黒を「1」で白を「0」で表現したものです。レフトガードバー(バーコードの左端/図ではLGと表記)とライトガードバー(バーコードの右端/図ではRGと表記)・それからセンターバー(左データキャラクタ6文字と右データキャラクタ5文字+チェックデジットを分割する真中線/図ではCBと表記)を除いて、各文字は、黒2本白2本あるいは一番左の黒バーの幅を1とした時の7本分で描かれているのがわかります。

あれ? よく数えてみると12文字しかないです。13文字じゃあねぇのか? と思ったりもしましたが、後で説明できるはずです。できなければ理解できていないということでこの図を作ったのも骨折りになります。

まずは、上手で区切ったそれぞれの内容から元の数字が復元できるかどうかをやってみます。対応する数字は、データキャラクタ対応表から探します。

位置バーの並びを数値化したもの対応する数字パリティの種類
LG101 (無/固定)レフトガードバー
L101110117左側のデータキャラクタ/奇数パリティ
L200010018左側のデータキャラクタ/偶数パリティ
L300111014左側のデータキャラクタ/偶数パリティ
L400110011左側のデータキャラクタ/奇数パリティ
L500101119左側のデータキャラクタ/偶数パリティ
L601101118左側のデータキャラクタ/奇数パリティ
CB01010 (無/固定)センターバー
R110100006右のデータキャラクタ
R211001101右のデータキャラクタ
R310000103右のデータキャラクタ
R410100006右のデータキャラクタ
R510111004右のデータキャラクタ
CD10010008モジュラチェックキャラクタ
RG101 (無/固定)ライトガードバー

ところで、左側のデータキャラクタ(L1~L6)までのパリティの種類を順に並べてみます。ここで、奇数はOddの「O」、偶数はEvenの「E」を使います。

奇偶偶奇偶奇 = OEEOEO

この並びを、プリフィックスキャラクタ対応表から探してみると、「9」が得られます。

結局、最後に得られた「9」を先頭に、LG/CB/RGを除いた13桁「9784198613648」がこのバーコードの現わす数字となって正しく元に戻せたことになります。長ぁ。

チェックキャラクタ(「9784198613648」の最後の「8」)については...置いときます。

メモ。

グラップルTOP

前回に引き続き、今回も完全に甘やかされた環境でバーコードを読み取れるものとします。具体的には、MiBarcodeが出力したバーコードを、背景まっ白な画像として保存したものを読む、という状態です。

さて、この画像を左端から攻めていくとき、まずはレフトガードバーに行き当たります。黒白黒の順で、このバーコードの基本となる1単位の幅をそれぞれ持っています。

レフトガードバーをすぎると左側の6文字のデータキャラクタ領域に突入します。データキャラクタ対応表をじーっと見てみると、左側6文字のバーコードは常に、パリティの種類に関わらず白で始まり黒で終わることがわかります。また1文字は黒2本白2本で構成されるので、つまるところ左に置いては、白黒白黒の並びであることが決まっています。

次にセンターバーが登場します。センターバーは、白黒白黒白と決まっています。

それから右側の5文字のデータキャラクタ領域となります。再びデータキャラクタ対応表をじーっと見てみると、右側5文字のバーコードとついでにモジュラチェックキャラクタは常に、黒で始まり白で終わることがわかります。左側のデータキャラクタとは逆ですが、これはセンターバーで白黒の調整が行なわれたのでうまくいくわけです。

そして最後に、ライトガードバーの黒白黒で終わります。

整理してみると

位置黒と白の並び方
LG黒白黒
L1白黒白黒
L2白黒白黒
L3白黒白黒
L4白黒白黒
L5白黒白黒
L6白黒白黒
CB白黒白黒白
R1黒白黒白
R2黒白黒白
R3黒白黒白
R4黒白黒白
R5黒白黒白
CD黒白黒白
RG黒白黒

何故こんな表まで作ったのか今となっては不明ですが、いいたいのは「2つの文字のバーがくっついてひとつのバーに見えることはない」ということだけです。JANコードにはキャラクタ間ギャップ(文字と文字の間の隙間)がないということなので、普通にあるんだろうなぁと思ってたんですが、ないというわけです。

なので、良い方法かどうかについては異常に疑問が残りますが、CODE-39の時のように、黒白の連続状況を数えておいて...という方法をとることができます。黒が10個連続している時に、実は最初の4個は1文字目で後の6つは2文字目のデータを表している、ということがないのでこういう手段を取れることになります。また、個数だけを記録していくだけで黒か白かはあえて覚えておく必要もありません。何番目かということさえわかっていれば、黒と白が交互に出てくるので自然と黒なのか白なのかを決めることができます。

ところで、黒のバーや白の隙間の幅というか広さには、4種類あります。CODE-39では広いか狭いかの2種類でしたが、JANコードではこれが4種類になります。レフトガードバーの1本目の幅を1単位として、1単位・2単位・3単位・4単位の4種類です。それぞれを単純に1,2,3,4と表現することにするとデータキャラクタ対応表を次のように書き換えることができます。(意味があるかどうかは別にして)

10進数左側のデータキャラクタ(白黒白黒)右側のデータキャ
ラクタ及びモジュ
ラチェックキャラ
クタ(黒白黒白)
奇数パリティ偶数パリティ
0321111233211
1222112222221
2212222122122
3141111411411
4113223111132
5123113211231
6111441111114
7131221311312
8121331211213
9311221133112

黒と白を区別しなくなったことで、左側と右側のデータキャラクタを区別せず扱えるようになりました。

攻略?TOP

いろいろあって、こんなんできました。なにやらここまでの説明も微妙に不足気味です。でももうアレです。

もう本当に反省しまくりの解析処理です。絶対に書き直しが必要ですが、でも、動いてます。公開というよりもローカルから間違って削除してしまった時のバックアップ用に、ここに置きます。置き場です。

で、実行ファイルとソースコードです。テストに使用したバーコード画像も同梱しています。CODE39とJANを読んだり読まなかったりします。少しだけ楽しいです。結果は画面右下に無理やり表示しています。ちゃんと一致しているように見えます。

20050405NaBaRead.zip(292,265bytes)(7,432bytes)

おまけTOP

こんなサイトがありました。

おそらくテスト用のページだと思いますが、Amazon Webサービスを利用した検索を体験することができます。意外と「バーコード 検索 書籍」というキーワードを使用すると大量のページが引っかかります。

その前にビデオカメラか何かの画像を取り込みたいんですが...そっちが問題。

EOFTOP