From: Yukihiro Matsumoto Date: 2008-09-25T00:49:10+09:00 Subject: [ruby-dev:36523] Re: Encoding.default_internal のためのパッチ まつもと ゆきひろです In message "Re: [ruby-dev:36517] Re: Encoding.default_internal のためのパッチ" on Wed, 24 Sep 2008 21:23:48 +0900, "NARUSE, Yui" writes: |Martin Duerst wrote: |> [ruby-core:18774] に Michael Selig から Encoding::default_internal |> の提案がありました。 | |まつもとさんに昼ごろ聞いたところ、まだ思案中のようです。 | |結局 default_internal ってのは multi-locale を指向する |Ruby からすると逆行する存在なので、難しいところではあります。 今日一日考えて、導入することにしました。 以下のような仕様を考えています。 * default_internalはIOでinternalを指定しなかった場合のエンコー ディングである * これが指定されている時IOからの入力は(バイナリでない限り)、 このエンコーディングを持つ(必要なら変換する)。 * default_internalも-Eオプションで指定する。指定書式は -E iso-2022-jp:utf-8 のように「:」で区切ったものとする。default_externalとして localeを指定したい時には、空のdefault_externalを指定するた めに -E :utf-8 のように書く。逆にdefault_internalへの変換を抑制するために は、空のdefault_internalを指定して -E iso-2022-jp: のように書く。旧来の「-E euc-jp」は「-E euc-jp:」と同じ意 味になる。 * (重要)なにも指定しない場合のdefault_externalはlocale。 default_internalは「UTF-8」。 * 新設の-Lオプションを指定するとdefault_externalはlocale、 default_internalは空になる。 * (未定)Dirなどが返すパス名はdefault_externalから default_internalへの変換が行われる。ただし、変換エラーが発 生した場合、文字が化けるのは避けたい(バイナリで返すか)。 背景 ここ数週間真剣に考えてきましたが、内部コードにUnicodeを使わな い理由はかなり減っていると思います。各種変換テーブルはラウン ドトリップするように設計されていますし、各種コストも開発当初 (8年以上前)はともかく現在では無視できるレベルになっています。 そこで、内部コードUnicode(UTF-8)を支援しつつ、必要であれば無 変換テキスト処理やより広い文字集合(の実験)も可能である仕様を 模索しました。結果、デフォルトでは外部エンコーディングをロケー ルから取得、内部エンコーディングはUTF-8としました。しかし、ロ ケールに従ったテキストデータを変換なしに処理したいニーズもそ れなりにあるでしょうから(特に書き捨てのプログラム)、そのため に「-L」オプションを新設しました。Unicode以外のエンコーディン グを内部エンコーディングに使いたい場合には明示的に-Eを使えば よいわけです。 この結果、各種ライブラリは * 基本UTF-8を返せばよい、入力もUTF-8を期待 * より親切なライブラリはdefault_internalで返す。入力は encodingを見て対処 という二段階対応ができます。段階的に前者(レベル1)から、後者 (レベル2)に移行すればよいのではないでしょうか。 現在では基本Unicodeで構わないとは思いますが、パス名については 変換に伴うデータロスでファイルが見つけられない事態を避けるこ とを考えなければなりません。上では「未定」と書いていますが、 「変換に失敗した時にはバイナリ」というのが現実的な対処ではな いかと思います。 もちろんこれらの変更は本日のfeature freezeには間に合いません が、悲鳴をあげたものだと見なしてください。できるだけ早急に 1.9.1に取り込もうと思います。急いで考えたものなので見落とし があるかもしれません。その場合は遠慮なく指摘してください。 これにともない、UTF-{16,32}対応はencから外した方がよいかもし れないと思うようになりました。これらはUTF-8とは符号化方式の 違いしかありません。まったくデータロスなしに変換できる以上、 対応するメリットは大きくなく、混乱のデメリット(たとえばCSVラ イブラリがUTF-16対応に苦労した)の方が大きそうです。 直前で申し訳ない まつもと ゆきひろ /:|)