このサイトのバーコード23形式を、このサイトのリーダーで全部読んでみた

何を確かめたのか

このサイトには、QRコードやJANコードなど30種類以上のコードを作るツールと、カメラでコードを読むバーコードリーダーがあります。 そこで、「このサイトで作ったコードを、このサイトのリーダーで本当に読めるのか」を全形式について確かめました。

結果を先にまとめると、次のとおりです。

• 試した23形式のうち、18形式が読めました。
• 読めなかった5形式は、そもそも読み取りライブラリに読み取り機能がありません。
• 検証の途中で、リーダー側の不具合が2つ見つかり、どちらも修正しました。NW-7（Codabar）が読めない設定になっていたことと、UPC-E がライブラリの不具合で読めなかったことです。
• QRコードの誤り訂正は、中央を隠す試験では規格上の数字（L約7%〜H約30%）より少ない面積で読めなくなりました。

試し方

1. 各形式のコードを、サイトの作成ツールと同じ部品（bwip-js 4.11.2）で画像にする。
2. その画像を、サイトのバーコードリーダーと同じ部品（ZXing の JavaScript 版 @zxing/library 0.23.0）で読む。
3. 読み取った文字が元の文字と一致したら「読めた」とする。

大きさは、bwip-js の拡大率を1〜4の4段階で試しました。拡大率1では、1次元バーコードのいちばん細い線が1ピクセル、2次元コードの1マス（モジュール）が2ピクセルになります。 読めた形式は、いちばん小さい拡大率1でもすべて読めました。 さらに、画像を90°回転させた場合も試しています。

これはパソコンの中で作った「ぼやけも傾きもない画像」での試験です。 カメラで撮ると、ピントのずれ・光の反射・紙の曲がりなどが加わるため、実際にはこれより読みにくくなります。 ここで「読めない」形式は、カメラでもまず読めないと考えてください。

結果1：形式ごとに読めたか

2次元コード

1次元バーコード

読めなかった形式の理由

Code 11・MSI・ファーマコード・カスタマバーコード・Royal Mail は、ZXing に読み取り機能そのものがありません。 これらは工場の部品管理、医薬品の包装、郵便の区分など、専用の読み取り機を使う場面で使われる形式で、 スマートフォンの標準的な読み取り機能でも対応していないことがほとんどです。

見つかった不具合その1：UPC-E が読めなかった

UPC-E は、ZXing の元の Java 版では読める形式です。JavaScript 版のコードを調べると、UPC-E の処理に3か所の間違いがありました。

1. 読み取った数字を組み立てる部分が、組み立てた結果を呼び出し元に返さず捨てていました。
2. バーコードの終わりを探すとき、UPC-E 専用の終了パターンではなく、EAN・UPC-A 用のパターンを探していました。
3. チェックデジットを確かめるために UPC-A の12けたへ戻す処理が、数字ではなく文字コードを比べていたため、常に誤った桁に展開していました。

この3か所を直した読み取り処理をサイト側で用意し、ライブラリが何も読めなかったときに使うようにしました（2026年9月20日）。 生成ツールが作った UPC-E のコード8種類（番号体系0と1、展開の分岐すべて）で、正しく読めることを確かめています。

見つかった不具合その2：NW-7 が読めなかった

最初の試験では、NW-7（Codabar）も読めませんでした。調べると、ZXing の JavaScript 版は、 読む形式を指定しないと NW-7 の読み取り機能を最初から外していることがわかりました。 このサイトのリーダーは形式を指定していなかったため、サイトのNW-7作成ツールで作ったコードを読めない状態でした。

リーダーが読める形式をすべて明示的に指定するように直し、NW-7 も読めることを確かめました（2026年9月19日修正）。 上の表は修正後の結果です。

回転に弱いのは1次元バーコード

QRコード・Data Matrix・Aztec・Micro QR は、90°回転しても読めました。 一方、1次元バーコードは回転させるとすべて読めませんでした。 バーコードリーダーは画像を横方向に1行ずつ調べるため、バーが横向き（縞が縦に並ぶ向き）になると線を横切れなくなるからです。 2次元コードでも、横に長い PDF417 と MaxiCode は、回転させた画像を読めませんでした。

ZXing には回転も試す「念入りモード」がありますが、カメラ映像を毎秒何枚も処理するリーダーでは処理が重くなるため使っていません。バーコードは、縞が縦に並ぶ向きでカメラに映すのが確実です。

読み取り結果が見た目と違う形式

• GS1-128：コードの下の (01)04901234567894 のかっこは人が読むための表示で、読み取り結果は 0104901234567894 になります。
• ISSN：雑誌のバーコードは、ISSN の8けたを 977 で始まる13けたの EAN-13 に組み込んだものです。0317-8471 は 9770317847001 として読み取られます。

結果2：QRコードはどこまで汚れても読めるか

QRコードには「誤り訂正レベル」があり、L・M・Q・H の順に、汚れや欠けに強くなります。 URL（https://heron-tools.com/ja/tools/2dcode/qr/、43文字）を各レベルでQRコードにし、 中央に白い正方形を1モジュールずつ大きくしながら置いて、どこまで読めるかを調べました。

わかったこと

• 読めなくなる面積は、規格上の数字より小さい：規格の「約7%〜30%」は、データを8ビットずつに区切った「コード語」のうち何割を直せるかという数字です。 正方形で隠すと、境目で一部だけ隠れたコード語も壊れるため、隠した面積の割合以上にコード語が壊れます。 「面積の30%を隠しても読める」わけではない、と覚えておくと安全です。
• M を選ぶと Q になることがある：作成に使っている bwip-js は、同じ大きさ（バージョン）に収まるなら、指定より強い誤り訂正レベルを自動で選びます。 今回の URL では、M を選んでも Q で作られました。コードの大きさは変わらずに、汚れに強くなります。
• H は大きくなる：同じ URL でも、L は 29×29、H は 37×37 モジュールでした。 同じ印刷サイズなら、H のほうが1モジュールが小さくなり、面積あたりでは約1.6倍の細かさになります。 ロゴを重ねる、屋外に貼るなど汚れが心配なときは H、名刺など小さく印刷するときは M が目安です。

同じ試験を英数字だけの文（HERON TOOLS QR ERROR CORRECTION TEST 2026）でも行い、 L で 4×4、M（実際は Q）で 10×10、H で 13×13 モジュールまで読めました。傾向は同じです。

結果3：同じ内容をコードにしたときの大きさ

16文字の HERON-TOOLS-2026 を各形式にして、bwip-js の拡大率を1にそろえたときの大きさを測りました（2次元コードは1マス2ピクセル、1次元バーコードは細い線1ピクセル）。

• 2次元コードでは Data Matrix がいちばん小さく、QRコードより一辺が約14%短くなりました。部品や基板に小さく印字する用途で使われるのはこのためです。
• 1次元バーコードでは、Code 39 は Code 128 の約1.4倍の幅になりました。Code 39 は1文字を表すのに多くの線を使うためです。
• 1次元バーコードの高さは自由に決められるので、表では幅だけを比べています。

まとめ：形式を選ぶときの目安

• だれのスマートフォンでも読めてほしい：QRコード。商品なら JAN。
• 小さく印字したい：Data Matrix（2次元）、Code 128（1次元）。
• Code 11・MSI・カスタマバーコードなど：取引先や郵便局などが指定する専用の形式です。一般のスマートフォンでは読めない前提で使いましょう。
• 汚れが心配：QRコードの誤り訂正を H に。ただしコードは大きくなります。

この記事で使ったツール