文字コード掲示板

（参考）SMTPメーラの問題などがあります。

朴様

EDIの多種コード変換問題で苦闘する中での経験的なお話なのですが、
>
> 必要性はともかくとして、ISOに登録することで半角カタカナが国際的に
> 共通化できたのでは？という思いがありました。

　JIS-X-0201にあるJIS8ビットコードの定義をご覧頂けば分かりますが、
　外国発のMTAである「SMTP」は8BITの最上位BITを落とすので、半角カナ
　を通しません。（文字化けします）

等と言う記事が、「問題があるので、半角カナを使用するな」的論調でWEB
検索すると多数見つかります。（半角カナの是非は別として）

電子メール等で表示不可能文字（半角カナを含む）を省いた、ISO-2022-JP
と言う名称のRFC（ISO規格名称ではない）がデファクトスタンダードとして
古くから流通している事実もあり、ISO-2022がJIS規格化されたJIS-X-0202
で定義された半角カナのエンコーディングスキームが国際的に認知されない
日本独自のローカルルールとして半角カナの対応を規定しています。
　 http://web.kyoto-inet.or.jp/people/tomoko-y/biwa/wnn/furoku.html

歴史的に、半角カナのエンコーディング方法は
　１．Netscape系
　２．Microsoft系
の２種類が存在し、上記JIS規格やISOは現状を追認するような形で、半角カナ
領域のエンコーディング方法を規定していますが、日本産のMTU以外は対応を
行っていないの現状が背景として存在します。（私見ですが）

MTAが全て「ESMTP」へ移行完了し、ISO完全準拠製品へ入れ替わるまで、現実
には使用できないコード（半角カナ）と言う認識です。（同様に私見）

とは言え、実際にはEDIで半角カナのデータ交換を行っている訳で、JIS97で
半角カナの将来的な削除を示唆しようが、半角カナ反対論者の強硬な主張が
存在しようが、実業務のデータから半角カナが消え去らない限り、今後も
半角カナが使われ続けるのは確実な状況にあります。

色々と問題のあるSJISコードですが、日本語ネイティブの目から見てさえ、
Unicodeの図形文字集合には不備がある＝表示図形が同じでもコードが異なる
＝重複文字が多数存在する、と言う状況を考えれば、EDIで行うデータ交換
ではSJIS＝管理人さんが説明しておられるWindows-31Jに限りますが、を
使用して各種文字コードの対応を決定付けているのが現実です。
→マッキントッシュのSJISは、製造年代別で異なる事に加え、Windows-31J
　とは非互換、JISが定義するSJISにはIBM拡張文字領域が存在しないなど、
　個人の好みは別としてWindows-31Jをデファクト採用する以外に、基準と
　なる文字体系が存在しないようにも感じます。（私見）

現代ではDB上に多量のデータを各社・各業界等で蓄積しておりますので、
規格云々に係らずWindows-31Jは使用され続けるでしょう。（私見）