Unicode は、現存および過去のすべての言語のすべての文字とグリフを定義することを目的とした文字セットです。ますます多くのソフトウェアが複数の言語、あるいはあらゆる言語をサポートする必要があるため、近年、Unicode は急速に普及しています。異なる言語に異なる文字セットを使用することは、プログラマーやユーザーにとって非常に面倒です。

残念ながら、Unicode は正規表現に関しては独自の要件と落とし穴をもたらします。このチュートリアルで説明した正規表現フレーバーのうち、Java、XML、および.NETは Unicode ベースの正規表現エンジンを使用しています。Perl はバージョン 5.6 から Unicode をサポートしています。PCRE はオプションで Unicode サポートを有効にしてコンパイルできます。PCRE は、その名前「Perl 互換」にもかかわらず、\pトークンに対して許容される内容において、柔軟性がはるかに低いことに注意してください。PCRE に基づく PHP preg 関数は、正規表現に /u オプションが追加されると Unicode をサポートします。Ruby はバージョン 1.9 から正規表現で Unicode エスケープとプロパティをサポートしています。XRegExp は、JavaScript に Unicode プロパティのサポートをもたらします。

RegexBuddy の正規表現エンジンは、バージョン 2.0.0 から完全に Unicode ベースになっています。RegexBuddy 1.x.x は Unicode をまったくサポートしていませんでした。PowerGREP は、バージョン 3.0.0 から同じ Unicode 正規表現エンジンを使用しています。以前のバージョンでは、8 ビット（つまり非 Unicode）の正規表現エンジンで grep する前に、Unicode ファイルを ANSI に変換していました。EditPad Pro は、バージョン 6.0.0 から Unicode をサポートしています。

文字、コードポイント、および書記素、または Unicode がどのように物事を混乱させるか

ほとんどの人はàを単一の文字と考えるでしょう。残念ながら、「文字」という言葉の意味によっては、必ずしもそうである必要はありません。

このチュートリアルで説明されているすべての Unicode 正規表現エンジンは、単一の Unicodeコードポイントを単一の文字として扱います。このチュートリアルでドットが単一の文字に一致すると説明されている場合、これは Unicode 用語では「ドットは単一の Unicode コードポイントに一致する」と解釈されます。Unicode では、àは、2つのコードポイントとしてエンコードできます。U+0061 (a) の後に U+0300 (グレイブアクセント) が続きます。この状況では、.をàに適用すると、aアクセントなしで一致します。^.$は、文字列が2つのコードポイントで構成されているため、一致に失敗します。^..$はà.

に一致します。Unicode コードポイント U+0300 (グレイブアクセント) は、結合文字です。結合文字ではないコードポイントの後に、任意の数の結合文字を続けることができます。上記の U+0061 U+0300 のようなこのシーケンスは、画面上に単一の書記素として表示されます。

残念ながら、àは、単一の Unicode コードポイント U+00E0 (グレイブアクセント付きの a) でエンコードすることもできます。この二重性の理由は、多くの歴史的な文字セットが「グレイブアクセント付きの a」を単一の文字としてエンコードしているためです。Unicode の設計者は、マークと基本文字を分離するという Unicode の方法（これにより、レガシー文字セットでサポートされていない任意の組み合わせが可能になります）に加えて、一般的なレガシー文字セットとの一対一のマッピングがあると便利だと考えました。

単一の Unicode 書記素を一致させる方法

単一の書記素を、単一のコードポイントとしてエンコードされているか、結合文字を使用して複数のコードポイントとしてエンコードされているかに関係なく、Perl、PCRE、PHP、Boost、Ruby 2.0、Java 9、および Just Great Software アプリケーションで一致させるのは簡単です。単に\Xを使用します。あなたは\Xをドットの Unicode バージョンと考えることができます。ただし、1つ違いがあります\Xは常に改行文字と一致しますが、ドットはドットが改行に一致する一致モードを有効にしない限り、改行文字と一致しません。

.NET、Java 8以前、および Ruby 1.9 では、\P{M}\p{M}*+または(?>\P{M}\p{M}*)を妥当な代替として使用できます。任意の数の書記素に一致させるには、(?>\P{M}\p{M}*)+を\X+.

