シフトJISの開発経緯 - b2r.infoの日記

古川さんのblogにシフトJISの開発経緯がのっています。
「パソコンにおける日本語処理/文字コードハンドブック」の川俣晶さんからのコメントもあり(川俣さんのコメントは文字コードと関係ありませんが(^^;)、文字コード関連の歴史的経緯を知るうえで非常に参考になります。

1. 既存の米国ソフトウェアに対するインパクトを最小にする。
2. JISコードを簡単なアルゴリズムでマッピングする。
3. 半角カナと共存する。

・1については、制御コードを極力排除するようにしました。1FH以下は
もちろん、7FHも。言語処理系で使う記号も極力さけるため、2バイト
目のスタートを40Hにしました。

5CHがまずい、というのは後からわかりましたが、残念ながら、後の祭
りでした。その問題が発覚したときに、ムッとした記憶があるので、私
としてはシフトJISコードのマッピングを知らずに、後からMS-DOSがそ
こを使ったのだと思っています。

要は1.と3.との調整(妥協?)がすべてだったと思うのです。

悪評高い5c問題については、読んだのは前述の川俣さんの本だったと思いますが、

シフトJIS開発時にはまだディレクトリの概念がなかった
ディレクトリ導入時、UNIXで区切り文字として使用されているスラッシュは、オプションスイッチとして広く利用されていたので、表示が似ているバックスラッシュを区切り文字に利用した

といった経緯があったと思います。

そもそも、まだネットワークもそれほど発達しておらず、異プラットフォーム間でのデータ交換・共有といった概念もまだまだ希薄だった時代、MS-DOS用に開発されたシフトJISがUNIX環境でメタ文字として使用している5cを含むことが問題になるなど、想定できることではなかったのだと思います。

「シフトJISは5c等ASCII領域を含むから駄目だ、駄目駄目だよ。EUC-JPじゃないと」みたいな事を聞くことがあるのですが、それは今だからいえることで、そのことでシフトJISを悪くいうのはお門違いというか、可哀そうです。ムッとしたくもなるってもんです。
バックスラッシュなんて、シフトJIS以前に円マークに置き換えられるくらい無用な?文字として認識されていたわけですし。

実はMySQLのシフトJISの扱いに現在進行形で頭を悩ませたりしているのですが、互換性を維持したシフトJISの実装は、当時としては極めて妥当で、優れた設計だったと思います。

EUC-JPは3.を無視することで、1.を気にすることなく、容易に2.を実現することができたわけです。
で、EUC-JPは8Eシングルシフトを使用して半角カナを2byteで実装するわけですが、シングルシフトを実装していないUNIX環境が多かったからISO2022-JPで半角カナが使えないといった新たな歴史につながるわけですね。

いやぁ歴史は大切です。
「パソコンにおける日本語処理/文字コードハンドブック」もう一度読みなおそう。