わが最初の文字コードファイト

史上空前の文字コードファイトブームを受けて、ふと、大昔の記憶を思い出しました。僕の「文字コードファイト事始め」です。まだインターネットが普及していなくて、パソコン通信の時代のお話です。
おそらく1987年くらいの話だと思うのですが、当時PC-VANやNIFTY全盛期で、その後活躍の場を日経MIXやNIFTYに移すのですが、その当時はまだPC-VANを主に使っていました。

なにが問題だったかというと、「高速モデム」が普及し始めたころで、300ボーの音響カプラから、1200bpsや2400bpsのモデムに移ろうという頃です。ちょうどMNPがようやく普及し始めたころです。MNPというのは、米マイクロコム社が提唱したモデム用のデータ圧縮と誤り訂正の規格です。
データ圧縮はよいとして、MNPでようやくモデムの誤り訂正手順が導入されたことになります。

で、MNPが普及していない頃の1200bpsや2400bpsのモデムというのは、よく文字化けを起こしておりました。そのために、XMODEMのようなファイル転送手順や、ishのような誤り訂正機能つきのバイナリ・テキスト変換プログラムが重宝がられたのでした。

ところが、当時のコミュニケーションツールの主力だった掲示板は、通常無手順でアップロードしていましたから、文字化けが起こったら化けっぱなしになりえたわけです。あるいは、ダウンロード中に文字化けする場合もありますが、一々ダウンロードしなおすのも面倒くさい。

ここで、シフトJISの特性上、一箇所でも文字化けが生じると、その影響が伝播する場合があります。例えば、以下の文字列。

小文字ａｂｃｄｅと入力する

「字」のシフトJISコードは、8E9Aですが、この8Eが4Eに化けたとします。すると、上記の文字列は、以下のように化けます。

小文N嘯≠ｂモр・ﾆ入力する

ひどいですね。
なぜそういうことが起きるかというと、8Eが4Eに化けると、これは"N"ですから、後続の9AがシフトJISの一バイト目と認識されるわけです。そして、以下一バイトずつずれが伝播することで、一バイトの文字化けが次々に影響し、読むに耐えない状態になることがあるわけです。

ここまでが問題の提起です。
で、どうしたかというと、「文字化け除去フィルタ」なるものを考案しました。原理はこうです。
いったん化けたものを直すのはあきらめて、逆に問題となる文字を除去することにより、できるだけ読みやすくすることを考えました(うわ、有害文字の削除??)。
具体的には、文字種ごとにスコアをつけて、できるだけスコアの総和が大きくなるようにしました。細かいことは良く覚えていないのですが、

アスキー文字:5点
半角カタカナ:5点
JIS第一水準:10点
JIS第二水準:1点
シフトJISとして不正な文字:-10点

のように、出現頻度や「ありそう」度合いにより点数を勘案して、逆に不正な並びについては「ペナルティ」をつけることによって採点しました。そして、バイトを順に見て行って、「バイトを削除することによって点数が上がる」場合は、そのバイトを除去するようにしたと思います。
おそらく、先の文字列は、「字」の二バイト目を除去して以下のように変換されたと思います。

小文Nａｂｃｄｅと入力する

これなら、まぁ読めなくもないですよね。
このツール、激しく文字化けした場合には、それなりに重宝しましたが、その後MNPモデムの普及によってニーズ自体が消滅したので、お蔵入りになりました。

しかし、です。
冒頭に述べたように、史上空前の文字コードファイトブームにより、不正な文字の除去、あるいはエラーにする(こっちが望ましい)という処理が必要になったので、20年くらい昔の記憶がよみがえったというお話でした。

追記(2007/10/24 12:30)

id:hasegawayosuke氏から、はてなブックマークコメントを頂戴しました(下記は見やすいように少し編集)。

似たようなことしてるな。はせがわの文字コードファイトは2003年に始まった→
[port139ml:03343] Re: はせがわさん版jstrings 0.5
istrings 0.2 を近いうちに出します - 葉っぱ日記

中身を見ると、

例えば、Shift_JIS であろうバイト列(16進)
�
� 81 82 82 82 83 82 84 82
�
があったとします。これをそのまま Shift_JIS に直すと、「≠ｂモр」という
意味のない文字列の断片なわけです。ところが、先頭の 81 を敢えて切り捨て
た上で Shift_JIS に直すと「ｂｃｄ」とそれなりに意味のありそうな文字列に
なるわけです。

なんという類似!　「≠ｂモр」は、文字コードファイトの同士の証ですかねww