[ruby-core:19064] Fwd: [ruby-dev:36523] Re: Encoding.default_internal

There has been some disconnect lately between ruby-dev and ruby-core
about default_internal. For a while, I planned to help out a bit,
but didn't get around to it until today.

Basically, what happened was that in [ruby-dev:36523], Matz made a new,
far-reaching proposal re. default_internal. Since then, various details
(as well as the proposal itself) have been discussed extensively on
ruby-dev.

I'll try to translate the salient points of the proposal below.
Please try to read the whole mail before responding; the discussion
has moved ahead considerably on details that are not covered here.

>Date: Thu, 25 Sep 2008 00:49:10 +0900
>From: Yukihiro Matsumoto <[e-mail]>
>Subject: [ruby-dev:36523] Re: Encoding.default_internal  のためのパッチ
>To: [e-mail] (ruby developers list)

>まつもと ゆきひろです
>
>In message "Re: [ruby-dev:36517] Re: Encoding.default_internal         のためのパッチ"
>    on Wed, 24 Sep 2008 21:23:48 +0900, "NARUSE, Yui" <[e-mail]> writes:
>
>|Martin Duerst wrote:
>|> [ruby-core:18774] に Michael Selig から Encoding::default_internal
>|> の提案がありました。

[Martin:]
In ruby-core:18774, there was a proposal from Michael Selig re.
Encoding::default_internal.

>|まつもとさんに昼ごろ聞いたところ、まだ思案中のようです。

[Yui:]
I asked matz around noon, but he was still thinking about it.

>|結局 default_internal ってのは multi-locale を指向する
>|Ruby からすると逆行する存在なので、難しいところではあります。

[Yui:]
Because default_internal goes against Ruby's basic multi-locale
orientation, it may be difficult [to introduce default_internal].

[from here on, Matz; comments in [] by the translator]

>今日一日考えて、導入することにしました。

I thought about this for a full day, and decided to introduce it.

>以下のような仕様を考えています。

I'm thinking about the following spec:

>* default_internalはIOでinternalを指定しなかった場合のエンコー
>  ディングである

default_internal is used as the internal encoding for an IO
if the internal incoding is not specified.

>* これが指定されている時IOからの入力は(バイナリでない限り)、
>  このエンコーディングを持つ(必要なら変換する)。

If default_internal is used, unless it's binary, the input from
an IO will carry the encoding of default_encoding (transcoded
if necessary).

>* default_internalも-Eオプションで指定する。指定書式は

default_internal can be specified with the -E option, as follows:

>  -E iso-2022-jp:utf-8
>
>  のように「:」で区切ったものとする。default_externalとして
>  localeを指定したい時には、空のdefault_externalを指定するた
>  めに

Two encodings are separated by a colon. In the case of using the
locale as default_external, default_external can be left empty:

>  -E :utf-8
>
>  のように書く。逆にdefault_internalへの変換を抑制するために
>  は、空のdefault_internalを指定して

If you want to avoid using default_internal, you can leave it blank:

>  -E iso-2022-jp:
>
>  のように書く。旧来の「-E euc-jp」は「-E euc-jp:」と同じ意
>  味になる。

The current -E euc-jp and -E euc-jp: have the same meaning.


>* (重要)なにも指定しない場合のdefault_externalはlocale。
>  default_internalは「UTF-8」。

IMPORTANT: The default for default_external is the locale.
The default for default_internal is UTF-8.

>* 新設の-Lオプションを指定するとdefault_externalはlocale、
>  default_internalは空になる。

With a new option -L, default_external is locale, and
default_internal is empty [i.e. no conversion].

>* (未定)Dirなどが返すパス名はdefault_externalから
>  default_internalへの変換が行われる。ただし、変換エラーが発
>  生した場合、文字が化けるのは避けたい(バイナリで返すか)。

(Undecided) Data such as path names returned from Dir will
be converted from default_external to default_internal.
However, if there is a conversion error, to avoid 'mojibake',
the data will be returned as binary.


>背景

Background

>ここ数週間真剣に考えてきましたが、内部コードにUnicodeを使わな
>い理由はかなり減っていると思います。

I was thinking about this seriously for several weeks, but
I think that the reasons for not using Unicode as an internal
code have decreased considerably.