の代替として使用します。

特定のコードポイントとの一致特定の Unicode コードポイントに一致させるには、\uFFFFを使用します。ここで、FFFF は、一致させたいコードポイントの 16 進数です。常に 4 桁の 16 進数を指定する必要があります。例：はà\u00E0

は、単一のコードポイント U+00E0 としてエンコードされている場合にのみ一致します。Perl、PCRE、Boost、およびstd::regex は、特定の Unicode コードポイントに一致させるには、構文をサポートしていません。これらは代わりに\x{FFFF}を使用します。中かっこで囲まれた 16 進数では、先頭のゼロを省略できます。\x自体は有効な正規表現トークンではないため、\x{1234}が\x1234回一致すると誤解されることは決してありません。常に Unicode コードポイント U+1234 に一致します。\x{1234}{5678}は、コードポイント U+1234 に正確に 5678 回一致しようとします。

Java では、正規表現トークン特定の Unicode コードポイントに一致させるには、は、標準同等性を有効にした場合でも、指定されたコードポイントにのみ一致します。ただし、同じ構文特定の Unicode コードポイントに一致させるには、は、Java ソースコードで Unicode 文字をリテラル文字列に挿入するためにも使用されます。Pattern.compile("\u00E0")は、àの単一コードポイントと二重コードポイントの両方のエンコードに一致しますが、Pattern.compile("\\u00E0")は、単一コードポイントバージョンのみに一致します。Java の文字列リテラルとして正規表現を記述する場合、バックスラッシュをエスケープする必要があることを忘れないでください。前者の Java コードは正規表現àをコンパイルし、後者はを使用します。ここで、FFFF は、一致させたいコードポイントの 16 進数です。常に 4 桁の 16 進数を指定する必要があります。例：をコンパイルします。実行する内容によっては、この違いが重要になる場合があります。

JavaScript は、RegExp クラスを通じて Unicode サポートを提供していませんが、文字列構文の一部として、単一の Unicode コードポイントを一致させるための特定の Unicode コードポイントに一致させるには、をサポートしています。

XML Schema および XPath には、Unicode コードポイントを一致させるための正規表現トークンはありません。ただし、のような XML エンティティを使用して、正規表現にリテラルコードポイントを簡単に挿入できます。

Unicode カテゴリ

Unicode は、複雑さだけでなく、新しい可能性ももたらします。その1つは、各 Unicode 文字が特定のカテゴリに属しているということです。「文字」カテゴリに属する単一の文字を一致させることができます\p{L}を使用します。そのカテゴリに属していない単一の文字を一致させるには、\P{L}.

を使用します。ここでも、「文字」は実際には「Unicode コードポイント」を意味します。\p{L}は、「文字」カテゴリの単一のコードポイントに一致します。入力文字列がàU+0061 U+0300 としてエンコードされている場合、aアクセントなしで一致します。入力がàU+00E0 としてエンコードされている場合、àアクセント付きで一致します。その理由は、コードポイント U+0061 (a) と U+00E0 (à) の両方が「文字」カテゴリにあり、U+0300 が「マーク」カテゴリにあるためです。

これで、\P{M}\p{M}*+が\X. \P{M}と同等である理由が理解できたはずです。一致しないコードポイントをマークし、\p{M}*+は、結合マークであるゼロ個以上のコードポイントに一致します。任意のダイアクリティカルマークを含む文字に一致させるには、\p{L}\p{M}*+を使用します。この最後の正規表現は常にàに、どのようにエンコードされているかに関係なく、一致します。所有量指定子は、バックトラッキングが、後に続く結合マークなしに非マークを一致させないようにします。\P{M}\p{M}*+は、決してそうしないでしょう。\XPCRE、PHP、および .NET は、

トークンの中かっこで囲まれた部分を確認するときに、大文字と小文字を区別します。\pトークン。\p{Zs}はあらゆる種類の空白文字に一致しますが、\p{zs}はエラーをスローします。このチュートリアルで説明されている他のすべての正規表現エンジンは、中かっこで囲まれたカテゴリの大文字と小文字を無視して、両方の場合で空白に一致します。それでも、以下のプロパティのリストで私がやったのと同じ大文字と小文字の組み合わせを使用する習慣を付けることをお勧めします。これにより、正規表現はすべての Unicode 正規表現エンジンで動作するようになります。

