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

成瀬です。

Yukihiro Matsumoto wrote:
> |RFC 2781 の 4.3 Interpreting text labelled as UTF-16 では、
> |BOM を見て判別 → BOM がなかったら big endian と解釈する。(SHOULD)
> |となっています。
> |http://www.ietf.org/rfc/rfc2781.txt
> 
> イマドキはそういうものなのですね。私の若い頃はエンディアンが
> 指定していない場合はネーティブエンディアンであると見なすと言
> われていたように思うのですが(曖昧な記憶)。

transformation format ですからねぇ。ネットワークバイトオーダーはビッグエ
ンディアンになりますし。

> |RFC 2781 の 4.3 Interpreting text labelled as UTF-16 では、
> |BOM を見て判別 → BOM がなかったら big endian と解釈する。(SHOULD)
> |となっています。
> 
> というルールに従うとして、それを今のRuby M17Nの延長線上で、エ
> ンコーディング名に指定するというのがどういうことになるか考え
> てみると
> 
> = open(read)のモードとして
>   BOMを見て判別
>         →  UTF-16だけ先頭2バイトを読み込むルーチンを追加す
>             る必要あり
>             正直めんどくさい

BOM がない場合をビッグエンディアンにするのは SHOULD なので、逆らってもい
いとは思うのですが（よほどの理由がなければ従うべきでしょうが）、「BOMを
見ろ」には MUST がついてしまっているので、「UTF-16」に対応するならば必須
かなぁと思います。ちなみに、Perl では BOM が来ればそこから推測、BOM がな
いとエラーでした。

断片的なパッチの例ですが、多分こんな感じになるでしょうか。open 直後に見
ちゃった方がいいのかなぁ。

Index: io.c
===================================================================
--- io.c        (revision 14917)
+++ io.c        (working copy)
@@ -2246,6 +2246,20 @@ rb_io_getc(VALUE io)
     if (io_fillbuf(fptr) < 0) {
        return Qnil;
     }
+
+    if (enc != rb_utf16_encoding()) {
+    } else if (fptr->rbuf_off >= 2) {
+       if (fptr->rbuf[0] == 0xFE && fptr->rbuf[0] == 0xFF) {
+           fptr->enc = enc = rb_utf16be_encoding()
+       } else if (fptr->rbuf[0] == 0xFF && fptr->rbuf[0] == 0xFE) {
+           fptr->enc = enc = rb_utf16le_encoding()
+       } else {
+           rb_raise(rb_eIOError, "%X %X is not valid BOM for UTF-16", );
+       }
+    } else {
+       rb_raise(rb_eIOError, "too short input for UTF-16", );
+    }
+
     r = rb_enc_precise_mbclen(fptr->rbuf+fptr->rbuf_off,
fptr->rbuf+fptr->rbuf_off+fptr->rbuf_len, enc);
     if ((n = MBCLEN_CHARFOUND(r)) != 0 && n <= fptr->rbuf_len) {
        str = rb_str_new(fptr->rbuf+fptr->rbuf_off, n);

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


open(write) の場合は、開いてから最初の write の前に 0xFEFF を print する
だけでいいような気も。Perlでは BOM 付き big endian でした。

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

内部で持っている間は BOM をつけておく必要はないと思います。

> ということで、あまり現実的ではないようです。であれば、このルー
> ルを尊重するのであれば
> 
>   そもそもエンディアンなしのUTF-16というエンコーディングは許さない
> 
> というのが唯一の現実的な解のような。
>
> 一方、エンディアンを省略した場合にはネーティブエンディアンを
> 採用するというルールであれば、上記の問題は発生しませんが、無
> 用にネーティブエンディアンなUTF-16を推奨してしまうという問題
> があるといえばありますね。

思うに、「UTF-16」の価値は読み込み時に BOM を見てバイトオーダーを推測し
てくれる点だと思うので、それをしないならばいっそ非サポートの方が混乱が少
ない様に感じます。

-- 
NARUSE, Yui  <[e-mail]>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA