From: "U.Nakamura" Date: 2008-11-13T18:45:22+09:00 Subject: [ruby-dev:37089] Re: [Feature #747] /\A/u ignores BOM こんにちは、なかむら(う)です。 In message "[ruby-dev:37088] Re: [Feature #747] /\A/u ignores BOM" on Nov.13,2008 18:13:39, 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