標準表記に加えて、\p{L}Java、Perl、PCRE、JGsoft エンジン、および XRegExp 3 では、省略表記\pLを使用できます。省略表記は、一文字の Unicode プロパティでのみ機能します。\pLlは\p{Ll}と同等ではありません。それは\p{L}lと同等で、Alまたはàlまたは、リテラルl.

が続く任意の Unicode 文字に一致します。Perl、XRegExp、および JGsoft エンジンは、長表記\p{Letter}もサポートしています。以下に、すべての Unicode プロパティの完全なリストを示します。アンダースコアを省略したり、代わりにハイフンやスペースを使用したりできます。

• \p{L}または\p{Letter}：任意の言語のあらゆる種類の文字。
  • \p{Ll}または\p{Lowercase_Letter}：大文字のバリアントを持つ小文字。
  • \p{Lu}または\p{Uppercase_Letter}：小文字のバリアントを持つ大文字。
  • \p{Lt}または\p{Titlecase_Letter}：単語の最初の文字のみが大文字で始まる場合、単語の先頭に表示される文字。
  • \p{L&}または\p{Cased_Letter}：小文字と大文字のバリアントが存在する文字（Ll、Lu、Ltの組み合わせ）。
  • \p{Lm}または\p{Modifier_Letter}：文字のように使用される特殊文字。
  • \p{Lo}または\p{Other_Letter}：小文字と大文字のバリアントがない文字または表意文字。
• \p{M}または\p{Mark}：別の文字と組み合わせて使用​​することを目的とした文字（例：アクセント、ウムラウト、囲みボックスなど）。
  • \p{Mn}または\p{Non_Spacing_Mark}：追加のスペースを占有せずに別の文字と組み合わせて使用​​することを目的とした文字（例：アクセント、ウムラウトなど）。
  • \p{Mc}または\p{Spacing_Combining_Mark}：追加のスペースを占有する別の文字と組み合わせて使用​​することを目的とした文字（多くの東部言語の母音記号）。
  • \p{Me}または\p{Enclosing_Mark}：結合する文字を囲む文字（丸、四角、キーキャップなど）。
• \p{Z}または\p{Separator}：あらゆる種類の空白または不可視の区切り文字。
  • \p{Zs}または\p{Space_Separator}：不可視だがスペースを占有する空白文字。
  • \p{Zl}または\p{Line_Separator}：行区切り文字 U+2028。
  • \p{Zp}または\p{Paragraph_Separator}：段落区切り文字 U+2029。
• \p{S}または\p{Symbol}：数学記号、通貨記号、飾り文字、罫線文字など。
  • \p{Sm}または\p{Math_Symbol}：あらゆる数学記号。
  • \p{Sc}または\p{Currency_Symbol}：あらゆる通貨記号。
  • \p{Sk}または\p{Modifier_Symbol}：単独で完全な文字となる結合文字（マーク）。
  • \p{So}または\p{Other_Symbol}：数学記号、通貨記号、結合文字ではない様々な記号。
• \p{N}または\p{Number}：あらゆるスクリプトのあらゆる種類の数字文字。
  • \p{Nd}または\p{Decimal_Digit_Number}：表意文字スクリプトを除くあらゆるスクリプトの 0 から 9 の数字。
  • \p{Nl}または\p{Letter_Number}：ローマ数字のように文字のように見える数字。
  • \p{No}または\p{Other_Number}：上付きまたは下付きの数字、あるいは 0 から 9 の数字ではない数字（表意文字スクリプトの数字を除く）。
• \p{P}または\p{Punctuation}：あらゆる種類の句読点文字。
  • \p{Pd}または\p{Dash_Punctuation}：あらゆる種類のハイフンまたはダッシュ。
  • \p{Ps}または\p{Open_Punctuation}：あらゆる種類の開き括弧。
  • \p{Pe}または\p{Close_Punctuation}：あらゆる種類の閉じ括弧。
  • \p{Pi}または\p{Initial_Punctuation}：あらゆる種類の開き引用符。
  • \p{Pf}または\p{Final_Punctuation}：あらゆる種類の閉じ引用符。
  • \p{Pc}または\p{Connector_Punctuation}：単語を接続するアンダースコアのような句読点文字。
  • \p{Po}または\p{Other_Punctuation}：ダッシュ、括弧、引用符、またはコネクターではないあらゆる種類の句読点文字。
