NARUSE, Yui
narus****@airem*****
2006年 4月 7日 (金) 11:58:01 JST
成瀬です。 Tadamasa Teranishi wrote: > 現状、うまく使えていないであろう文字(おそらくは想定外の入力データ)を > 生かす必要があるのかどうか。 想定外というか、思うにどのような文字が来るか、 「想定」していないのが実情かなと。 > もし、そのような文字を使いたいのであれば、そもそもアプリケーションを > UTF-8 で設計すべきではないか、と思います。 これから作るならばそうなりますね。 > どうしてもデータを生かしたいのなら > >> そのまま CP51932 として生かさないといけない、とは思っていません。 >> 多少平行運用を行わなければならない場合もあるでしょうが、 >> 多くの場合は、 >> nkf --overwrite --ic=CP51932 --oc=UTF-8 >> 一回の利用だろうとは思っています。 > > のように移行する際に1回データを変換するだけで良いような気がします。 > それは代表的なコード変換プログラムがサポートしさえしておれば良く、 > 多くのアプリケーションがサポートしなければならないことではない > ように思います。 自分で文字コード変換を抱えているソフトウェアですと、 その「一回」にぶつかってしまう可能性はありますね。 iconv に丸投げしているならばアプリケーション自身が 意識する必要はありませんけれど。 Ruby 2.0 のように CSI ならばともかく、UCS 正規化を行っているならば、 基本的には意識してサポートする必要は無いでしょう。 # 現状 UCS 正規化（広義）はしていても、Shift_JIS で正規化とか、 # EUC で正規化とかが多そうですけれど :-) > CP932 と eucJP-ms と それ以外とではかなり事情が違うと思います。 > CP932 に関しては Shift_JIS と使い分けているといえるでしょう。 > しかし、それ以外はそうかどうかは疑問が残ります。 eucJP-ms の事情がご理解いただけるのならば、 それは環境の違いかと思います。 わたしは eucJP-ms より CP51932 の方が欲しいくらいなので。 >> けれど、説得力のあるニーズを示すデータは難しいですね。 > ... >> しかし、他に「数字」が出る指標があるかというと、うーん。。。 > > ようするに裏づけされたデータがないということで、なんとなくそうなん > じゃないかという感覚的なものなのでしょう。 いえ、わたし自身は CP51932 は意図して使っています。 むしろ、eucJP-ms より CP51932 の方が使いますね。 # ゲイツ側の人間なので。 >>> メールに限らず UTF-8 化に力を注ぐほうが、より健全だろうと思います。 >> UTF-8 化の前提として、既存データの UTF-8 化が存在し、 >> それを行うのにレガシーエンコーディングと Unicode の対応表が、 >> ‘いくつか’必要である、というのがわたしの考えです。 >> >> 過去のデータは全て捨ててしまえ・・・とは言いませんよね？ >> ＃システムは捨ててしまえ、というのもありでしょうが。 > > 過去のデータの全てを生かさなければならないとは思わないということです。 > 生かすデータを選別しても良いのではないかということです。 生かすデータの選別は、何らかの形で行われるでしょうね。 ただ、それはアプリケーションの与り知らない、 もっと上のレイヤーで行われることだと考えます。 # そのために数字は出しづらいわけで。 実装コスト等の理由で、そのような選択肢を残さず切ってしまうか、 選別の余地を残すのかは、わたしには判断付きかねます。 # で、結局 CP51932 は自分のニーズで実装したわけです > CP932 とかは生かさなければならないでしょうけど、CP51932 を生かさ > なければならないか(個々の事情で生かさなければならない場合はあるで > しょうけれども)というのは疑問です。 例えば CGI/Perl は EUC-JP で書く習慣がありましたから、 掲示板のログ等で潜在的に CP51932 のデータが大量に眠ってはいます。 その大量のデータのうち、どの程度の割合が残すに値するかの判断は、 わたしにはつきかねます。 # が、自分の管理している範囲では全て残しますね。 > 機種依存文字等を含む場合は、 > UTF-8 への変換は移行する際に必要でも、UTF-8 からの変換は CP932 > ぐらいに絞らないと余計混乱するのではないかと思います。 > > 例えば、CP51932 や ISO-2022-JP-MS で出力するアプリケーションが増えて、 > 世の中にそのようなデータが増える方向に動きはしないかと懸念します。 > (コード変換プログラムは除く) > CP51932 や ISO-2022-JP-MS で出力する場合には、慎重に行うべきでしょう。 > それよりは UTF-8 で処理する方向で動いて欲しいと願います。 ある程度同意します。 多くの標準で、レガシーエンコーディングから Unicode への、 一方向のマッピングしか公開されていないのはそのような意図なのでしょう。 しかし、わたしは特に思想を持たず、両方向提供した上で、 後は神の見えざる手にまかせちゃえばいいや、と思ってしまったりも。 今更そんな絞らなくても、UTF-8 にできる部分は UTF-8 になるだろう、 と楽天的に考えています。 CSS の大きさにしても、CES としての設計にしても、 UTF-8 の優位性は明らかなので。 > ついでに。 > シェアの問題でしょうけれども Windows のコード中心なのも気になります。 > Macintosh は? とか、携帯電話の絵文字は? とかもあるわけです。 > 特に携帯電話は無視できる数ではないので、Windows のコードだけ考えて > いても...という気もします。 Macintosh は？というツッコミはわたしも考えたのですけれど、 実際にニーズを伴った発言はなぜか見かけませんね。 もっとも、MAC-JAPANESE はメンテナンスされている対応表が存在するので、 あとは実装だけという気もします。 http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT # あー、でも0x5C -> U+00A5 なのかー 携帯の絵文字はニーズが結構あるようですが、 これの対応表は・・・あるんですかね？ Vodafone が公開しているのは見つけましたが、 http://www.vodafone.jp/3G/live/mail/pict_convert.html どのようにUnicodeの仕様領域に割り当てるか等、 なんらかの標準は欲しいですね、すでにあるのかな？ # 各社が Unicode との対応は公開しているものの、 # au と Vodafone は領域重なってるし・・・。 -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
