Excel・CSV でバーコードの先頭ゼロが消える理由と対策

バーコードを一括生成したことがある人に聞けば、同じ話が返ってきます。ファイルは正常に見えた、バーコードも印刷された — ところがどれを読み取っても、桁が 1 つ少ない番号、あるいは指数表記に変換された番号になっていた。バーコードジェネレーターが悪かったのではありません。ジェネレーターが値を見る前に、スプレッドシートがデータを食べていたのです。

これはバーコード生成で最もよくあるデータ不良であり、結果を読み取るまでほぼ確実に見えません。なぜ起きるのか、どのシンボロジーが危険なのか、そしてスプレッドシートからラベルまでの道のりをデータに生き延びさせる方法を解説します。

なぜ Excel が先頭のゼロを食べるのか

Excel の既定の挙動は、数字に見えるものは何でも_数値_として解釈することです。そして数値には先頭のゼロがありません。セルに 012345678905 と入力すると、Excel は数値 12345678905 を格納します。Enter を押した瞬間、先頭の 0 は消えます。

たいていのスプレッドシートではこれは無害です。バーコードデータにとっては致命的です。UPC-A はちょうど 12 桁、EAN-13 は 13 桁、GTIN-14 や SSCC-18 は 14 桁または 18 桁だからです。先頭のゼロを 1 つ落とせば、_別の、短い、無効な_識別子を符号化したことになります — チェックディジットで不合格になるか、別の商品として読み取られます。

同じことは、CSV ファイルをダブルクリックして開いたときにも起きます。Excel は各列を既定の「型を推測する」ロジックで取り込み、数字だけのフィールドは数値になり、ゼロが削り取られます。

指数表記：11 桁の崖

Excel にはもう一つ、よりこっそりした挙動があります。およそ 11 桁を超える数値は、指数表記で表示され（そしてしばしば格納も）されます — 12345678901234 が 1.23457E+13 になります。

12 桁の UPC では微妙なラインですが、14 桁の GTIN-14 や 18 桁の SSCC では確実に起きます。値が指数表記に書式変換された瞬間、末尾の桁は丸めて捨てられ、コードは修復不能に破壊されます。後からセルを再書式設定しても失われた桁は戻りません。数値そのものがすでに丸められているからです。

15 桁の精度限界

指数表記を回避できたとしても、Excel には超えられない天井があります。数値を IEEE 754 倍精度浮動小数点として格納するため、正確なのは約 15 桁までです。

15 桁を超える識別子 — そして SSCC-18 は 18 桁 — は、末尾の桁が黙って丸められます。18 桁の SSCC を Excel の数値セルに無傷で保管することはできません。文字列として保管する_しかない_のです。これは設定で変えられるものではなく、形式の性質であり、Microsoft 自身の Excel の仕様と制限 に記載されています。

どのシンボロジーが危険か

ゼロで始まるコード — 多くの国で発行された EAN-13 ではよくある — は、書式未設定のスプレッドシートのセルに触れた瞬間に危険にさらされます。

ゼロを守る方法

核心となる原則は、データが入る前に列を文字列に固定することです。信頼できる方法を優先順に並べます。

よくある対処法について 2 つ補足します。

• ゼロが消えた_後_にセルを「文字列」書式にしても戻りません。 データはすでに削られています。再取り込みか再入力、あるいは固定幅の数式でゼロを埋め戻すしかありません。
• アポストロフィの技は入力中にしか効きません。 列全体を貼り付けるなら、先に列を「文字列」書式にしてください。

CSV から生成しているなら、CSV をプレーンテキストエディタで開き、生のファイルにゼロが残っているか確認してください。CSV 自体を書き出したプログラムがゼロを削っていた場合、どんなスプレッドシートの技も役に立ちません — ファイルを作った元側を直す必要があります。

GS1 の視点：これらは単なる数字ではない

スプレッドシートに壊される識別子は任意のものではありません — 定義された構造と計算されたチェックディジットを持つ GS1 の識別キーです。GTIN-14、SSCC-18、GS1-128 バーコードはすべて、GS1 企業プレフィックスに参照番号とチェックディジットが続く形をしています。