• \p{C}または\p{Other}：不可視の制御文字と未使用のコードポイント。
  • \p{Cc}または\p{Control}：ASCII または Latin-1 の制御文字：0x00～0x1F および 0x7F～0x9F。
  • \p{Cf}または\p{Format}：不可視の書式設定インジケーター。
  • \p{Co}または\p{Private_Use}：プライベート使用のために予約された任意のコードポイント。
  • \p{Cs}または\p{Surrogate}：UTF-16 エンコーディングにおけるサロゲートペアの片方。
  • \p{Cn}または\p{Unassigned}：文字が割り当てられていない任意のコードポイント。

Unicode スクリプト

Unicode 標準では、割り当てられた各コードポイント（文字）を 1 つのスクリプトに配置します。スクリプトとは、特定の人間が書くシステムで使用されるコードポイントのグループです。タイ語のようなスクリプトはタイ語単一の人間言語に対応します。ラテン文字のような他のスクリプトはラテン文字複数の言語にまたがります。

一部の言語は複数のスクリプトで構成されています。日本語の Unicode スクリプトはありません。代わりに、Unicode はひらがな, カタカナ, 漢字、そしてラテン文字日本語の文書が通常構成されるスクリプトを提供します。

特別なスクリプトは共通スクリプトです。このスクリプトには、広範囲のスクリプトに共通するあらゆる種類の文字が含まれています。あらゆる種類の句読点、空白、およびその他の記号が含まれています。

割り当てられたすべての Unicode コードポイント（でマッチングされるもの）\P{Cn}）は、正確に 1 つの Unicode スクリプトの一部です。割り当てられていないすべての Unicode コードポイント（でマッチングされるもの）\p{Cn}）は、どの Unicode スクリプトにも属していません。

JGsoft エンジン、Perl、PCRE、PHP、Ruby 1.9、Delphi、およびXRegExpは、Unicode スクリプトを照合できます。以下にリストを示します。

1. \p{Common}
2. \p{Arabic}
3. \p{Armenian}
4. \p{Bengali}
5. \p{Bopomofo}
6. \p{Braille}
7. \p{Buhid}
8. \p{Canadian_Aboriginal}
9. \p{Cherokee}
10. \p{Cyrillic}
11. \p{Devanagari}
12. \p{Ethiopic}
13. \p{Georgian}
14. \p{Greek}
15. \p{Gujarati}
16. \p{Gurmukhi}
17. \p{Han}
18. \p{Hangul}
19. \p{Hanunoo}
20. \p{Hebrew}
21. \p{Hiragana}
22. \p{Inherited}
23. \p{Kannada}
24. \p{Katakana}
25. \p{Khmer}
26. \p{Lao}
27. \p{Latin}
28. \p{Limbu}
29. \p{Malayalam}
30. \p{Mongolian}
31. \p{Myanmar}
32. \p{Ogham}
33. \p{Oriya}
34. \p{Runic}
35. \p{Sinhala}
36. \p{Syriac}
37. \p{Tagalog}
38. \p{Tagbanwa}
39. \p{TaiLe}
40. \p{Tamil}
41. \p{Telugu}
42. \p{Thaana}
43. \p{Thai}
44. \p{Tibetan}
45. \p{Yi}

Perl および JGsoft フレーバーでは、以下を使用できます\p{IsLatin}の代わりに\p{Latin}。「Is」構文は、次のセクションで説明するように、スクリプトとブロックを区別するのに役立ちます。PCRE、PHP、および XRegExp は「Is」プレフィックスをサポートしていません。

Java 7 は Unicode スクリプトのサポートを追加しました。他のフレーバーとは異なり、Java 7 では「Is」プレフィックスが必要です。

Unicode ブロック

