UPC-Aに関するトラブルレポート
テクノベインズ株式会社
１９９９年１２月２８日
UPC-Aを使用して、特定なデータ（本来目的である正しいUPC−Aのデータでない）について作成されたバーコードラベルを、バーコードスキャナで読み込んだ際、読み込みの仕方によっては誤ったコードを出力を発生する場合があります。
問題を起こすケース例
UPC-A 000000000062 のバーコード（最後の２はチェックコード）UPC-Aは米国における流通商品を管理する事を目的として開発されたコードです。UPCの規格により、コードパターンの先頭部分には企業コードが入るように規定されています。コードの割付仕様を満たしたUPCの場合、先頭がすべて０になるようなコード体系はUPC-Aには存在しません。
しかし、バーコード作成プログラムなどにより、UPC-Aコードを使用してオリジナルなバーコードを作成することは可能です。その場合、以下のような問題点が発生する場合があります。
問題点
上記の値のバーコードを作成し、バーコードスキャナで読み込むと、JAN-8（EAN-8）の00000000データと読み間違うことがある。原因
以下の原因により、バーコードスキャナは誤ったコードを出力する場合があります。
披検査バーコード
UPC-A
このバーコードラベルと被検査バーコードUPC-A 000000000062のデータラベルと比べてみて、特に問題ないと思われます。
JAN-8
JAN-8の00000000とUPC-A 000000000062は明らかに異なるバーコードシンボルです。
しかしバーをよく見てみると、UPC-Aシンボルの中にJAN-8シンボルと同じような部分が含まれていることに気が付きます。
２つのラベルを少しずらし、重ね合わせてみるとよくわかります。上がUPC-A、下がJAN-8です。
UPC-AとJAN-8
斜めの矢印部分に（スキャンされた部分）JAN-8を含みます。
考察
通常バーコードは印字されたバーの両脇にクアイアットゾーンと呼ばれる何も印字されていない空間が必要です。クアイアットゾーンに続く最初のバー群をスタートバーとみなします。今回問題となったバーコードは、JAN-8のチェックコードまで含んだ形で、正しいパターン（に非常に近い）が生成され、さらにそのバーの両端に大きな白ブランク部分（クアイアットゾーン）ができてしまうデータの組み合わせであったため、完全な１つのデータパターンが成立してしまっています。
JAN-8として認識するためには、規格とスタートバーの幅が異なりますが、以下のような要因により（要因が重なり）、正しいJAN-8と認識されてしまっているようです。
- スタートバーはスキャンの最初であるため、他のデータ部のバーと異なり、スタート位置の検出および同期開始のためのバーであるため、バーの太さ自体はある程度幅を持って検出している。
- 広い白エリアに続く黒バーのデータ（スタートバー）は、画像データ的に立ち上がりエッジがなまるため、細めに検出されやすい。
- データ中に含まれる最大幅のバーと比較すると細いため、細バーとして検出されてしまう。
- バーコードへ近づける際に、上記図のように斜めに読んでしまった場合、先頭バーが細く検出されてしまう。
- 読み込んだ１列中のデータの中からバーコードを切り出す際、途中からデータを認識してしまった場合。
- 印字のかすれ等などにより先頭を細めに認識してしまう場合。
左からスキャンされた場合、スキャンの状態によってはUPC-Aコードの途中で１つのバーコードが構成されてしまうため、このような場合に誤ったコードを発生する恐れがあります。
バーコードは左右どちらから読んでも正しく読めるように規定されているため、右からスキャンされた場合と左からスキャンされた場合とでは結果が異なります。右から読んだ場合、UPC-Aのストップバーを読むため試験の際、読み誤りが少ないように思われました。
実際に下記のように左右マスクして読み込ませた場合、先頭バーの幅が異なる事により読みづらいですが、JAN-8（EAN-8）として読み込むことができることを確認しました。
上記問題について、弊社で複数のメーカーのバーコードスキャナを用い試験したところ、発生頻度の大小はありましたが、いずれのバーコードスキャナであっても上記問題が発生することがわかりました。スタートバーの認識はアナログ的な判断に影響されますので、同じスキャナでもレンズやCCDの特性、ソフトウェアのバージョン等によっても、エラーが頻度が異なります。
回避案
本問題は、規格にのっとり使用されているUPC-Aのバーラベルとしてはほとんど問題が発生しないと思われます。実際、米国の流通マーケットがこの問題により混乱したという話は聞きません。これは、このバーコードであつかうデータフォーマットまで考えられ運用されているからだと思われます。今回の例のように、UPC-Aを本来規定された以外のデータフォーマットで運用した場合、バーコードシンボル自体が問題を発生するため、バーコードスキャナでの回避は非常に難しくなります。どのようなデータの組み合わせの場合にこのような誤りパターンを発生するのか、すべてのデータ組み合わせを検証することは不可能ですので、あらかじめ以下のような方法での問題回避をお勧めいたします。
- UPC-Aは本来の目的（北米で生産される商品コード）以外に使用しない。
- 使用していない種類のバーコードの読込みを禁止する。（この場合、EAN-8読込を禁止する）
- 読み間違いが発生するコードの組み合わせが見つかった場合、そのコードは欠番とし、そのラベルは使用しない。
- 読み込んだバーコードの種別識別子をあわせて出力する設定を行い、目的外バーコードの場合プログラムで破棄する。
- 読み込んだバーコードの桁数が目的以外の桁数の場合、そのバーコードはプログラムで破棄する。
※UPC-Aをご使用される場合、上記を正しくご理解した上でご使用いただけますようお願い申し上げます。
参考
ITFコードについて
ITFコードを用いた際にも似たような問題が発生します。ITFで短い桁まで読み込めるように設定した場合、バーコードの一部でITFコードが成立してしまうため、斜め読み等で同様の誤りが発生することがあります。通常ITFを使用する場合、目的バーコードの桁数のみを読み込むようにバーコードスキャナにバーコードデータ長を設定して使用します。JAN,EAN,UPCについて
本記述中でJANコードとEANコードという表記がありますが、JANコードとEANコードはシンボル的にはまったく同じものです。EANコードの国コード（先頭２桁）が49または45の原産国IDが日本であるEANコードを、日本においてJANコードと呼んでいます。UPCコードは北米向けで、国コードが0ですが、国コードを0としてEANコードを用いるのではなく、バーコード自体が異なります。Last Updated 2011/09/09
