"BOKU"のITな日常

BOKUが勉強したり、考えたことを頭の整理を兼ねてまとめてます。

文字コードJISには2種類ある。Windowsのエディタの落とし穴/JIS7(ISO-2022-JP)とJIS8の話

f:id:arakan_no_boku:20191002201759p:plain

 目次

文字コード「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分ほど眺めて・・思い出しました。

 

エスケープシーケンスコードじゃないか!!

そうです。

これは「エスケープシーケンスコード」です。

x0213.org

固定長コードはエスケープシーケンスコードなど含めません。

だから、取り込みプログラムもエスケープシーケンスコードを考慮していません。

こいつがエラーの原因であることは100%間違いありません。

とりあえず、このエスケープシーケンスコードを取り除いてやると、エラーなく処理できました。

 

Windowsのエディタの落とし穴

JISの固定長データが、エスケープシーケンスコードのはいったデータに変わってしまった原因はデータ作成者のオペミスでした。

外部機関から受け取った「JISの固定長データ」を、Windowsのエディタで開いて中身の確認をしたらしいのですが、つい「文字コードJIS」で上書き保存したみたいです。

これ。

やりがちなのですが、パッと見ておかしくなったのがわからないんです。

元データの文字コードは「JIS」です。

間違って保存してしまった後も、エディタで確認すると文字コード「JIS」です。

でも、実は見えないエスケープシーケンスコードが入り込んで、固定長データとしては壊れている。

こういうことがおきているわけですから。

まさに、Windowsのエディタの落とし穴です。

 

JIS7(ISO-2022-JP)とJIS8

Windowsのエディタになんでこんな落とし穴があるのか?

これを説明するには、まず文字コード「JIS」には、ISO-2022-JP(JIS7)系とJIS8系という2種類あることから始めないといけません。

この2つの「JIS」の大きな違いは、ISO-2022-JP(JIS7)には、シフトイン、シフトアウトの考え方があることです。

www.ohsumap.jp

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 半角カタカナの開始

JIS8ではそんな必要はありません。

英数と半角カナに別々にコードがちゃんと割り振られているので、シフトイン・シフトアウトなどで切り替える必要がないからです。

だから、固定長のように桁を保証しないといけない場合はJIS8を使います。

そう。

JISの固定長・・というのは、暗黙的に「JIS8の固定長」なのです。

 

WindowsのエディタのJISは「ISO-2022-JP

問題は、Windowsのエディタや文字コード変換ツールなどでJISを指定すると、この「ISO-2022-JP」が適用されるということです。

charset.7jp.net

つまり、今回のトラブルは次のようにして発生しました。

  1. JIS8で作成された「JISの固定長データ」を受け取った。
  2. 中身を確認するためWindowsエディタで開き、うっかり上書きした。
  3. そこで半角カナの前後にエスケープシーケンスが埋め込まれた。

ちなみに。

半角カタカナの開始を示すエスケープシーケンス「<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と同じです。

charset.7jp.net

 

www.asahi-net.or.jp

だから。

JIS8の固定長をもしWindowsエディタで保存しないといけなくなったら、文字コード「SHIFT-JIS(SJIS)」を選べばよかったのですね。

気づけば簡単なことなので、なんとかなりました。

でも。

文字コードがからむとややこしいですね。

昔、汎用機全盛時は「EBICDIC」とか「JIS7」「JIS8」「EUC」「SJIS」などなど、常に文字コードを意識しながら仕事してたな・・と久々に思い出しました。

ユニコードがある現代は、ほんと良い時代だと、つくづく、思います。

今回はこんなところで。

ではでは。