您可以使用特殊字元序列在正規表示式中放入非列印字元。使用 \t 來配對 tab 字元 (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 風味 最初只使用 \v 符合垂直標籤。JGsoft V2 使用 \v 符合任何垂直空白。

許多正規表示式風味也支援代碼 \cA 到 \cZ 以插入 ASCII 控制字元。反斜線後的字母永遠是小寫 c。第二個字母是大寫字母 A 到 Z，表示 Control+A 到 Control+Z。這些等於 \x01 到 \x1A (26 進位)。例如 \cM 符合回車，就像 \r、\x0D 和 \u000D 一樣。大多數風味允許第二個字母是小寫，意義沒有不同。只有 Java 要求 A 到 Z 為大寫。

不建議在 \c 後使用字母以外的字元，因為不同應用程式之間的行為不一致。有些允許在 \c 後使用任何字元，而另一些則允許 ASCII 字元。應用程式可能會取用該字元索引在編碼頁或其 Unicode 編碼點中的最後 5 個位元，以形成 ASCII 控制字元。或者應用程式可能只會翻轉位元 0x40。無論哪種方式，\c@ 到 \c_ 都會符合控制字元 0x00 到 0x1F。但 \c* 可能會符合換行符或字母 j。星號在 ASCII 表中是字元 0x2A，因此較低的 5 個位元是 0x0A，而翻轉位元 0x40 會得到 0x6A。在支援 \cA 到 \cZ 以符合控制字元的應用程式中，元字元確實會在 \c 後立即失去其意義。原始的 JGsoft 風味、.NET 和 XRegExp 較為明智。它們將 \c 後的任何非字母字元視為錯誤。

在 XML Schema 正規表示式 和 XPath 中，\c 是 速記字元類別，符合 XML 名稱中允許的任何字元。

JGsoft 風味 最初將 \cA 到 \cZ 視為控制字元。但 JGsoft V2 將 \c 視為 XML 速記。

如果您的正規表示式引擎支援 Unicode，您可以使用 \uFFFF 或 \x{FFFF} 來插入 Unicode 字元。歐元貨幣符號佔用 Unicode 編碼點 U+20AC。如果您無法在鍵盤上輸入它，您可以使用 \u20AC 或 \x{20AC} 將其插入正規表示式中。請參閱 Unicode 教學部分，以取得關於 符合 Unicode 編碼點 的更多詳細資訊。

如果您的正規表示式引擎使用 8 位元組碼頁而非 Unicode，則只要知道您正在使用的字元集中的字元位置，就可以在正規表示式中包含任何字元。在 Latin-1 字元集中，版權符號是字元 0xA9。因此，若要搜尋版權符號，可以使用 \xA9。搜尋 tab 的另一種方式是使用 \x09。請注意，需要前導零。在 Tcl 8.5 及更早版本中，您必須小心使用此語法，因為 Tcl 過去會使用 \x 之後的全部十六進位字元，並將最後 4 個字元視為 Unicode 碼點。因此，\xA9ABC20AC 會符合歐元符號。Tcl 8.6 僅將前兩個十六進位數字視為 \x 的一部分，就像其他所有正規表示式風格一樣，因此 \xA9ABC20AC 符合 ©ABC20AC。

換行符號

\R 是一個特殊跳脫字元，可以符合任何換行符號，包括 Unicode 換行符號。它的特殊之處在於將 CRLF 對視為不可分割的。如果 \R 的符合嘗試在字串中的 CRLF 對之前開始，則單一的 \R 會符合整個 CRLF 對。\R 不會回溯以僅符合 CRLF 對中的 CR。因此，雖然 \R 可以符合單獨的 CR 或單獨的 LF，但 \R{2} 或 \R\R 無法符合單一的 CRLF 對。第一個 \R 會符合整個 CRLF 對，沒有留下任何東西讓第二個符合。

或者至少，這就是 \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 可以符合的有效換行符號。此行為在所有風格中是一致的。

八進位跳脫字元

許多應用程式也支援八進位跳脫字元，形式為 \0377 或 \377，其中 377 是字元在字元集中的位置的八進位表示（此例中為十進位 255）。在反斜線之後允許或需要多少個八進位數字、是否需要或不允許前導零，以及沒有額外數字的 \0 是否符合 NULL 位元組，在不同的正規表示式風格之間有很大的差異。在某些風格中，這會造成複雜性，因為 \1 到 \77 可以是八進位跳脫字元 1 到 63（十進位）或 反向參照 1 到 77（十進位），具體取決於正規表示式中有多少個 擷取群組。因此，強烈建議不要在正規表示式中使用這些八進位跳脫字元。請改用十六進位跳脫字元。

Perl 5.14、PCRE 8.34、PHP 5.5.10 和 R 3.0.3 支援八進制跳脫字元的語法 \o{377}。大括號中可以包含任意數量的八進制數字，可以有或沒有前導零。不會與後向參照混淆，後面的數字會由大括號清楚分隔。請務必只在括號中放置八進制數字。在 Perl 中，\o{whatever} 沒有錯誤，但會比對 NULL 位元組。

JGsoft 風格 最初以 \0377 的形式支援八進制跳脫字元。JGsoft V2 支援 \o{377}，並將 \0377 視為錯誤。

正規表示式語法與字串語法

許多程式語言在原始碼中字串文字的語法中，支援類似用於非列印字元的跳脫字元。然後這些跳脫字元會在字串傳遞給正規表示式引擎之前，由編譯器轉換成實際的字元。如果正規表示式引擎不支援相同的跳脫字元，可能會導致在原始碼中將正規表示式指定為字串文字時，與從檔案讀取或從使用者輸入接收的正規表示式在行為上產生明顯差異。例如，POSIX 正規表示式 不支援任何這些跳脫字元。但 C 程式語言在字串文字中支援 \n 和 \x0A 等跳脫字元。因此，在使用 POSIX 函式庫開發 C 應用程式時，\n 只有在將正規表示式作為字串文字新增到原始碼時，才會被解釋為換行符號。然後編譯器會解釋 \n，而正規表示式引擎會看到實際的換行字元。如果您的程式碼從檔案讀取相同的正規表示式，則正規表示式引擎會看到 \n。根據實作，POSIX 函式庫會將其解釋為字面上的 n 或錯誤。實際的 POSIX 標準指出反斜線前面接「一般」字元的行為是「未定義」。

Python 3.2 及更早版本中存在類似的問題，使用 Unicode 跳脫字元 \uFFFF。自從 Unicode 支援新增到 Python 以來，Python 就支援此語法作為 (Unicode) 字串文字的一部分。但 Python 的 re 模組 僅從 Python 3.3 開始支援 \uFFFF。在 Python 3.2 及更早版本中，\uFFFF 在將正規表示式作為文字 (Unicode) 字串新增到 Python 程式碼時會運作。但當 Python 3.2 程式碼從檔案或使用者輸入讀取正規表示式時，\uFFFF 會比對 uFFFF，因為正規表示式引擎將 \u 視為跳脫字面 u。