Unicode 標準では、Unicode 文字マップを異なるブロックまたはコードポイントの範囲に分割しています。各ブロックは、「チベット語」のような特定のスクリプトの文字や、「点字パターン」のような特定のグループに属する文字を定義するために使用されます。ほとんどのブロックには、Unicode 標準の将来の拡張のために予約された、割り当てられていないコードポイントが含まれています。

Unicode ブロックはスクリプトと 100% 対応しないことに注意してください。ブロックとスクリプトの重要な違いは、ブロックが以下に示すようにコードポイントの単一の連続した範囲であるということです。スクリプトは、Unicode 文字マップ全体から取得された文字で構成されます。ブロックには、割り当てられていないコードポイントが含まれる場合があります（つまり、でマッチングされるコードポイント）。\p{Cn}）。スクリプトには、割り当てられていないコードポイントは決して含まれません。一般に、Unicode スクリプトを使用するか Unicode ブロックを使用するか不明な場合は、スクリプトを使用してください。

たとえば、通貨ブロックにはドル記号と円記号は含まれていません。それらは、両方が通貨記号であり、円記号がラテン文字ではない場合でも、代わりに Basic_Latin ブロックと Latin-1_Supplement ブロックにあります。これは、ASCII 標準にドル記号が含まれ、ISO-8859 標準に円記号が含まれているという歴史的な理由からです。名前だけに基づいて、以下に示すブロックを盲目的に使用すべきではありません。代わりに、実際に一致する文字の範囲を見てください。RegexBuddyのようなツールは、これに非常に役立ちます。Unicode プロパティ\p{Sc}または\p{Currency_Symbol}は、Unicode ブロックよりも適切な選択肢になります\p{InCurrency_Symbols}すべての通貨記号を見つけようとするとき。

