\x{0}A がマッチしない。後ろにあるのが \x{0}\x{0} だとしっかりマッチするんだけど。■比較したのは ver.2.00となんだけど、こちらも、HIGH SURROGATEの直後にパターン \x{0}A で表される文字列がくる場合に限りマッチしない。直後でなければマッチするし、直後でもそれが \x{0}\x{0} で表される文字列とパターンであればマッチするし、HIGH SURROGATEが LOW SURROGATEであってもやはりマッチする。■ということを VC++の L"\xD8D8\xDCDC\0A" みたいなリテラル文字列をちょっとずつ修正しながら確かめたんだけど、コンパイルされるから実際の文字コード・バイト列はよくわからんよね。Windowsでワイド文字っていうと Unicodeであり、Windowsで Unicode(符号化文字集合だが符号化方式を指したりもする)っていうと UTF-16LEなんだろうけど。←ここでは BOMの有無を規定していない。こんな勝手なお約束をグローバルルールにしようなんて考えてるとしても無理筋ですよ>「UTF-16LE符号化スキーム／16ビット整数をリトルエンディアンで直列化する。バイト順マーク (BOM) は使用不可。」 使用不可！ 無理に決まってんじゃん。そんな期待予測予断を誰かに抱かせようという試みが既に有害だわ。LEは little endianの略で、さっきのは目に見えない情報を UTF-16というエンコーディング名の後にメモ書きしただけですからね。■２種類のパターンの選び方に特に意味はなくて、「U+0000 U+0000 U+0041(大文字A) U+0000」の４文字を多数含むバイナリファイルを置換・整形してるときに気づいたってだけ。エディタは UTF-8で解釈してるからファイルにあるのは 00 00 41 00 の４バイトで(※Stirlingで確かめた)、エディタの内部表現とコンパイラのワイド文字列リテラルが wchar_t列で 0000 0000 4100 0000 だと思う(※たぶん UTF-16LE。LEのバイトオーダーってたぶんこうだよね。sizeof (wchar_t) == 2 なのは処理系依存で VC++だからだってね)。■ところで、サクラエディタがファイルを UTF-8のバイトストリームとして読み込んだとき、文字を構成しない不正なバイトは CCodeBase::BinToText によって「バイナリ１バイトを U+DC00 から U+DCFF までに対応付け」られるらしいことが、ちょろっとソースを読んだ限りでは窺われるんだけど、マッチを見失わせるペアを構成しないサロゲートってこうして生まれるんだね……。