特殊文字シーケンスを使用すると、正規表現に印字不可能な文字を含めることができます。以下を使用してください。\tタブ文字（ASCII 0x09）をマッチさせる場合、\rキャリッジリターン（0x0D）の場合、\nラインフィード（0x0A）の場合。よりエキゾチックな非印刷文字は\a（ベル、0x07）、\e（エスケープ、0x1B）、および\f（フォームフィード、0x0C）です。Windowsのテキストファイルは\r\nを使って行を終端し、UNIXのテキストファイルは\n.

一部のフレーバーでは、\v垂直タブ（ASCII 0x0B）にマッチします。他のフレーバーでは、\v垂直空白文字に一致する短縮形です。これには、垂直タブ、フォームフィード、およびすべての改行文字が含まれます。Perl 5.10、PCRE 7.2、PHP 5.2.4、R、Delphi XE 以降のバージョンでは、これを短縮形として扱います。以前のバージョンでは、不必要にエスケープされたリテラルの v として扱っていました。JGsoft フレーバーは、当初、垂直タブのみに一致しました。\vJGsoft V2は、任意の垂直空白に一致します。\v.

多くの正規表現フレーバーは、トークンもサポートしています。\cAから\cZASCII制御文字を挿入します。バックスラッシュの後の文字は常に小文字の c です。2 番目の文字は大文字の A から Z で、Control+A から Control+Z を示します。これらは\x01から\x1A（10進数の26）に相当します。例:\cMはキャリッジリターンに一致します。\r, \x0Dと同様に、\u000Dほとんどのフレーバーでは、2 番目の文字を小文字にすることができ、意味に違いはありません。Javaのみが、A から Z を大文字にする必要があります。

文字以外の文字を\cの後で使用することはお勧めしません。これは、アプリケーション間で動作が矛盾しているためです。一部では、\cの後ろに任意の文字を許可する一方で、ASCII文字を許可する場合があります。アプリケーションは、コードページまたはUnicodeコードポイントの文字インデックスの最後の5ビットを取得して、ASCII制御文字を形成できます。または、アプリケーションは単にビット0x40を反転させるだけです。どちらの場合でも\c@から\c_は制御文字0x00から0x1Fに一致します。しかし\c*は、ラインフィードまたは文字jと一致する可能性があります。アスタリスクはASCIIテーブルの文字0x2Aであるため、下位5ビットは0x0Aで、ビット0x40を反転させると0x6Aになります。メタ文字は、確かに\cをサポートするアプリケーションでは、直後に意味を失います。\cAから\cZ制御文字と一致させるためのものです。オリジナルのJGsoftフレーバー、.NET、および XRegExp はより賢明です。\cの後の文字以外のものをエラーとして扱います。

XMLスキーマ正規表現とXPathでは、\c短縮文字クラスであり、XML名で使用できる任意の文字に一致します。

JGsoftフレーバーは、当初\cAから\cZを制御文字として扱いました。しかし、JGsoft V2は\cをXML短縮形として扱います。

正規表現エンジンがUnicodeをサポートしている場合は、以下を使用できます。\uFFFFまたは\x{FFFF}Unicode文字を挿入します。ユーロ通貨記号は、UnicodeコードポイントU+20ACを占めています。キーボードで入力できない場合は、次の正規表現で挿入できます。\u20ACまたは\x{20AC}。Unicodeコードポイントのマッチングの詳細については、Unicodeに関するチュートリアルセクションを参照してください。

正規表現エンジンがUnicodeではなく8ビットコードページで動作する場合は、作業している文字セットでの位置がわかっていれば、正規表現に任意の文字を含めることができます。Latin-1文字セットでは、著作権記号は文字0xA9です。したがって、著作権記号を検索するには、次を使用できます。\xA9。タブを検索する別の方法は、次を使用することです。\x09。先頭のゼロは必須です。Tcl 8.5以前では、この構文に注意する必要があります。これは、Tclが\xの後ろにあるすべての16進文字を食い尽くし、最後の4つをUnicodeコードポイントとして扱っていたためです。したがって\xA9ABC20ACはユーロ記号に一致します。Tcl 8.6は、最初の2つの16進数字のみを\xの一部として取得します。他のすべての正規表現フレーバーと同様に、\xA9ABC20ACは、©ABC20AC.

改行

