コンピュータ内部では、文字ではなく数値で処理を行います。テキストファイルを保存する際、各文字は数値にマッピングされ、その数値がディスクに保存されます。テキストファイルを開く際には、数値が読み込まれて文字にマッピングし直されます。正規表現でテキストを処理する場合、正規表現は、処理対象のファイルや文字列を作成する際に使用したのと同じマッピングを使用する必要があります。

通常、正規表現に文字をすべて入力するだけであれば、心配することはありません。正規表現機能を提供するアプリケーションやプログラミングライブラリは、対象文字列が使用しているテキストエンコーディングを認識し、それに応じて処理を行います。たとえば、ユーロ通貨記号を検索したい場合で、ヨーロッパのキーボードをお持ちであれば、AltGr+Eを押すだけです。あなたの正規表現€は、すべてのユーロ記号を正しく検出します。

しかし、USキーボードではAltGr+Eを押すことはできません。または、ソースコードを7ビットクリーン（つまりプレーンASCII）にしたい場合もあるでしょう。そのような場合は、正規表現で文字エスケープを使用する必要があります。

正規表現エンジンがUnicodeをサポートしている場合は、Unicodeエスケープを以下のように使用します。\u20AC(ほとんどのUnicodeフレーバー) または\x{20AC}(Perl および PCRE)。U+20ACはユーロ記号のUnicodeコードポイントです。対象文字列がUTF-8、UTF-16、UCS-2などのどのエンコーディングでエンコードされていても、常にユーロ記号と一致します。対象文字列がレガシーな8ビットコードページでエンコードされている場合でも、混乱はありません。アプリケーションや正規表現エンジンに、ファイルがどのエンコーディングを使用しているか伝える必要があるかもしれません。しかし\u20ACは常にユーロ記号です。

ほとんどのUnicode正規表現エンジンは、8ビット文字エスケープもサポートしています。\xFFしかし、その使用は推奨されません。文字\x00から\x7Fまでは通常、問題はありません。最初の128個のUnicodeコードポイントは、ほとんどの8ビットコードページのベースとなるASCIIテーブルと同一です。

しかし、\x80以上については解釈が異なる場合があります。純粋なUnicodeエンジンは、これを\u0080と同一に扱い、これはLatin-1の制御コードを表します。しかし、ほとんどの人が期待するのは、\x80がユーロ記号と一致することです。これは、すべてのWindowsコードページで80hの位置を占めているからです。テキストファイルがWindowsコードページを使用してエンコードされている場合、8ビットの正規表現エンジンを使用すると一致します。

ほとんどの人が\x80をUnicodeコードポイント\u0080ではなく、8ビット文字として扱うと期待するため、一部のUnicode正規表現エンジンはまさにそのように動作します。一部は、8ビット文字コードを解釈するために、特定のコードページ（たとえば、Windows 1252やコンピュータのデフォルトコードページ）を使用するようにハードワイヤードされています。

他のエンジンでは、入力文字列に依存します。Just Great Software のアプリケーションでは、\x80は、Unicodeテキストファイルを検索するときは\u0080として、Windows 1252テキストファイルを検索するときは\u20ACとして扱われます。 ここに魔法はありません。テキストファイルのエンコーディングに関係なく、テキストファイルのインデックス80hの文字に一致します。 UnicodeコードポイントU+0080はLatin-1の制御コードですが、Windows 1252の文字インデックス80hはユーロ記号です。逆に、テキストエディタでユーロ記号を入力し、UTF-16LEとして保存すると、2バイトAC 20が保存され、Windows 1252として保存すると、1バイト80.

が保存されます。 もし上記の内容が混乱を招く場合は、Unicodeをサポートする正規表現エンジンで\x80から\xFFを使用しないでください。

8ビット正規表現エンジン

8ビットデータのみを扱うレガシー（廃止された？）正規表現エンジンを使用する場合は、\u20AC. \x80しかありません。 最新のエンジンにもレガシーモードがあることに注意してください。たとえば、人気のある正規表現ライブラリであるPCREは、デフォルトで8ビットエンジンとして実行されます。Unicode機能を使用する場合は、明示的にUTF-8サポートを有効にする必要があります。有効にすると、PCREは対象文字列をUTF-8に変換することも期待します。

8ビットエンジン用の正規表現を作成する際は、どの文字セットまたはコードページを使用するかを考慮する必要があります。8ビット正規表現エンジンは気にしません。正規表現に\x80と入力すると、そのバイトが何を表すかに関係なく、任意のバイト80hと一致します。Windows 1252テキストファイルではユーロ記号、Latin-1ファイルでは制御コード、EBCDICファイルでは数字のゼロになります。

正規表現内のリテラル文字の場合でも、正規表現で使用しているエンコーディングと対象エンコーディングを一致させる必要があります。アプリケーションがLatin-1コードページを使用しており、正規表現Àを使用した場合、Latin-2テキストファイルを検索するとŔと一致します。アプリケーションは、間違ったコードページを使用しているため、これを画面にÀとして表示します。 この問題は、正規表現に固有のものではありません。異なる8ビットエンコーディングを使用するファイルやアプリケーションを操作する場合は、いつでもこの問題が発生します。

したがって、8ビットデータを操作する場合は、実際に操作するデータを16進数エディタで開いてください。使用されているバイトを確認し、それらを正規表現で指定してください。

非常に厄介なのは、8ビットエンジンでUnicodeファイルを処理する場合です。ユーロ記号のみを含むテキストファイルに戻りましょう。リトルエンディアンUTF-16（Windowsでは「Unicode」と呼ばれる）として保存すると、8ビット正規表現エンジンは2バイトAC 20(リトルエンディアンはバイトを反転させることを忘れないでください) を検出します。UTF-8（エンディアンがない）として保存すると、8ビットエンジンは3バイトE2 82 ACを検出します。8ビット正規表現エンジンを使用してUTF-8ファイル内のユーロ記号を一致させるには、\xE2\x82\xACが必要になります。