\u エスケープ

[19] Unicode符号位置を \uHHHH のようにエスケープする方法が色々な場面で使われます。

BMP 符号位置の符号化

[20] U+0000-U+FFFF の符号位置は、 \u の後に4桁のASCII十六進数字で符号位置を表すことによって表現できます。

[22] 十六進数字として大文字と小文字のどちらを用いるか (両方認められるか) は、使われる文脈によります。

[21] 何をエスケープ形で表し、何をエスケープしないで表すかは、使われる文脈によります。

非 BMP 符号位置の符号化

[23] U+10000 以上の符号位置の表現方法は、いくつかの流儀があります。

[24] 古くから使われている方法では、 \U の後に8桁の十六進数字で符号位置を指定します。この方法は UCS の31ビットすべての符号位置を表現できます。 (BMP をこの方法でも表現できるかどうかは、文脈によります。)

[25] 場合によっては、 \U の後に6桁の十六進数字で符号位置を指定します。この方法は Unicode の21ビットすべての符号位置を表現できます。 (BMP をこの方法でも表現できるかどうかは、文脈によります。)

[26] この2つの方法は、混在させることができません。

[27] UTF-16 を使う環境では、サロゲートペアに相当する2つの符号位置の \uHHHH 形で非 BMP 符号位置を表現する場合があります。

エラー処理

[28] エラー処理の方法は、文脈によります。困ったことに、明確に規定していない場合もあります。

[29] 少なくても次のようなエラー状況を想定する必要があります。

[30] \uHHHH など適切な形式にならずに途切れている \ などが出現した場合の扱い
[31] 値域外の符号位置の扱い (Unicode の範囲外の \U12345678 のようなものなど)
[32] サロゲートの符号位置の扱い (サロゲートを認めない場合、サロゲート自体とエスケープされたサロゲートの組で現れた場合、単独のサロゲートが現れた場合)
[33] 非文字の扱い

十六進記法 (Unicode 正規表現)

[37] Unicode正規表現においては、十 (じゅう) 六 (ろく) 進 (しん) 記 (き) 法 (ほう) (Hex Notation) の実装が要求されています。 >>36

[38] 十六進記法は、 16進数表現によって任意のUnicode符号点 [ U+0000, U+10FFFF ] を指定できなければなりません。 >>36 RL1.1

[48] サロゲート符号点や非文字も含まれています。

[39] 特定の構文の実装までは要求されておらず、既存の正規表現構文の自然な拡張が想定されているようです。しかしながら、符号点を16進数で表したものでなくてはならず、 UTF-8 バイト列や UTF-16符号単位の16進数表現ではこの要件を満たせません >>36。

[40] U+1D11E を \U0001D11E, \x{1D11E}, \u{1D11E} のように表せます。 >>36

[41] 記法例として、次のような構文が定められています。 >>36

[42] \u の後に4つのASCII十六進数字
- [45] ASCII十六進数字のUnicode符号点を表します。
[43] \u{ の後に符号点の並びの後に }
- [44] 符号点は1から5個のASCII十六進数字か 10 の後に4個の ASCII十六進数字
- [46] 符号点の並びは1個以上の符号点を SP で区切ったもの
- [47] 符号点のUnicode符号点を順に並べたものを表します。

[36] UTS #18: Unicode Regular Expressions, 2022-02-08T14:02:12.000Z, 2022-11-13T03:56:15.819Z https://unicode.org/reports/tr18/#Hex_notation

`\uHHHH` (Java)

[1] Java の \u 符号化 (UnicodeEscape) http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#100850 http://java.sun.com/docs/books/jls/first_edition/html/3.doc.html#100850 http://www.y-adagio.com/public/standards/tr_javalang2/lexical.doc.html http://www.y-adagio.com/public/standards/tr_javalang/3.doc.htm

[2] >>1 を ABNF に翻訳すると、

[3] UnicodeEscape = "\" 1*('u') 4HEXDIGIT

[4] Mozilla でも使われていて、 x-u-escaped と呼ばれている。

[5] U+10000 〜をどう表現するのかは不明。

[6] JavaSDK に native2ascii というのが入ってます。これを使って変換します。
[7] >>3 にあるように \uu4E00 みたいな書き方が可能 (意味は >>1 参照。) なの (は Java 以外の実装、例えば Mozilla とかが対応しているのか) と、 >>5 の疑問があるのですが、なんせ "\u" なんてどこの検索円陣にも掛からないし、さぱーりわからない。
[8] Java や Mozilla とは関係なしに、各種言語・表記法などで、従来の \x などのオクテット表現方法の延長として \uHHHH が使われることがよくあります。
[9] >>8 のような場合で、 U+FFFF より大きいのを表現する方法は、 \UHHHHHH を使う方法と \UHHHHHHHH を使う方法があります。 (後者がお勧め。) ほかにサロゲートを使ってがんばる処理系もあるかもしれませんが、萎え萎え。

[10] >>5-9 Java では \UHHHHHH とするようです。

Supplementary Characters in the Java Platform http://java.sun.com/developer/technicalArticles/Intl/Supplementary/

`\uHHHH` (JavaScript)

[11] JavaScript の正規表現で \u の後に十六進数が4桁続かない場合、 ES3 によると構文エラーのはずですが、どのブラウザでも、 \ がなかった場合と同じように処理されます。

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0Adocument.write%20(%22u1%22.match(%2F%5E%5Cu1%24%2F)%3F1%3A0)%3B%0A%3C%2Fscript%3E

`\u'HHHH'` (RFC 5137)

[12] RFC 5137 (BCP 137) は、 Unicode 文字を escape するための方法で勧められるものを2つ挙げています。そのうちの1つが ¥u'HHHH' のような書式です。

   EmbeddedUnicodeChar =  %x5C.75.27 4*6HEXDIG %x27
      ; starting with lowercase "\u" and "'" and ending with "'".
      ; Note that the encodings are considered to be abstractions
      ; for the relevant characters, not designations of specific
      ; octets.

   HEXDIG =  "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
      "A" / "B" / "C" / "D" / "E" / "F"

RFC 5234のABNF を用いているので、十六進数の大文字・小文字は区別しません。 (「\u」の部分は小文字でなければなりません。)

[13] RFC 5137 はこの他 XML の十六進数文字参照も勧めています。 C 式の「\uHHHH」/「\UHHHHHHHH」表記、 Perl 風の「¥x{H}」表記、 Java 式の「\uHHHH」+ 代理組表記は「通常は勧められない」としています。 (C 式が勧められないのは、終わりを表す区切子がないため。)

[14] RFC 5137 - ASCII Escaping of Unicode Characters (2015-07-26 17:06:08 +09:00 版) https://tools.ietf.org/html/rfc5137#section-5.1

[15] draft-klensin-encoded-word-type-u-00 - The "U" Encoding for Encoded-Words in Email (2016-01-11 02:26:53 +09:00 版) https://tools.ietf.org/html/draft-klensin-encoded-word-type-u-00

[16] この方法が IETF 以外で使われるのは見たことがありません。 IETF は世間一般で広く普及した形式を奇妙にアレンジするのが好きなようです。