本網站的其他內容

RegexBuddy—Better than a regular expression tutorial!

Unicode 正規表示式

Unicode 是一個字元集，旨在定義所有語言（無論是活的還是死的）的所有字元和字形。由於越來越多軟體需要支援多種語言，甚至只是「任何」語言，因此 Unicode 近年來已大幅普及。對不同語言使用不同的字元集對程式設計人員和使用者來說實在太過繁瑣。

很不幸的是，Unicode 在正規表示式方面帶來了自己的需求和陷阱。在本教學中討論的正規表示式風味中，Java、XML 和 .NET 使用基於 Unicode 的正規表示式引擎。Perl 從版本 5.6 開始支援 Unicode。PCRE 可以選擇編譯時支援 Unicode。請注意，儘管 PCRE 名稱為「Perl 相容」，但對於 \p 權杖允許的內容，它的彈性遠低於 Perl。基於 PCRE 的 PHP preg 函式在正規表示式附加 /u 選項時支援 Unicode。Ruby 從版本 1.9 開始在正規表示式中支援 Unicode 逸出和屬性。XRegExp 為 JavaScript 帶來 Unicode 屬性支援。

RegexBuddy 的 regex 引擎從 2.0.0 版開始完全基於 Unicode。RegexBuddy 1.x.x 完全不支援 Unicode。 PowerGREP 從 3.0.0 版開始使用相同的 Unicode regex 引擎。較早的版本會在使用 8 位元（即非 Unicode）regex 引擎進行搜尋之前，將 Unicode 檔案轉換為 ANSI。 EditPad Pro 從 6.0.0 版開始支援 Unicode。

字元、碼點和字位元或 Unicode 如何搞亂事情

大多數人會認為 à 是單一字元。很不幸的是，這取決於「字元」一詞的意思，因此不一定會是這樣。

本教學課程討論的所有 Unicode regex 引擎將任何單一 Unicode 碼點視為單一字元。當本教學課程告訴您點號符合任何單一字元時，這在 Unicode 術語中轉換為「點號符合任何單一 Unicode 碼點」。在 Unicode 中，à 可以編碼為兩個碼點：U+0061 (a) 後接 U+0300（重音符號）。在這種情況下，套用於 à 的 . 將符合沒有重音符號的 a。 ^.$ 將無法符合，因為字串包含兩個碼點。 ^..$ 符合 à。

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 版本。不過，有一個差異：\X 始終會比對換行字元，而點號則不會比對換行字元，除非您啟用點號比對換行字元比對模式。

.NET、Java 8 及更早版本，以及 Ruby 1.9 中，您可以使用 \P{M}\p{M}*+ 或 (?>\P{M}\p{M}*) 作為相當接近的替代方案。若要比對任意數量的音節，請使用 (?>\P{M}\p{M}*)+ 作為 \X+ 的替代方案。

比對特定碼點

若要比對特定 Unicode 碼點，請使用 \uFFFF，其中 FFFF 是您要比對的碼點的十六進位數字。您必須始終指定 4 個十六進位數字，例如 \u00E0 比對 à，但僅在編碼為單一碼點 U+00E0 時。

Perl、PCRE、Boost 和 std::regex 不支援 \uFFFF 語法。它們改用 \x{FFFF}。您可以在大括弧中的十六進位數字中省略前導零。由於 \x 本身不是有效的正規表示式標記，因此 \x{1234} 絕不會被誤認為比對 \x 1234 次。它始終比對 Unicode 碼點 U+1234。 \x{1234}{5678} 將嘗試比對碼點 U+1234 正好 5678 次。

在 Java 中，正規表示式標記 \uFFFF 僅比對指定的碼點，即使您已開啟規範等價性。不過，相同的語法 \uFFFF 也用於在 Java 原始碼中將 Unicode 字元插入字串常數。 Pattern.compile("\u00E0") 將比對 à 的單一碼點和雙碼點編碼，而 Pattern.compile("\\u00E0") 僅比對單一碼點版本。請記住，在將正規表示式寫為 Java 字串常數時，反斜線必須加上跳脫字元。前一個 Java 程式碼編譯正規表示式 à，而後一個則編譯 \u00E0。根據您的操作，差異可能很顯著。

JavaScript 透過其 RegExp 類別不提供任何 Unicode 支援，但支援 \uFFFF，作為其字串語法的一部分，用於比對單一 Unicode 碼點。

XML Schema 和 XPath 沒有用於比對 Unicode 編碼點的正規表示式記號。不過，您可以輕鬆地使用 XML 實體，例如 ，將文字編碼點插入正規表示式中。

Unicode 類別

除了複雜性之外，Unicode 也帶來了新的可能性。其中之一是每個 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}*+ 比對沒有後接組合標記的非標記，而 \X 永遠不會這樣做。

PCRE、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 或任何 Unicode 字母後接一個字面 l。

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 標準將每個已分配的碼點（字元）放入一個文字系統中。文字系統是一組由特定人類書寫系統使用的碼點。有些文字系統（如 泰文）對應到單一的人類語言。其他文字系統（如 拉丁文）則橫跨多種語言。

