[#37050] [Feature #735] Date#inspect — "rubikitch ." <redmine@...>

Feature #735: Date#inspect

14 messages 2008/11/09

[#37075] [Feature #747] /\A/u ignores BOM — Shyouhei Urabe <redmine@...>

Feature #747: /\A/u ignores BOM

14 messages 2008/11/12

[#37161] m17n of irb — "Yugui (Yuki Sonoda)" <yugui@...>

Yuguiです。

35 messages 2008/11/24
[#37183] Re: m17n of irb — keiju@... (keiju ISHITSUKA) 2008/11/25

けいじゅ@いしつかです.

[#37203] Re: m17n of irb — "Yugui (Yuki Sonoda)" <yugui@...> 2008/11/26

keiju ISHITSUKA さんは書きました:

[#37292] Re: m17n of irb — Yukihiro Matsumoto <matz@...> 2008/12/06

まつもと ゆきひろです

[#37293] Re: m17n of irb — "Yugui (Yuki Sonoda)" <yugui@...> 2008/12/07

Yuguiです。

[#37298] Re: m17n of irb — Yukihiro Matsumoto <matz@...> 2008/12/07

まつもと ゆきひろです

[#37210] RSS::Maker.create(version) — "Akinori MUSHA" <knu@...>

 RSS::Maker で、 "2.0" 等の文字列でフィードのフォーマットを渡す

15 messages 2008/11/27

[#37213] Re: [ruby-cvs:27586] Ruby:r20368 (trunk): * ext/bigdecimal/bigdecimal.c (BigDecimal_div2): should return — Tadayoshi Funaba <tadf@...>

> * ext/bigdecimal/bigdecimal.c (BigDecimal_div2): should return

8 messages 2008/11/27

[ruby-dev:37089] Re: [Feature #747] /\A/u ignores BOM

From: "U.Nakamura" <usa@...>
Date: 2008-11-13 09:45:22 UTC
List: ruby-dev #37089
こんにちは、なかむら(う)です。

In message "[ruby-dev:37088] Re: [Feature #747] /\A/u ignores BOM"
    on Nov.13,2008 18:13:39, <konishih@fd6.so-net.ne.jp> wrote:
> 大体分かってきたような気がします。普通にopenで読み込んだ場合は2.(=A)なの
> ですね。でStringオブジェクトに変換した場合は、エンコーディングを持つ(B)
> と。

あー、普通、というか、エンコーディングを指定せずにファイルを
オープンした場合はlocaleのエンコーディングを指定したとみなさ
れます。
ので、2.(=A)にはならないで、おそらく間違ったエンコーディング
が付与された文字列が生成されてしまうと思われます。

なので、正常系としては、明示的にエンコーディングとしてバイナ
リ列(ASCII-8BIT)が指定されるか、明示的にUTF-16LEまたはUTF-16BE
が指定されるか、いずれかしかありえません。


> やはり、正規表現を使うのであれば、Bの状態でBOMを付けない方が良いと思いま
> す。あえてAの状態で先頭マッチを行う場合でも、「文字列」という本義を考え
> るとBOMまでマッチさせるのには違和感を感じます。

そういえば、/\A/に対する私の意見を述べていませんでした。

バイナリ列に対する正規表現マッチにおいては、BOMというものはな
い(zero width non breaking spaceという文字もない)ので、BOMで
あったはずのデータ("\xfe\xff"または"\xff\xfe")が/\A/にマッチ
することはありえないと私も思います。

Bの場合、BOMがBOMであると判明しているならばそれが/\A/にマッチ
してもおかしいとは思わないのですが、既に読み込まれた文字列に
おいて冒頭の"\ufeff"がBOMだったのか単にzero width non breaking
spaceだったのかを区別することは不可能でしょうから、/\A/でマッ
チさせるのにはやはり無理があるのではないかと思います。
# /\A/の意味は変えずに「先頭および先頭の"\ufeff"にマッチする
# 特殊文字」を別途導入するのはありえないこともないと思います。

が、まあ、やはり先に提案したとおり、最初にBOMが自動的に読み捨
てられるopenを用意するのが無難だろうと思います。


それでは。
-- 
U.Nakamura <usa@garbagecollect.jp>


In This Thread