[LE-talk-ja 22] Re: ISO-2022-JP-MS について

Back to archive index

Kazuhiro Kazama kazam****@mac*****
2006年 4月 6日 (木) 13:01:53 JST


On 2006/04/06, at 11:22, NARUSE, Yui wrote:
>>> ユーザ定義文字をメールで送信するために、
>>> 当事者同士で合意の上 ISO-2022-JP-MS で送る余裕があるのならば、
>>> CP932 で添付ファイルにするなり、UTF-8 で送るべき、
>>> というのは当然の批判でしょう。
>>
>> メールに限らず UTF-8 化に力を注ぐほうが、より健全だろうと思います。
>
> UTF-8 化の前提として、既存データの UTF-8 化が存在し、
> それを行うのにレガシーエンコーディングと Unicode の対応表が、
> ‘いくつか’必要である、というのがわたしの考えです。
>
> 過去のデータは全て捨ててしまえ・・・とは言いませんよね?
> #システムは捨ててしまえ、というのもありでしょうが。
>
> そのうえで、Shift_JIS だけでいいじゃんとか、
> Shift_JIS と CP932 の違いは大きいよ、という話になるでしょう。

基本的には,レガシーエンコーディングしか扱えないシステムと,Unicode 
ベースのシステムが混在する際の問題は解決しなければいけないと考えていま 
すし,基本的にEUCやShift-JISの変種は主にその相互変換に使われると思って 
います.

しかし,それとは関係ない部分で,単に扱える文字レパートリーを増やすこと 
が目的で新しい符号化文字集合をデファクト化しようとするとしたら違う話 
で,別のよりよい方法がすでにオーソライズされている場合には,そちらを使 
う方向の努力の方がよいと思います.たぶん,元の記事もそういう意図だと思 
います.

少なくとも,「より多くの文字を扱いたい」は,日本を含めた漢字を扱うアジ 
ア圏の人間の願いなわけですが,それなら今はJIS X 0213は無視できないし, 
また従来の機種依存文字が,機種依存文字でない形で扱える,しかも従来は 
Windowsとは非互換の機種依存文字のマッピングを採用していたMac OS Xなど 
でも正しく表示できるということは重要だと思います.

なお,顧客の強引な要求でどうしても危険な実装をしなければいけない時もあ 
るでしょう(今回指摘されたMozilla関係のOSSプロダクトで実際に実装したの 
は,たぶん元Netscapeの国際化部門の知りあいでしょう(笑))が,そのよう 
な特殊な要求に応じられるようにAPIを整備することは必要だと思いますが, 
その場合には危険な実装は局所化すべきでしょう.

> Java 方面で Shift_JIS がCP932 の alias になった騒ぎがありましたが、
> 騒ぎになる程度の違いは両者にある、と。
> (これもまたえらく主観的ですが)

それの騒ぎに関係したのは私だったりします(笑).

それで,結論ありきで議論を始めるよりも,まず既存の文字符号化を今よりさ 
らに詳しく分析して,その違いを明らかにすることが重要ではないかと思いま 
す.できれば,Unicodeへのマッピングが違う部分はどこなのかを一覧表にす 
るのは有効だと思います.また同じ符号化文字集合であってもOSSプロダクト 
によってマッピングが違うということはないかということも一度確認すること 
も必要な気がします.
---
風間 一洋 (kazam****@mac*****)





Legacy-Encoding-talk-ja メーリングリストの案内
Back to archive index