NARUSE, Yui
narus****@airem*****
2006年 5月 22日 (月) 05:59:16 JST
成瀬です。 Nozomi Ytow wrote: > "NARUSE, Yui" <narus****@airem*****> wrote: > >> 基本的に CP* というのは Unicode 対応表のことである、 >> とわたしは理解しているので、根拠になるかと。 > > その対応表の、Unicode でない方の集合は、何と呼べば > 良いのでしょうか。 CP* に対応する文字集合、じゃないですかね。 CP932 でしたら Windows-31J でしょうが。 >> そもそも、このプロジェクトはLegacy Encodingを >> 使いやすくするプロジェクトではなく、 >> Legacy Encodingをなるべく早期に混乱なく葬る >> プロジェクトのはずですので、 > > 「使いやすくする」かどうかはさておき、早期に葬るなら > サポートしないというのが正解でしょう。 サポートしなかったら既存のデータは移行できませんね。 > 「基本仕様書」の 0.1 版では相互変換が目的とされて > います。 ISO-2022-JP-MS に象徴されるように、 このプロジェクトはしばしば目的と手段が混同されている気がします。 相互変換が目的ならば、円記号・波ダッシュ問題は 課題には上がらないはずです。 > 「既存の物まで含めて全部 UTF-8 に移せ」というのは > 現実的でないというのが背景にある認識だと思うのですが > 違いましょうか。 「今すぐ移せ」を加え、「背景にある」を削れば同意します。 >> VSについては、正式な規格と衝突する可能性は少なそうですが、 >> 外字まがいの手法であることは確かです。 >> そのような裏技的な手法をこのプロジェクトで用いるのには反対です。 > > 裏技的かどうかが重要なのではなく、工夫すれば区別できるものを > 区別できなくしてしまう事を仕様とするかどうかが重要でしょう。 仕様としてしまうのが妥当かと思います。 どうしても区別したい場合は、文字コードのレイヤーでなく、 一つ上のレイヤーで区別したほうが幸せになれるかなーと。 >> 「内部処理用」というのが言い訳にならないことは、 >> Shift_JISやEUCが外部に流れてしまっている事例等もありますし。 > > たとえば mule コードを外部的に積極的には使っている人というのを > 聞いたことはないのですが、それはさておき、「流れてしまっている」 > のは流した人の責任ではないでしょうか。包丁と殺人の関係と似た > 様なものでしょう。 Mule と iconv は少々事情が異なると感じます。 基本的にMule は Mule コードをそのまま外に流すようなことはしませんよね。 libiconv の場合は外に流れるケースが少なからずあるかと思います。 >> 実装指向なプロジェクトであると解しています。 >> レガシーから移行する際に必要な情報を集めて公開し、 >> また移行に必要な実装を提供するプロジェクトであると。 > > だったら Unicode へのコンバータ作るだけで良いのでは。 > それで解決すれわけないでしょ、というのが、このプロジェクトの > 必要性の一つだと理解していますが。 Unicode へのコンバータ作るだけで実装自体は終わりますね。 それだけで相互変換も可能になりますし。 -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
