NARUSE, Yui
narus****@airem*****
2006年 4月 10日 (月) 06:42:09 JST
成瀬です。 Tadamasa Teranishi wrote: > 受け取り側の対応コード以外のものが送られてくれば、それは想定外のデータ > でしょう。 > で、CP-932, EUC-JP, UTF-8 ぐらいは対応していても、CP51932 とかは > 想定していないケースがほとんどかと。 > # CP51932 を想定していたのなら、それなりに対処もしているでしょうし。 どの範囲のユーザを想定するのかという話になってしまいますが、 「JIS X 0208」という言葉をしらない人が「EUC-JP」を指定した場合、 想定しているのは「ひらがなとか漢字とか」程度なので、 想定内か想定外かというのははっきりしないかと。 >>> もし、そのような文字を使いたいのであれば、そもそもアプリケーションを >>> UTF-8 で設計すべきではないか、と思います。 >> これから作るならばそうなりますね。 > > いや、今でも使いたいなら UTF-8 に移行すべきであって、CP51932 とか > で使おうとするのが良いことではないだろうと思います。例え、使える > ようになったとしてもです。 システムが複数のモジュールから構成されていて、 かつそのモジュールのうちいくつかが UTF-8 非対応の場合、 モジュールを置き換えるまで延命が必要でしょう。 >>> CP932 と eucJP-ms と それ以外とではかなり事情が違うと思います。 >>> CP932 に関しては Shift_JIS と使い分けているといえるでしょう。 >>> しかし、それ以外はそうかどうかは疑問が残ります。 >> eucJP-ms の事情がご理解いただけるのならば、 >> それは環境の違いかと思います。 >> わたしは eucJP-ms より CP51932 の方が欲しいくらいなので。 > > その理由を説明していただけますか? > > CP51932 を使っているのは IE (および他のブラウザ?)から送られてくる > データぐらいしか知りませんが、他にありますか? Windows のテキストエディタで、ファイルを EUC-JP として保存した場合、 それは CP51932 ですね。 >>>> けれど、説得力のあるニーズを示すデータは難しいですね。 >>> ... >>>> しかし、他に「数字」が出る指標があるかというと、うーん。。。 >>> ようするに裏づけされたデータがないということで、なんとなくそうなん >>> じゃないかという感覚的なものなのでしょう。 >> いえ、わたし自身は CP51932 は意図して使っています。 > > それは成瀬さんがということであって、相当の人がということには > なりませんよね。 > (使い分けている人がいないと言っているのではなくて、相当の人が > 使い分けているかどうかは疑問があると言っているわけですから。) 使い分けている人は現状多くは無いと思います。 が、自分の思っていた「EUC-JP」が実は CP51932 だった、 という人はかなり多いのではないでしょうか。 # Windows で 3バイト EUC を扱えるエディタってあまりないですし。 >> むしろ、eucJP-ms より CP51932 の方が使いますね。 >> # ゲイツ側の人間なので。 > > Windows よりの設計をするのはわからないわけではないですが、自ら公言され > ては、設計が偏っていると受け取られかねないですよ。 > # Windows はもちろん無視できるわけではありませんが。 自分が偏っていることを自覚しているので、あえて公言し、 誰かが補正してくださることを期待しています。 その点、寺西さんには本当に感謝しています。 >>> CP932 とかは生かさなければならないでしょうけど、CP51932 を生かさ >>> なければならないか(個々の事情で生かさなければならない場合はあるで >>> しょうけれども)というのは疑問です。 >> 例えば CGI/Perl は EUC-JP で書く習慣がありましたから、 >> 掲示板のログ等で潜在的に CP51932 のデータが大量に眠ってはいます。 > > つまり現状死んでいるわけです。 Windows から「日本語 (EUC)」として読めば普通に見れますから、 「死んでいる」は語弊があるかと。 “dying”ではありますな。 >> その大量のデータのうち、どの程度の割合が残すに値するかの判断は、 >> わたしにはつきかねます。 >> # が、自分の管理している範囲では全て残しますね。 > > 現状死んでいるデータを本当に生かしたいですか? > CP51932 のデータは、本当に全てCP51932 のデータなのでしょうか? > 他のEUC系のコードと混在していたりしませんか? > 生かそうとしてはまったりすることはないのでしょうか? CP51932 と eucJP-ms が混在しているというのは、ありえますし、 厄介なシナリオですが、読み出しに限れば、 eucJP-ms のユーザ定義文字領域を NEC選定IBM拡張文字とみなす、 というバッドノウハウは可能ですね。 > 両方向提供すること自体は必ずしも悪いわけではありませんが、 > それにより、レガシーエンコーディングのまま、より悪い方向で拡張された > アプリケーションが増えてしまって、かえって Unicode への移行を妨げる > ことになるのではないかと懸念します。(と、レガシーエンコーディング > のデータが増えて、移行の際により混乱を拡大しそうです。) > > 両方向提供するのと同時に、レガシーエンコーディングへの変換は最小限 > に注意して使うようにするのと、Unicode への移行を推奨するといった > 内容を含むガイドライン等を示す必要があるのではないかと思います。 あくまでレガシーであるというのを強調するのはいいですね。 Shift_JIS や EUC-JP がレガシーであることを、 （知るべきなのに）まだ知らない人って多そうですし。 > 遠い将来はそうでしょうが、レガシーエンコーディングの環境が整うと、 > しばらくレガシーエンコーディングのまま使い続ける可能性も出てくる > ような気がします。 > そこを心配しているわけです。 環境を整えなかった場合、 全面的にレガシーなシステムのまま限界まで使い、 一二の三で一気に Unicode、というシナリオになるのでしょうが、 それですと、MySQL 4.1 の二の舞になるように思います。 http://www.mysql.gr.jp/mysqlml/mysql/msg/12372 >>> ついでに。 >>> シェアの問題でしょうけれども Windows のコード中心なのも気になります。 >>> Macintosh は? とか、携帯電話の絵文字は? とかもあるわけです。 >>> 特に携帯電話は無視できる数ではないので、Windows のコードだけ考えて >>> いても...という気もします。 >> Macintosh は？というツッコミはわたしも考えたのですけれど、 >> 実際にニーズを伴った発言はなぜか見かけませんね。 > > Macintosh ユーザは歴史的にものわかりが良くて、困っていてもそんなもの > だと割り切って使う人が多いですからね。そうじゃないと、Windows じゃ > なくてわざわざ Mac を使ったりしませんし。 思うに、Windows の機種依存データは外の環境に出て行きやすいが、 Mac の機種依存データは Mac の環境内で処理され、外に出てこないので、 問題が顕在化しづらいのかもしれません。 # Mac 上では MAC-JAPANESE に対応した iconv があるので -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
