目次
- 文字コード「JIS」の固定長データの文字数カウントがおかしい
- エディタでわからない時は16進ダンプ
- エスケープシーケンスコードじゃないか！！
- Windowsのエディタの落とし穴
- JIS7（ISO-2022-JP）とJIS8
- WindowsのエディタのJISは「ISO-2022-JP」
- WindowsのエディタでJIS8保存なら「SJIS」を選ぶ
文字コード「JIS」の固定長データの文字数カウントがおかしい
文字コード「JIS」の固定長データををインプットとする処理で、エラーがでてすすまないという相談がありました。
確認すると、たしかに「データ長が指定より長い」というエラーがでています。
データがおかしいのだろうと、エディタで開いて見直しても、問題はなく、指定の桁（文字）数に収まってます。
問題ないのか？と思って、プログラムで読み込むと6文字分長いと怒られる。
デバッグして変数をウォッチしてみると、文字数カウントで6文字多い。
データがおかしいのは間違いないのだけれど、エディタで見てもわからない。
そういう類のエラーです。
エディタでわからない時は16進ダンプ
16進ダンプしてみました。
固定長のデータは「半角カナ」まじりだったのですが、見ていくと、その「半角カナ」文字があるあたりに怪しいところがあります。
こんな感じです。
1B 28 49 3B 38 57 32 39 5D 3C 5E 1B 28 42
この黒文字部分の「 3B 38 57 32 39 5D 3C 5E」が、半角カナ文字です。
その前後の赤文字部分「1B 28 49」と「1B 28 42」は、元のテキストには対応する文字がありません。
つまり、エディタでは見えない文字が6文字固定長データに追加されてます。
僕はこの数字の並び・・大昔に見たことがあります。
5分ほど眺めて・・思い出しました。
エスケープシーケンスコードじゃないか！！
そうです。
これは「エスケープシーケンスコード」です。
固定長コードはエスケープシーケンスコードなど含めません。
だから、取り込みプログラムもエスケープシーケンスコードを考慮していません。
こいつがエラーの原因であることは１００％間違いありません。
とりあえず、このエスケープシーケンスコードを取り除いてやると、エラーなく処理できました。
Windowsのエディタの落とし穴
JISの固定長データが、エスケープシーケンスコードのはいったデータに変わってしまった原因はデータ作成者のオペミスでした。
外部機関から受け取った「JISの固定長データ」を、Windowsのエディタで開いて中身の確認をしたらしいのですが、つい「文字コードJIS」で上書き保存したみたいです。
これ。
やりがちなのですが、パッと見ておかしくなったのがわからないんです。
元データの文字コードは「JIS」です。
間違って保存してしまった後も、エディタで確認すると文字コード「JIS」です。
でも、実は見えないエスケープシーケンスコードが入り込んで、固定長データとしては壊れている。
こういうことがおきているわけですから。
まさに、Windowsのエディタの落とし穴です。
JIS7（ISO-2022-JP）とJIS8
Windowsのエディタになんでこんな落とし穴があるのか？
これを説明するには、まず文字コード「JIS」には、ISO-2022-JP（JIS7）系とJIS8系という2種類あることから始めないといけません。
この２つの「JIS」の大きな違いは、ISO-2022-JP（JIS7）には、シフトイン、シフトアウトの考え方があることです。
ISO-2022-JPは、JIS7をベースに電子メールなどに使うために決められたものです。
JIS7の最大の特徴は、英大文字・小文字と半角カナのコードが重複していることです。
JIS7のエリアは元々半角カナなんて考慮せずに決められていました。
なので、コードが足らず、重複したコードを設定して、「ここからは半角カナとして使う」とか「ここからは英字として使う」という宣言によって、切り替えています。
ISO-2022-JPのそのへんの仕様は以下のように説明されてます。
コード範囲が重複するため、エスケープシーケンスによって切り替えます。
ESC $ @ 漢字の開始（旧JIS漢字 JIS C 6226-1978）
ESC $ B 漢字の開始 (新JIS漢字 JIS X 0208-1983）
ESC & @ ESC $ B 漢字の開始 (JIS X 0208-1990）
ESC ( B ASCIIの開始ESC ( J JISローマ字の開始
ESC ( I 半角カタカナの開始
JIS８ではそんな必要はありません。
英数と半角カナに別々にコードがちゃんと割り振られているので、シフトイン・シフトアウトなどで切り替える必要がないからです。
だから、固定長のように桁を保証しないといけない場合はJIS8を使います。
そう。
JISの固定長・・というのは、暗黙的に「JIS8の固定長」なのです。
WindowsのエディタのJISは「ISO-2022-JP」
問題は、Windowsのエディタや文字コード変換ツールなどでJISを指定すると、この「ISO-2022-JP」が適用されるということです。
つまり、今回のトラブルは次のようにして発生しました。
ちなみに。
半角カタカナの開始を示すエスケープシーケンス「＜ESC ( I＞」は16進数だと「1B 28 49」、ASCIIの開始を示すエスケープシーケンスは「＜ESC ( B＞」は「1B 28 42」です。
それで。
1B 28 49 3B 38 57 32 39 5D 3C 5E 1B 28 42
みたいな出たができていたというわけなのですね。
WindowsのエディタでJIS8保存なら「SJIS」を選ぶ
実は。
JIS8の「半角英数字」・「半角スペース」・「半角カナ」のコードはSJISと同じです。
だから。
JIS8の固定長をもしWindowsエディタで保存しないといけなくなったら、文字コード「SHIFT-JIS（SJIS）」を選べばよかったのですね。
気づけば簡単なことなので、なんとかなりました。
でも。
文字コードがからむとややこしいですね。
昔、汎用機全盛時は「EBICDIC」とか「JIS7」「JIS8」「EUC」「SJIS」などなど、常に文字コードを意識しながら仕事してたな・・と久々に思い出しました。
ユニコードがある現代は、ほんと良い時代だと、つくづく、思います。
今回はこんなところで。
ではでは。
