[ruby-dev:32960] Re: Shift_JIS variants and UTF-16 support

まつもと ゆきひろです

In message "Re: [ruby-dev:32959] Re: Shift_JIS variants and UTF-16 support"
    on Mon, 7 Jan 2008 19:18:44 +0900, "NARUSE, Yui" <[e-mail]> writes:

|Yukihiro Matsumoto wrote:
|> エンディアンが指定されてい
|> ない"UTF-16"を使えるようにするかどうかは決めていませんが、お
|> そらくはプラットフォームのエンディアンを見て、別名として定義
|> するのではないかと思います。
|
|RFC 2781 の 4.3 Interpreting text labelled as UTF-16 では、
|BOM を見て判別 → BOM がなかったら big endian と解釈する。(SHOULD)
|となっています。
|http://www.ietf.org/rfc/rfc2781.txt

イマドキはそういうものなのですね。私の若い頃はエンディアンが
指定していない場合はネーティブエンディアンであると見なすと言
われていたように思うのですが(曖昧な記憶)。

まあ、それはそれとして、

|RFC 2781 の 4.3 Interpreting text labelled as UTF-16 では、
|BOM を見て判別 → BOM がなかったら big endian と解釈する。(SHOULD)
|となっています。

というルールに従うとして、それを今のRuby M17Nの延長線上で、エ
ンコーディング名に指定するというのがどういうことになるか考え
てみると

= open(read)のモードとして
  BOMを見て判別
        →  UTF-16だけ先頭2バイトを読み込むルーチンを追加す
            る必要あり
            正直めんどくさい

= open(write)のモードとして
  文字列ひとつひとつにBOMが付いているとは考えにくい
        → writeではエラーということ？
           特別扱いはめんどくさい

= String#encodeの引数として
  文字列一つ一つにBOMはないだろう。
        → encodeではエラーということ？
           特別扱いはめんどくさい

ということで、あまり現実的ではないようです。であれば、このルー
ルを尊重するのであれば

  そもそもエンディアンなしのUTF-16というエンコーディングは許さない

というのが唯一の現実的な解のような。

一方、エンディアンを省略した場合にはネーティブエンディアンを
採用するというルールであれば、上記の問題は発生しませんが、無
用にネーティブエンディアンなUTF-16を推奨してしまうという問題
があるといえばありますね。

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