有些語言由多個文字系統組成。沒有日文 Unicode 文字系統。相反地，Unicode 提供日文文件通常由其組成的 平假名、片假名、漢字 和 拉丁文 文字系統。

一個特殊的文字系統是 通用 文字系統。此文字系統包含各種字元，這些字元是廣泛文字系統中常見的。它包含各種標點符號、空白和雜項符號。

所有已分配的 Unicode 碼點（由 \P{Cn} 匹配的）都是一個 Unicode 文字系統的一部分。所有未分配的 Unicode 碼點（由 \p{Cn} 匹配的）都不屬於任何 Unicode 文字系統。

JGsoft 引擎、Perl、PCRE、PHP、Ruby 1.9、Delphi 和 XRegExp 可以匹配 Unicode 文字系統。以下是清單

\p{Common}
\p{Arabic}
\p{Armenian}
\p{Bengali}
\p{Bopomofo}
\p{Braille}
\p{Buhid}
\p{Canadian_Aboriginal}
\p{Cherokee}
\p{Cyrillic}
\p{Devanagari}
\p{Ethiopic}
\p{Georgian}
\p{Greek}
\p{Gujarati}
\p{Gurmukhi}
\p{Han}
\p{Hangul}
\p{Hanunoo}
\p{Hebrew}
\p{Hiragana}
\p{Inherited}
\p{Kannada}
\p{Katakana}
\p{Khmer}
\p{Lao}
\p{Latin}
\p{Limbu}
\p{Malayalam}
\p{Mongolian}
\p{Myanmar}
\p{Ogham}
\p{Oriya}
\p{Runic}
\p{Sinhala}
\p{Syriac}
\p{Tagalog}
\p{Tagbanwa}
\p{TaiLe}
\p{Tamil}
\p{Telugu}
\p{Thaana}
\p{Thai}
\p{Tibetan}
\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} 更好。