\Rは、Unicode改行を含む任意の改行に一致する特殊なエスケープです。特別なのは、CRLFペアを不可分なものとして扱うことです。\Rのマッチング試行が文字列内のCRLFペアの前で始まる場合、単一の\Rは、CRLFペア全体に一致します。\Rは、CRLFペア内のCRのみに一致するようにバックトラックしません。したがって、\Rが単独のCRまたは単独のLFに一致するのに対し、\R{2}または\R\Rは、単一のCRLFペアに一致できません。最初の\Rは、CRLFペア全体に一致し、2番目のペアに一致するものが何も残っていません。

または少なくとも、それは\Rがどのように機能するはずかです。JGsoft V2、Ruby 2.0以降、Java 8、およびPCRE 8.13以降ではそのように機能します。Java 9では、\R\Rが単一のCRLFペアに一致できるバグが導入されました。PCRE 7.0から8.12には、\R{2}が単一のCRLFペアに一致できるバグがありました。Perlには、同じ結果をもたらす別のバグがあります。

ことに注意してください。\Rは、CRLFペアに一致するために前方のみを検索します。正規表現\r\Rは、単一のCRLFペアに一致できます。\rがCRを消費した後、残りの単独のLFは、\Rに一致する有効な改行です。この動作は、すべてのフレーバーで一貫しています。

8進数エスケープ

多くのアプリケーションでは、\0377または\377の形式の8進エスケープもサポートされています。ここで、377は文字セット内の文字の位置の8進数表現です（この場合は10進数で255）。バックスラッシュの後に許可または必須の8進数の桁数、先頭のゼロが必要か許可されていないか、\0追加の桁なしでNULLバイトと一致するかどうかについては、正規表現フレーバー間に多くのばらつきがあります。一部のフレーバーでは、これが\1から\77は、正規表現にいくつのキャプチャグループがあるかに応じて、8進エスケープ1から63（10進数）または後方参照1から77（10進数）にすることができます。したがって、正規表現でこれらの8進エスケープを使用することは強くお勧めしません。代わりに16進エスケープを使用してください。

Perl 5.14、PCRE 8.34、PHP 5.5.10、およびR 3.0.3は、新しい構文\o{377}を8進エスケープ用にサポートしています。中括弧の間には、先頭にゼロがあってもなくても、任意の数の8進数を指定できます。後方参照との混同はなく、それに続くリテラル数字は、閉じ中括弧によってきれいに区切られます。中括弧の間には8進数字のみを入れるように注意してください。Perlでは、\o{whatever}はエラーではなく、NULLバイトに一致します。

JGsoftフレーバーは、当初、\0377の形式で8進エスケープをサポートしていました。JGsoft V2は、\o{377}をサポートし、\0377の後の文字以外のものをエラーとして扱います。

正規表現構文と文字列構文

多くのプログラミング言語は、ソースコード内のリテラル文字列の構文で、印字不可能な文字に対して同様のエスケープをサポートしています。次に、このようなエスケープは、文字列が正規表現エンジンに渡される前に、コンパイラーによって実際の文字に変換されます。正規表現エンジンが同じエスケープをサポートしていない場合、正規表現がファイルから読み取られた場合、またはユーザー入力から受信した場合と比較して、ソースコードでリテラル文字列として指定された正規表現を使用する場合、動作に明らかな違いが生じる可能性があります。たとえば、POSIX正規表現はこれらのエスケープをサポートしていません。ただし、Cプログラミング言語は、\nや\x0Aのようなエスケープを文字列リテラルでサポートしています。したがって、POSIXライブラリを使用してCでアプリケーションを開発する場合、\nは、正規表現を文字列リテラルとしてソースコードに追加した場合にのみ改行として解釈されます。次に、コンパイラーは\nを解釈し、正規表現エンジンは実際の改行文字を認識します。コードがファイルから同じ正規表現を読み取った場合、正規表現エンジンは\nを認識します。実装によっては、POSIXライブラリはこれをリテラルnとして、またはエラーとして解釈します。実際のPOSIX標準では、バックスラッシュが前に付いた「普通の」文字の動作は「未定義」であると述べられています。

同様の問題は、Python 3.2 およびそれ以前のバージョンにもUnicodeエスケープにおいて存在します。\uFFFFPythonは、UnicodeサポートがPythonに追加されて以来、(Unicode)文字列リテラルの一部としてこの構文をサポートしてきました。しかし、Pythonのreモジュールは、\uFFFFPython 3.3以降でのみサポートしています。Python 3.2およびそれ以前では、\uFFFF正規表現を(Unicode)文字列リテラルとしてPythonコードに追加すると動作します。しかし、Python 3.2スクリプトがファイルやユーザー入力から正規表現を読み込む場合、\uFFFFは、uFFFF文字通り正規表現エンジンが見るように\uエスケープされたリテラルとしてu.