1. \p{InBasic_Latin}：U+0000～U+007F
2. \p{InLatin-1_Supplement}：U+0080～U+00FF
3. \p{InLatin_Extended-A}：U+0100～U+017F
4. \p{InLatin_Extended-B}：U+0180～U+024F
5. \p{InIPA_Extensions}：U+0250～U+02AF
6. \p{InSpacing_Modifier_Letters}：U+02B0～U+02FF
7. \p{InCombining_Diacritical_Marks}：U+0300～U+036F
8. \p{InGreek_and_Coptic}：U+0370～U+03FF
9. \p{InCyrillic}：U+0400～U+04FF
10. \p{InCyrillic_Supplementary}：U+0500～U+052F
11. \p{InArmenian}：U+0530～U+058F
12. \p{InHebrew}：U+0590～U+05FF
13. \p{InArabic}：U+0600～U+06FF
14. \p{InSyriac}：U+0700～U+074F
15. \p{InThaana}：U+0780～U+07BF
16. \p{InDevanagari}：U+0900～U+097F
17. \p{InBengali}：U+0980～U+09FF
18. \p{InGurmukhi}：U+0A00～U+0A7F
19. \p{InGujarati}：U+0A80～U+0AFF
20. \p{InOriya}：U+0B00～U+0B7F
21. \p{InTamil}：U+0B80～U+0BFF
22. \p{InTelugu}：U+0C00～U+0C7F
23. \p{InKannada}：U+0C80～U+0CFF
24. \p{InMalayalam}：U+0D00～U+0D7F
25. \p{InSinhala}：U+0D80～U+0DFF
26. \p{InThai}：U+0E00～U+0E7F
27. \p{InLao}：U+0E80～U+0EFF
28. \p{InTibetan}：U+0F00～U+0FFF
29. \p{InMyanmar}：U+1000～U+109F
30. \p{InGeorgian}：U+10A0～U+10FF
31. \p{InHangul_Jamo}：U+1100～U+11FF
32. \p{InEthiopic}：U+1200～U+137F
33. \p{InCherokee}：U+13A0～U+13FF
34. \p{InUnified_Canadian_Aboriginal_Syllabics}：U+1400～U+167F
35. \p{InOgham}：U+1680～U+169F
36. \p{InRunic}：U+16A0～U+16FF
37. \p{InTagalog}：U+1700～U+171F
38. \p{InHanunoo}：U+1720～U+173F
39. \p{InBuhid}：U+1740～U+175F
40. \p{InTagbanwa}：U+1760～U+177F
41. \p{InKhmer}：U+1780～U+17FF
42. \p{InMongolian}：U+1800～U+18AF
43. \p{InLimbu}：U+1900～U+194F
44. \p{InTai_Le}：U+1950～U+197F
45. \p{InKhmer_Symbols}：U+19E0～U+19FF
46. \p{InPhonetic_Extensions}：U+1D00～U+1D7F
47. \p{InLatin_Extended_Additional}：U+1E00～U+1EFF
48. \p{InGreek_Extended}：U+1F00～U+1FFF
49. \p{InGeneral_Punctuation}：U+2000～U+206F
50. \p{InSuperscripts_and_Subscripts}：U+2070～U+209F
51. \p{InCurrency_Symbols}：U+20A0～U+20CF
52. \p{InCombining_Diacritical_Marks_for_Symbols}：U+20D0～U+20FF
53. \p{InLetterlike_Symbols}：U+2100～U+214F
54. \p{InNumber_Forms}：U+2150～U+218F
55. \p{InArrows}：U+2190～U+21FF
56. \p{InMathematical_Operators}：U+2200～U+22FF
57. \p{InMiscellaneous_Technical}：U+2300～U+23FF
58. \p{InControl_Pictures}：U+2400～U+243F
59. \p{InOptical_Character_Recognition}：U+2440～U+245F
60. \p{InEnclosed_Alphanumerics}：U+2460～U+24FF
61. \p{InBox_Drawing}：U+2500～U+257F
62. \p{InBlock_Elements}：U+2580～U+259F
63. \p{InGeometric_Shapes}：U+25A0～U+25FF
64. \p{InMiscellaneous_Symbols}：U+2600～U+26FF
65. \p{InDingbats}：U+2700～U+27BF
66. \p{InMiscellaneous_Mathematical_Symbols-A}：U+27C0～U+27EF
67. \p{InSupplemental_Arrows-A}：U+27F0～U+27FF
68. \p{InBraille_Patterns}：U+2800～U+28FF
69. \p{InSupplemental_Arrows-B}：U+2900～U+297F
70. \p{InMiscellaneous_Mathematical_Symbols-B}：U+2980～U+29FF
71. \p{InSupplemental_Mathematical_Operators}：U+2A00～U+2AFF
72. \p{InMiscellaneous_Symbols_and_Arrows}：U+2B00～U+2BFF
73. \p{InCJK_Radicals_Supplement}：U+2E80～U+2EFF
74. \p{InKangxi_Radicals}：U+2F00～U+2FDF
75. \p{InIdeographic_Description_Characters}: U+2FF0–U+2FFF
76. \p{InCJK_Symbols_and_Punctuation}: U+3000–U+303F
77. \p{InHiragana}: U+3040–U+309F
78. \p{InKatakana}: U+30A0–U+30FF
79. \p{InBopomofo}: U+3100–U+312F
80. \p{InHangul_Compatibility_Jamo}: U+3130–U+318F
81. \p{InKanbun}: U+3190–U+319F
82. \p{InBopomofo_Extended}: U+31A0–U+31BF
83. \p{InKatakana_Phonetic_Extensions}: U+31F0–U+31FF
84. \p{InEnclosed_CJK_Letters_and_Months}: U+3200–U+32FF
85. \p{InCJK_Compatibility}: U+3300–U+33FF
86. \p{InCJK_Unified_Ideographs_Extension_A}: U+3400–U+4DBF
87. \p{InYijing_Hexagram_Symbols}: U+4DC0–U+4DFF
88. \p{InCJK_Unified_Ideographs}: U+4E00–U+9FFF
89. \p{InYi_Syllables}: U+A000–U+A48F
90. \p{InYi_Radicals}: U+A490–U+A4CF
91. \p{InHangul_Syllables}: U+AC00–U+D7AF
92. \p{InHigh_Surrogates}: U+D800–U+DB7F
93. \p{InHigh_Private_Use_Surrogates}: U+DB80–U+DBFF
94. \p{InLow_Surrogates}: U+DC00–U+DFFF
95. \p{InPrivate_Use_Area}: U+E000–U+F8FF
96. \p{InCJK_Compatibility_Ideographs}: U+F900–U+FAFF
97. \p{InAlphabetic_Presentation_Forms}: U+FB00–U+FB4F
98. \p{InArabic_Presentation_Forms-A}: U+FB50–U+FDFF
99. \p{InVariation_Selectors}: U+FE00–U+FE0F
100. \p{InCombining_Half_Marks}: U+FE20–U+FE2F
101. \p{InCJK_Compatibility_Forms}: U+FE30–U+FE4F
102. \p{InSmall_Form_Variants}: U+FE50–U+FE6F
103. \p{InArabic_Presentation_Forms-B}: U+FE70–U+FEFF
104. \p{InHalfwidth_and_Fullwidth_Forms}: U+FF00–U+FFEF
105. \p{InSpecials}: U+FFF0–U+FFFF