>各種変換テーブルはラウン
>ドトリップするように設計されていますし、各種コストも開発当初
>(8年以上前)はともかく現在では無視できるレベルになっています。

The various conversion tables are made so that round-trip
conversion is possible, and the various costs, compared
to when [the current multilingual architecture] was developped,
have come to a negligible level.

>そこで、内部コードUnicode(UTF-8)を支援しつつ、必要であれば無
>変換テキスト処理やより広い文字集合(の実験)も可能である仕様を
>模索しました。

Therefore, I was considering a specification that would support
Unicode (UTF-8) as an internal code, while making possible
text processing without conversion and (experiments with)
wider character sets.

>結果、デフォルトでは外部エンコーディングをロケー
>ルから取得、内部エンコーディングはUTF-8としました。

As a result, I made the defaults for external encodings
dependent on the locale, and the default for internal
incodings UTF-8.

>しかし、ロ
>ケールに従ったテキストデータを変換なしに処理したいニーズもそ
>れなりにあるでしょうから(特に書き捨てのプログラム)、そのため
>に「-L」オプションを新設しました。

However, (especially for "write and forget" programs), there
should be a considerable need for processing text data without
conversion, and for that, I introduced the -L option.

>Unicode以外のエンコーディン
>グを内部エンコーディングに使いたい場合には明示的に-Eを使えば
>よいわけです。

In case you want to use a non-Unicode encoding as the internal encoding,
you can use -E explicitly.

>この結果、各種ライブラリは

As a result, each library

> * 基本UTF-8を返せばよい、入力もUTF-8を期待

- basically can return UTF-8, and can expect UTF-8 as input

> * より親切なライブラリはdefault_internalで返す。入力は
>   encodingを見て対処

- more friendly libraries will return default_internal,
  and will check the encoding on input

>という二段階対応ができます。段階的に前者(レベル1)から、後者
>(レベル2)に移行すればよいのではないでしょうか。

This will allow a two-step approach. We can move step-by-step
from the former (level 1) to the later (level 2).

>現在では基本Unicodeで構わないとは思いますが、パス名については
>変換に伴うデータロスでファイルが見つけられない事態を避けるこ
>とを考えなければなりません。

Currently, I don't think there should be problems with using
Unicode as a base, but we have to consider how to avoid not
finding a file when there is data loss due to a conversion
of a path name.

>上では「未定」と書いていますが、
>「変換に失敗した時にはバイナリ」というのが現実的な対処ではな
>いかと思います。

I wrote "undefined" above, but I think "use binary if
conversion fails" may be a realistic approch.

>もちろんこれらの変更は本日のfeature freezeには間に合いません
>が、悲鳴をあげたものだと見なしてください。

Of course, this change doesn't meet today's feature freeze
deadline, but please consider this as a request for a delay.

>できるだけ早急に
>1.9.1に取り込もうと思います。

I will try to integrate this as quickly as possible into 1.9.1.

>急いで考えたものなので見落とし
>があるかもしれません。

Because I was thinking about this in a hurry, there may be
some things that I overlooked.

>その場合は遠慮なく指摘してください。

In that case, please point this out without hesitation.

>これにともない、UTF-{16,32}対応はencから外した方がよいかもし
>れないと思うようになりました。

In connection with this, I started to think it might be a good
idea to remove UTF-{16,32} from enc.

[That proposal was later abandoned when U. Nakamura brought
up a case where he had to lightly process megabytes of UTF-16LE
data, where conversion, if used, extended processing time by
a factor of two.]

>これらはUTF-8とは符号化方式の
>違いしかありません。

They only differ from UTF-8 in terms of encoding scheme.

>まったくデータロスなしに変換できる以上、
>対応するメリットは大きくなく、混乱のデメリット(たとえばCSVラ
>イブラリがUTF-16対応に苦労した)の方が大きそうです。

They can be converted without any data loss, and therefore
the merrit of dealing with them isn't big compared to the
demerit of confusion (e.g. how the CSV library has had
problems dealing with UTF-16).

>                                直前で申し訳ない

               Sorry [for sending this out] just before [the feature freese]

>                                まつもと ゆきひろ /:|)

                               Matz

[Regards,    Martin.]


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp     mailto:[e-mail]