バーコード読み取り — JAN/EAN/UPC/CODE128/CODE39/ITF/Codabar

バーコードが乗った画像には、商品の内訳から個人識別子まで含まれる

バーコードは「モノの識別子」として設計されていますが、実際にデコードされる値は用途ごとに大きく異なります。スーパーのレシートに印刷された JAN-13 は購入商品の明細そのものです。配送伝票の追跡番号 (Code 128) は荷受人の住所・氏名と紐付いた個人特定可能な情報です。病院・図書館・社員証に使われる Codabar / Code 39 は患者 ID・貸出番号・社員番号を含みます。倉庫検品用の ITF-14 は在庫構成を示すサプライチェーン情報です。複数の画像を一括処理する場合、その CSV 出力には多数の識別子が集約されます。

スマートフォンで撮影した画像ファイルには EXIF メタデータ (撮影位置・日時) が埋め込まれていることもあります。バーコード値に加え、撮影コンテキストの情報も画像に含まれるため、「バーコードの読み取り画像」を外部サービスにアップロードすることは複数の機微情報を同時に渡すことになりえます。

バーコード画像をオンラインデコーダーに上げるとどうなるか

オンラインのバーコードデコードサービスは、画像をサーバーへ送信してデコード結果を返します。画像本体がサーバーに届くと、EXIF 含む元データが残ります。さらにバーコード値は画像を解析した結果としてサーバー側ログに記録されることがあります。「追跡番号を読み取りたかっただけ」でも、荷受人情報と紐付いた Code 128 値を外部サーバーに渡したことになります。

また、大量の画像を一括でアップロードするバッチ処理的な使い方をしたとき、顧客リストに近い量の個人識別子が一度のリクエストで外部へ出る可能性があります。利用規約で「送信データをサービス品質向上のために利用する権利を持つ」と定めているサービスでは、これらの値が学習データや統計として活用されるかもしれません。

@zxing/library による完全ブラウザ内デコード

本ツールは Apache 2.0 ライセンスの @zxing/library を npm パッケージとして取り込み、Canvas API で画像ピクセルを読み取ってブラウザ内でデコード処理を行います。ZXing (Zebra Crossing) はバーコード処理ライブラリとして広く知られたオープンソースプロジェクトで、JAN / EAN / UPC / Code 128 / Code 39 / ITF / Codabar の各フォーマットをカバーします。ピクセルデータをブラウザのメモリ上で処理するため、画像ファイルも、そこから読み取ったバーコード値も、いずれも外部サーバーへは送信されません。

DevTools の Network タブを開いた状態で画像をドロップしても、ページ初期ロード以降のリクエストは発生しません。複数ファイルの一括処理でも同様で、CSV エクスポートもブラウザのクリップボード API を使ってローカルで生成されます。

商品管理・物流・医療現場でのローカル活用

バーコードを読み取る現場の多くは、情報が機微なほど外部送信を避けたい状況です。倉庫・医療・図書館など、識別子に個人情報や業務上の秘密が紐付いている場面では特に、ブラウザ完結ツールの優位性が明確です。本ツールはインストール不要、オフライン環境 (ブラウザのキャッシュがあれば) でも動作するため、専用スキャナが手元にないシチュエーションでの補助ツールとして活用できます。

バーコード規格別の構造とチェックディジット検証

1 次元バーコードのフォーマットはそれぞれ符号化方式と桁構造が異なります。JAN-13 / EAN-13 は ISO/IEC 15420 で定義された 13 桁の数字コードで、先頭 2-3 桁が国コード (45 / 49 は日本、00-13 は米国・カナダ)、続く 4-5 桁がメーカーコード、残りが商品コード、最終 1 桁がモジュロ 10 のチェックディジットです。@zxing/library はチェックディジットを自動で再計算し、不一致なら読み取り結果を破棄します。これによって誤検出を抑えつつ、印刷品質が悪いラベルでも高い信頼性で値を取り出せます。

Code 128 は ISO/IEC 15417 で定義されたバリアブル長フォーマットで、Code Set A (大文字 + 制御文字) / B (フルアスキー) / C (2 桁ずつ数字) を Start / Code Switch キャラクタで切り替えながら効率的に符号化します。輸送ラベルでは Code Set C で偶数桁の追跡番号を半分の幅で印刷する設計が一般的です。Code 39 (ANSI MH10.8M) は英大文字・数字・少数の記号のみで、各文字を 9 個のバー (うち 3 個が太い) で表現します。ITF (Interleaved 2 of 5) は ISO/IEC 16390 で定義されたペアエンコーディングで、必ず偶数桁の数字のみを扱います。Codabar (NW-7) は伝統的に図書館や血液バッグの識別に使われ、Start/Stop キャラクタを A B C D から選択する独特の構造を持ちます。

画像認識フェーズの工夫と読み取り失敗の典型パターン

ZXing は画像を Canvas のグレースケールピクセル配列に変換し、ハイブリッド二値化 (Hybrid Binarizer) でバーと空白の境界を判定します。続いて Run-Length Encoding 風の幅シーケンスを抽出し、各フォーマットの「Finder Pattern」(EAN-13 のガードバー、Code 128 の Start キャラクタ等) を検出して読み取り方向を確定します。回転 90° / 180° の画像でも 4 方向すべてをスキャンするため、撮影向きを気にせず処理できます。ただし極端な歪み・反射・モアレが発生した画像ではバイナリゼーション段階で失敗するため、撮影時のフラッシュ反射を避ける・斜めから撮らないという基本が読み取り成功率に直結します。

実運用で読み取り失敗の原因として頻出するのは、(1) JAN-13 と JAN-8 を混同して 8 桁のラベルを 13 桁モードで読ませる、(2) Code 128 と Code 39 の判別を手動で固定して別フォーマットの画像を渡す、(3) 印刷の擦れでガードバーの片側が欠けている、(4) ITF の偶数桁制約を満たさない奇数桁の数字列が記録されている、の 4 パターンです。本ツールはフォーマット自動判定モードを既定にしているため (1)(2) は回避できますが、(3)(4) は元の印刷品質の問題なのでリプリントが必要になります。読み取った値を別のラベル印刷に流用したい場合は barcode-generate で同じ 1 次元規格を再エンコードでき、対象が QR コードの画像なら qr-decode が 2 次元側のデコードを同じ Apache 2.0 の ZXing ライブラリで担当します。