NARUSE, Yui
narus****@airem*****
2006年 5月 22日 (月) 15:51:20 JST
成瀬です。 Nozomi Ytow wrote: > "NARUSE, Yui" <narus****@airem*****> wrote: > >>> その対応表の、Unicode でない方の集合は、何と呼べば >> CP* に対応する文字集合、じゃないですかね。 >> CP932 でしたら Windows-31J でしょうが。 > > そうですか、知りませんでした。 > Unicode サポートしてなかったころからコードページと言っていた > 記憶があったので、「コードページ(code page)とは文字セットのこと」 > というマイクロソフトの説明を鵜呑みにしていました。 > http://msdn2.microsoft.com/ja-JP/library/2x8et5ee.aspx 確かに由来はそうですし、語義もそうですが、 XMLにおけるencodingと同じものと理解しています。 >>> 裏技的かどうかが重要なのではなく、工夫すれば区別できるものを >>> 区別できなくしてしまう事を仕様とするかどうかが重要でしょう。 >> 仕様としてしまうのが妥当かと思います。 >> どうしても区別したい場合は、文字コードのレイヤーでなく、 >> 一つ上のレイヤーで区別したほうが幸せになれるかなーと。 > > うーん。round trip や source code separation は > 優先順位が高いと私は思いますが、人それぞれなのですね。 高いのは確かですが、重複符号化された文字まで分ける必要があるかというと、 疑問には感じます。 >> Mule と iconv は少々事情が異なると感じます。 >> libiconv の場合は外に流れるケースが少なからずあるかと思います。 > > どうやって? アプリケーションからlibiconvを用いて、文字列を CP932からNEC特殊文字とIBM拡張文字を区別するUnicodeに変換し、 そのままその文字列を外に流しちゃう人って絶対いますよね。 >> Unicode へのコンバータ作るだけで実装自体は終わりますね。 >> それだけで相互変換も可能になりますし。 > > では iconv が今回対象の文字コードをサポートしているのだから > もういい事になってしまうのでは? Perl/Encode等はiconvを使いませんから。 これらが自前で抱えているコンバータにも手を入れませんと。 -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