すべての Unicode 正規表現エンジンが、Unicode ブロックをマッチさせるために同じ構文を使用するわけではありません。Java、Ruby 2.0、およびXRegExpは、上記のように\p{InBlock}という構文を使用します。.NET および XML は代わりに\p{IsBlock}を使用します。Perl と JGsoft フレーバーは、両方の表記をサポートしています。正規表現エンジンがサポートしている場合は、「In」表記を使用することをお勧めします。「In」は Unicode ブロックにのみ使用できますが、「Is」は使用している正規表現のフレーバーに応じて、Unicode プロパティやスクリプトにも使用できます。「In」を使用することで、同様の名前のプロパティやスクリプトではなく、ブロックをマッチさせていることが明確になります。

.NET および XML では、ブロック名でアンダースコアを省略する必要がありますが、ハイフンは保持する必要があります。例: 次のように使用します。\p{IsLatinExtended-A}の代わりに\p{InLatin_Extended-A}。Java では、ハイフンを省略する必要があります。.NET および XML も名前を大文字と小文字を区別して比較しますが、Perl、Ruby、および JGsoft フレーバーは大文字と小文字を区別せずに比較します。Java 4 は大文字と小文字を区別します。Java 5 以降は、「Is」プレフィックスについては大文字と小文字を区別しますが、ブロック名自体は大文字と小文字を区別しません。

ブロックの実際の名前は、すべての正規表現エンジンで同じです。ブロック名は Unicode 標準で定義されています。PCRE および PHP は、Unicode スクリプトをサポートしているにもかかわらず、Unicode ブロックをサポートしていません。

異なるエンコーディングについて心配する必要がありますか？

アクセント付き文字がエンコードされるさまざまな方法によって作成される落とし穴を常に念頭に置いておく必要がありますが、常にそれらを心配する必要があるわけではありません。入力文字列と正規表現が同じスタイルを使用していることがわかっている場合は、まったく心配する必要はありません。このプロセスは Unicode 正規化と呼ばれます。Java、C#、VB.NET など、ネイティブの Unicode サポートを備えたすべてのプログラミング言語には、文字列を正規化するためのライブラリルーチンがあります。マッチを試みる前に、対象と正規表現の両方を正規化すると、矛盾は発生しません。

Java を使用している場合は、Pattern.compile() の 2 番目のパラメータとして CANON_EQ フラグを渡すことができます。これにより、Java 正規表現エンジンは正準等価文字を同一として扱うようになります。正規表現àU+00E0 としてエンコードされたものは、àU+0061 U+0300 としてエンコードされたものと一致し、その逆も同様です。現在、他の正規表現エンジンはマッチング中に正準等価性をサポートしていません。

キーボードで à キーを入力すると、私が知っているすべてのワードプロセッサはコードポイント U+00E0 をファイルに挿入します。したがって、自分で入力したテキストを操作している場合は、自分で入力した正規表現は同じように一致します。

最後に、従来の Windows (多くの場合「ANSI」と呼ばれる) または ISO-8859 コードページを使用してエンコードされたテキストファイルを検索するためにPowerGREPを使用している場合、PowerGREP は常に一対一の置換を使用します。すべての Windows または ISO-8859 コードページはアクセント付き文字を単一のコードポイントとしてエンコードするため、ほとんどすべてのソフトウェアはファイルを Unicode に変換するときに各文字に単一の Unicode コードポイントを使用します。