Shift_JIS

PC-98+MS-DOSの頃、文字列はShift_JISが当たり前だった。
私が考えるShift_JISの最大の利点は、半角文字は１バイト、全角文字は2バイトということだろう(一部例外を除く)。
これのどこが良いのかと言えば、バイト数が表示カラム数に一致するのだ。

しかしながら、'\'記号(5C)問題がある。
Shift_JISは２バイトで構成され、２バイト目は7bit文字のコードとかぶる部分がある。
そして、２バイト目が'\'記号(5C)になっている文字の場合、C言語のエスケープと見なされ、コンパイル時におかしな処理となる。

80年代、Lattice-CやMS-CでShift_JISで書かれたソースコンパイルしようとするとおかしなことになることがあった。
対策としては、2バイト目が'\'記号の文字の次に'\'記号を挿入するフィルタを実装して、make時にソースコードを変換してコンパイルする。
ちなみに、Turbo-C(後のBoarland C)では、Shift_JISを正しく扱っていた。
個人でプログラミングをする時は、Boarland C/C++ばかり使うようになっていった。

しかし、職場では住友電気のU-Stationを使っていた。
これはUnix機だったが、Shift_JISでソースコードを書いていたため、また'\'記号問題の対策(フィルタを実装して...)をする必要があった。

それから20年ぐらいだろうか。
そんな感じで開発環境が変わるたびに、毎度毎度同じ対策をし続けて、すっかり慣れていた。
そのため「UTF-8で文字の扱いが楽になる」という話を聞いた時、「Shift_JISで充分じゃん。」みたいに考えていた。

UTF-8では、'\'記号問題が無いという利点はあるが、なんと多くの全角文字が3バイトになるのだ。
さらには、半角カナも3バイトになる。
すなわち、文字のバイト数とカラム数が合わなくなる。
多くのprintf()の"%s"の「フィールド幅」や「精度」は、バイト数を指定するもので、カラム数ではない。
この記事のbookinfoの表示がズレズレになっているのも関係する。
実際には、EUC-JPの半角カナも2バイトだったため、このbookinfoは文字のカラム数を調整する機能も実装されている。
しかし、UTF-8には対応しておらず、ズレズレ表示になっている。
これはこれで、面倒な問題だ。

ちょっと話が脱線したが、Shift_JISでの問題は誰であれ自分なりの対処方法を持っていると思っていた。
しかし、こんなニュースを発見した。
キャラ名に「ソ」をいれるとバグる！　古参開発者「うっ……頭の中で何かが……」
記事の末尾にあるが、もはや「過去の話」なのかもしれない。