これが重要な理由は 2 つあります。

• チェックディジットが安全網になる。 先頭のゼロが落ちると、短くなった番号は非常に高い確率でチェックディジット不一致を起こします。これは良い知らせです — エラーが黙って出荷されるのではなく、読み取り時に検出されるからです。悪い知らせは、多くの作業者がチェックディジットが間違っていると気づかず、データを直す代わりに再印刷を繰り返すことです。チェックディジットのロジックは チェックディジットの用語集 で解説しています。
• データキャリアは任意ではない。 GTIN-14 は正しいアプリケーション識別子（AI 01）付きで ITF-14 または GS1-128 バーコードに符号化しなければならず、SSCC-18 は AI 00 を使います。スプレッドシートの値が壊れると、バーコードはまったく読めないバーコードよりずっと厄介な、単に間違った先を指す「それらしく見える」GS1 キーを符号化します。

GS1 はデータキャリアと識別子の 規格セット 全体を公開しており、一般仕様 がその符号化方法を厳密に規定しています。元データをきれいに保つことは、そのすべての前提条件です。

壊れたデータを修復する

ゼロがすでに消えているなら、慌てる必要はありません — 復旧には 3 つのレベルがあり、確実なのはそのうち 1 つだけです。

• レベル 1 — チェックディジットが先頭のゼロを再現できる。 UPC-A、EAN-13、GS1-128 キーでは、チェックディジットは他の桁から算出されます。13 桁であるべきコードの列が 12 桁を読んでいるなら、足りない桁はほぼ確実に先頭のゼロです。候補それぞれについてチェックディジットを計算し、一致するものを確認すれば、正しい先頭桁が分かります。チェックディジットの計算式 を参照してください。
• レベル 2 — 固定幅までゼロ埋めし直す。 意図した長さが分かっているなら、=TEXT(A1,"000000000000")（UPC-A なら 12 個、EAN-13 なら 13 個、SSCC なら 18 個のゼロ）のような数式がゼロを前置きしてくれます。これは桁数が分かっていて、値がそれ以外は無傷な場合にだけ機能します。15 桁の制限で末尾を丸められた SSCC は復旧できません。
• レベル 3 — 元に戻る。 これが唯一確実な修正です。ERP、商品マスタ、元の CSV からデータを再書き出しし、今度は取り込み時に列を文字列に固定します。壊れたファイルを正しさに修復しようとしないでください — 失われた桁は本当に失われており、推測した桁を使うと「別の商品を指すバーコード」を出荷することになります。

「読めるが間違っている」と「読めない」の違いは 読み取れるのに弾かれる：符号化値とデータベース の主題です — バーコードは問題なく読めるのにシステムが拒否し続けるなら、読む価値があります。

生成前にデータを点検する方法

バッチをどのジェネレーターに投入する前でも、2 秒でできる監査があります。

1. 桁数を数える。 UPC-A の列はすべて 12 桁、EAN-13 は 13 桁、SSCC は 18 桁であるべきです。すべての値が 1 桁少なければ、先頭のゼロが食べられています。
2. E+ や E- を探す。 指数表記で表示されているセルはすでに壊れています — 末尾の桁は消えています。
3. 並べ替えて極端な値を見る。 15 桁の丸めは最大の値に最初に現れます。...1234 で終わるはずの SSCC が ...0000 で終わっていれば、丸められています。

落ちた先頭ゼロの修正は早いですが、丸められた 18 桁の SSCC の修正はそうではありません。失われた桁はスプレッドシートからは復元できないからです。長い識別子を文字列として保管した瞬間、その修復は永遠に不要になります。

これは 12 の原因でたどる「読み取れない」診断 の最初の層です — そして最も多くの人が不意を突かれる層でもあります。バーコードは_印刷_され_読み取れる_のに、間違った値だからです。記号は正しく読めるのにシステムが拒否する、密接に関連したケースについては 読み取れるのに弾かれる：符号化値とデータベース を参照してください。

関連記事

• 印刷したのに読めないバーコード：12 の原因を順に
• SSCC-18：18 桁、チェックディジット、決して使い回せない理由
• チェックディジットを解説