\p{InBasic_Latin}: U+0000–U+007F
\p{InLatin-1_Supplement}: U+0080–U+00FF
\p{InLatin_Extended-A}: U+0100–U+017F
\p{InLatin_Extended-B}: U+0180–U+024F
\p{InIPA_Extensions}: U+0250–U+02AF
\p{InSpacing_Modifier_Letters}: U+02B0–U+02FF
\p{InCombining_Diacritical_Marks}: U+0300–U+036F
\p{InGreek_and_Coptic}: U+0370–U+03FF
\p{InCyrillic}: U+0400–U+04FF
\p{InCyrillic_Supplementary}: U+0500–U+052F
\p{InArmenian}: U+0530–U+058F
\p{InHebrew}: U+0590–U+05FF
\p{InArabic}: U+0600–U+06FF
\p{InSyriac}: U+0700–U+074F
\p{InThaana}: U+0780–U+07BF
\p{InDevanagari}: U+0900–U+097F
\p{InBengali}: U+0980–U+09FF
\p{InGurmukhi}: U+0A00–U+0A7F
\p{InGujarati}: U+0A80–U+0AFF
\p{InOriya}: U+0B00–U+0B7F
\p{InTamil}: U+0B80–U+0BFF
\p{InTelugu}: U+0C00–U+0C7F
\p{InKannada}: U+0C80–U+0CFF
\p{InMalayalam}: U+0D00–U+0D7F
\p{InSinhala}: U+0D80–U+0DFF
\p{InThai}: U+0E00–U+0E7F
\p{InLao}: U+0E80–U+0EFF
\p{InTibetan}: U+0F00–U+0FFF
\p{InMyanmar}: U+1000–U+109F
\p{InGeorgian}: U+10A0–U+10FF
\p{InHangul_Jamo}: U+1100–U+11FF
\p{InEthiopic}: U+1200–U+137F
\p{InCherokee}: U+13A0–U+13FF
\p{InUnified_Canadian_Aboriginal_Syllabics}: U+1400–U+167F
\p{InOgham}: U+1680–U+169F
\p{InRunic}: U+16A0–U+16FF
\p{InTagalog}: U+1700–U+171F
\p{InHanunoo}: U+1720–U+173F
\p{InBuhid}: U+1740–U+175F
\p{InTagbanwa}: U+1760–U+177F
\p{InKhmer}: U+1780–U+17FF
\p{InMongolian}: U+1800–U+18AF
\p{InLimbu}: U+1900–U+194F
\p{InTai_Le}: U+1950–U+197F
\p{InKhmer_Symbols}: U+19E0–U+19FF
\p{InPhonetic_Extensions}: U+1D00–U+1D7F
\p{InLatin_Extended_Additional}: U+1E00–U+1EFF
\p{InGreek_Extended}: U+1F00–U+1FFF
\p{InGeneral_Punctuation}: U+2000–U+206F
\p{InSuperscripts_and_Subscripts}: U+2070–U+209F
\p{InCurrency_Symbols}: U+20A0–U+20CF
\p{InCombining_Diacritical_Marks_for_Symbols}: U+20D0–U+20FF
\p{InLetterlike_Symbols}: U+2100–U+214F
\p{InNumber_Forms}: U+2150–U+218F
\p{InArrows}: U+2190–U+21FF
\p{InMathematical_Operators}: U+2200–U+22FF
\p{InMiscellaneous_Technical}: U+2300–U+23FF
\p{InControl_Pictures}: U+2400–U+243F
\p{InOptical_Character_Recognition}: U+2440–U+245F
\p{InEnclosed_Alphanumerics}: U+2460–U+24FF
\p{InBox_Drawing}: U+2500–U+257F
\p{InBlock_Elements}: U+2580–U+259F
\p{InGeometric_Shapes}: U+25A0–U+25FF
\p{InMiscellaneous_Symbols}: U+2600–U+26FF
\p{InDingbats}: U+2700–U+27BF
\p{InMiscellaneous_Mathematical_Symbols-A}: U+27C0–U+27EF
\p{InSupplemental_Arrows-A}: U+27F0–U+27FF
\p{InBraille_Patterns}: U+2800–U+28FF
\p{InSupplemental_Arrows-B}: U+2900–U+297F
\p{InMiscellaneous_Mathematical_Symbols-B}: U+2980–U+29FF
\p{InSupplemental_Mathematical_Operators}: U+2A00–U+2AFF
\p{InMiscellaneous_Symbols_and_Arrows}: U+2B00–U+2BFF
\p{InCJK_Radicals_Supplement}: U+2E80–U+2EFF
\p{InKangxi_Radicals}: U+2F00–U+2FDF
\p{InIdeographic_Description_Characters}: U+2FF0–U+2FFF
\p{InCJK_Symbols_and_Punctuation}: U+3000–U+303F
\p{InHiragana}: U+3040–U+309F
\p{InKatakana}: U+30A0–U+30FF
\p{InBopomofo}: U+3100–U+312F
\p{InHangul_Compatibility_Jamo}: U+3130–U+318F
\p{InKanbun}: U+3190–U+319F
\p{InBopomofo_Extended}: U+31A0–U+31BF
\p{InKatakana_Phonetic_Extensions}: U+31F0–U+31FF
\p{InEnclosed_CJK_Letters_and_Months}: U+3200–U+32FF
\p{InCJK_Compatibility}: U+3300–U+33FF
\p{InCJK_Unified_Ideographs_Extension_A}: U+3400–U+4DBF
\p{InYijing_Hexagram_Symbols}: U+4DC0–U+4DFF
\p{InCJK_Unified_Ideographs}: U+4E00–U+9FFF
\p{InYi_Syllables}: U+A000–U+A48F
\p{InYi_Radicals}: U+A490–U+A4CF
\p{InHangul_Syllables}: U+AC00–U+D7AF
\p{InHigh_Surrogates}: U+D800–U+DB7F
\p{InHigh_Private_Use_Surrogates}: U+DB80–U+DBFF
\p{InLow_Surrogates}: U+DC00–U+DFFF
\p{InPrivate_Use_Area}: U+E000–U+F8FF
\p{InCJK_Compatibility_Ideographs}: U+F900–U+FAFF
\p{InAlphabetic_Presentation_Forms}: U+FB00–U+FB4F
\p{InArabic_Presentation_Forms-A}: U+FB50–U+FDFF
\p{InVariation_Selectors}: U+FE00–U+FE0F
\p{InCombining_Half_Marks}: U+FE20–U+FE2F
\p{InCJK_Compatibility_Forms}: U+FE30–U+FE4F
\p{InSmall_Form_Variants}: U+FE50–U+FE6F
\p{InArabic_Presentation_Forms-B}: U+FE70–U+FEFF
\p{InHalfwidth_and_Fullwidth_Forms}: U+FF00–U+FFEF
\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 正規化。所有具有原生 Unicode 支援的程式語言，例如 Java、C# 和 VB.NET，都有用於正規化字串的函式庫常式。如果您在嘗試比對之前正規化主旨和正規表示式，就不會有任何不一致的情況。

如果您使用 Java，您可以將 CANON_EQ 旗標傳遞為 Pattern.compile() 的第二個參數。這會告訴 Java 正規表示式引擎將正規等價字元視為相同。正規表示式 à 編碼為 U+00E0 與編碼為 U+0061 U+0300 的 à 相符，反之亦然。目前沒有其他正規表示式引擎在比對時支援正規等價。

如果您在鍵盤上輸入 à 鍵，我所知道的文字處理器都會將碼點 U+00E0 插入檔案中。因此，如果您使用自己輸入的文字，您自己輸入的任何正規表示式都會以相同的方式相符。

最後，如果您使用 PowerGREP 搜尋使用傳統 Windows（通常稱為「ANSI」）或 ISO-8859 碼頁編碼的文字檔案，PowerGREP 始終使用一對一替換。由於所有 Windows 或 ISO-8859 碼頁都將重音字元編碼為單一碼點，因此在將檔案轉換為 Unicode 時，幾乎所有軟體都對每個字元使用單一 Unicode 碼點。

| 快速入門 | 教學 | 工具和語言 | 範例 | 參考 | 書籍評論 |