> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/zh-tw/shen-ru-wen-zhang/51-unicode-utf-8-and-multilingual-text-an-introduction.md).

# Unicode、UTF-8 與多語言文字：簡介

## Unicode 與 OpenType：字元與字形

現代 TeX 引擎，也就是 XeTeX 與 LuaTeX，之所以從 Knuth 原始的 TeX 引擎演進而來，主要是因為需要跟上科技環境的發展，特別是 Unicode（用於文字）與 OpenType（用於字型）。如今，透過使用諸如 [fontspec](https://ctan.org/pkg/fontspec?lang=en) 和 [unicode-math](https://ctan.org/pkg/unicode-math?lang=en)，LaTeX 使用者可以使用 OpenType 字型所提供的極其精密的排版能力——包括進階的多語言排版以及基於 OpenType 的數學排版（[由 Microsoft 首創](https://blogs.msdn.microsoft.com/murrays)).

然而，若要充分發揮 XeTeX/LuaTeX 搭配 OpenType 字型的效益，熟悉一些背景主題／概念會很有幫助——尤其是在排解問題或為更進階／複雜的工作鋪路時。舉例來說，你可能會讀到 XeTeX 與 LuaTeX 引擎使用「UTF-8 輸入」，或說它們是「具 Unicode 感知」的；而進一步閱讀 OpenType 字型時，可能會提到或討論諸如「Unicode 編碼」、「OpenType『字型特性』」、「字形」、「字形 ID」、「字形名稱」等等主題。我們的目標是為這些術語／主題提供入門介紹，並拼湊出一個基本框架，說明它們彼此如何相關，並希望能為後續工作或問題解決提供支援。

我們打算涵蓋的主題大致可清楚分成兩大類： *Unicode* 其實可視為生活在文字／字元與文字編碼的世界中，並且 *OpenType* 其世界則是字型與字形的世界；但當然，這兩個世界是相互連結的，即使在這第一篇文章中也有部分重疊。

### 我們要討論哪些主題？

這篇文章的主要焦點是一些與 Unicode 相關的主題：從討論「字元」是什麼開始，接著介紹文字系統／語言、Unicode 編碼與 UTF-8——並附上一個處理多語言文字檔的例子。後續文章將以這篇為基礎，涵蓋與 OpenType 字型技術相關的背景主題。顯然，在一篇部落格文章的篇幅限制內，不可能試圖對我們希望討論的所有領域都做一次「深度探討」：我們明確的目標，是提供一個總體框架，說明幾個關鍵概念如何彼此關聯並共同運作。我們先從最基本的概念開始：也就是 *字元*.

## 字元：基本構成單元

在我們的討論核心（以及 Unicode 的核心）中，有一個基本觀念／概念，那就是「字元」的意義：這是那種在日常工作與對話中，其意義常常會因使用情境而被「預設」的詞。不過，從 Unicode、排版與字型技術的角度來看，我們需要更精確一些，並定義「字元」究竟是什麼。例如，我們很自然地可能會把 **a** 和 *a* 視為不同的「字元」：『粗體 a』與『斜體 a』。但其實不是：它們只是同一個基本字元的不同視覺呈現，而 Unicode 賦予它的正式名稱是 [拉丁小寫字母 A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [將字元定義為](http://www.unicode.org/glossary/#character) ：

> 「書寫語言中具有語義價值的最小組成部分；指的是抽象的意義和／或形狀，而不是某個特定形狀……」

這清楚區分了字元的具體 *視覺外觀* 以及其 *意義*.

你可以把字元視為語言的基本單位，或構成要素；更準確地說，是一種 *書寫系統*——這是我們在下文會討論的主題。字元在使用特定字型顯示時實際長什麼樣子，與 Unicode 對字元的定義無關：真正相關的只有 *意義* 才是真正值得關注的： *角色與用途* 每個字元作為一組構件中的一員，最終由這些構件組成各種文字系統／語言。

### 文字系統與語言

值得簡要提及兩個重要概念： *文字系統* 和 *語言*。Unicode 網站提供了一個有用的 [文字系統定義](https://www.unicode.org/standard/supported.html):

> 「Unicode 標準編碼的是文字系統，而不是語言。當多種語言的書寫系統共享一組在歷史上彼此相關的圖形符號時，所有這些圖形符號的聯集會被視為一個單一的字元集合來編碼，並被識別為單一的文字系統。」

以一個 [維基百科的範例](https://en.wikipedia.org/wiki/Script_\(Unicode\))，拉丁文字系統由一組特定的 [字元集合](http://unicode.org/charts/) 組成，這些字元被多種語言使用：英文、法文、德文、義大利文等等。當然，並非所有在拉丁文字系統中定義的字元都會被所有基於拉丁文字系統的語言使用——例如，英文字母表並不包含法文或德文等其他歐洲語言中常見的重音字元。

### OpenType 字型：文字系統與語言

在這一點上，我們將從 Unicode 轉入 OpenType 字型，因為文字系統與語言的概念在 OpenType 字型技術中也扮演極其重要的角色。

使用同一 [書寫系統](http://www.unicode.org/glossary/#script) 的一組語言，在顯示（排版）以特定語言寫成的文字時，可能各自具有不同的排版傳統。土耳其語和 [無點 i 的行為](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) （請參見該頁面關於連字的註解）。與文字系統／語言相關的排版「規則」是透過所謂的文字系統與語言 *標籤* 來識別應適用於特定文字系統／語言組合的規則。當然，每種 OpenType 字型所支援的文字系統／語言集合，會因字型創作者的選擇與製作目的而有所不同。像 XeTeX 或 LuaTeX 這類精密的排版軟體，可以藉由允許使用者在排版特定語言的文字時，選擇性地將這些規則套用到輸入文字上，從而利用這些（內建於 OpenType 字型中的）規則——例如，透過使用 LaTeX [fontspec 套件](https://ctan.org/pkg/fontspec?lang=en).

#### 檢視 OpenType 字型內部：文字系統／語言

為了讓這點更清楚，這裡有一張螢幕截圖，顯示免費的 [Scheherazade OpenType 字型](http://software.sil.org/scheherazade/download/) 在（同樣免費的） [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) 字型編輯軟體中開啟。在這張圖中，你可以看到 Scheherazade 內建的文字系統、語言與排版特性——使用 VOLT 你可以為 Scheherazade 增加額外的特性與功能，但這已遠超出本文範圍！

![在 Microsoft VOLT 中開啟的 Scheherazade OpenType（TrueType 風格）字型](/files/de2bcc93f2076b6ff775ca7530f7c15675742279)

從這張截圖可以看出，Scheherazade 支援阿拉伯與拉丁文字系統，並且為多種使用阿拉伯文字系統的語言提供進一步的專門支援——這是透過所謂的 OpenType 特性來實現的，這些特性列在上方綠框中。我們不會深入探討這些特性的細節，但這裡要傳達的是，高品質的 OpenType 字型內建了大量智慧，供能夠善用字型內建排版規則的排版軟體使用。

有興趣的讀者可以瀏覽 OpenType 標記登錄表，查看 [文字系統標記](https://www.microsoft.com/typography/otspec/scripttags.htm) 和 [語言標記](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) 目前在 OpenType 規範中使用的。

### 回到字元：不同的字元角色

構成文字系統（或語言）基本元素的字元集合，並不都扮演相同角色。例如，在大多數語言中，都有用於 *標點符號*，用於數字的字元 *數字* 以及我們所認為的 *字母* 的字母表，其中在某些文字系統中也有大寫與小寫形式。字元的概念相當廣泛，而 Unicode 標準也包含一些專門的字元，它們 *並非設計來顯示* 但其工作是「控制文字的解讀或顯示」。例如，在排版某些阿拉伯文字時，你可能希望強制或阻止某些字元的連接行為；Unicode 標準提供了特殊控制字元來做到這一點：所謂的 [零寬度連接字元](https://en.wikipedia.org/wiki/Zero-width_joiner) 以及 [零寬度不連接字元](https://en.wikipedia.org/wiki/Zero-width_non-joiner)。這些字元不是為了顯示而設計的，軟體在處理文字時會將它們「吸收」掉，以產生預期的視覺效果。

Unicode 標準中所規定的所有字元都會被賦予一組屬性，這些屬性實際上描述了每個字元在 Unicode 編碼中的角色與用途——像 LATIN SMALL LETTER A 這樣的字元名稱，只是字元屬性清單中的一個項目。這些屬性在 [Unicode 字元資料庫（UCD）](http://www.unicode.org/reports/tr44/) 中有完整說明，並廣泛用於搜尋、排序、拼字檢查等電腦化文字處理作業。列出 Unicode 字元屬性的資料檔也可 [供下載](http://www.unicode.org/Public/UCD/latest/).

在分配給每個字元的屬性中，對我們的討論而言最重要的是一個 *數值識別碼* ，由其 Unicode 編碼指派；這正是我們接下來要談的主題。

### 字元：數字與編碼

這是顯而易見的，但電腦和其他數位裝置本來就是用來儲存與處理數值資料的：那麼這和文字有什麼關係？當你使用電腦鍵盤，或在行動裝置螢幕上點選輸入一些文字時，你的按鍵輸入會被轉換成數字，用來表示你正在輸入的字元序列。

在某個時候，你可能會想透過電子郵件、簡訊，或透過像是 Tweet 或某種社群媒體貼文之類的線上通訊方式傳送該文字（也就是一串數字）。顯然，撰寫文字的裝置與收件者使用的裝置，必須以某種方式對哪些數字代表哪些字元達成一致。否則，你的文字可能無法在收件者的裝置上正確顯示。

為了讓今日的全球通訊得以運作，發送與接收裝置需要某種「共同約定的慣例」，使特定的一組數字代表特定的一組字元。這種慣例稱為一種 *編碼*：一組用來表示特定字元集合的數字，而 Unicode 編碼如今已成為 *事實上的* 全球標準。

## Unicode：用於儲存文字的位元與位元組

Unicode 是一個龐大的標準，涵蓋的內容遠遠不只文字編碼，但這裡我們只聚焦於它所提供的編碼。

#### 位元、位元組，以及多少字元？

我們提到過，裝置會以數字來儲存與表示文字——更具體地說，字元會以整數，也就是完整數值來儲存。要理解這對 Unicode 編碼的影響，我們需要做一個 *非常* 簡短的、 *非常* 基本的回顧，看看電腦如何儲存整數（我們無意深入電腦科學）。

長話短說，現今的桌上型或手持裝置會以離散的「區塊」來儲存整數，其長度可以是 1、2、4 或 8 位元組。每一種儲存單位都能依其所含總位元數，儲存最高到某個正整數上限：

* 1 位元組（8 位元）：最大正整數為 255；
* 2 位元組（16 位元）：最大正整數為 65535；
* 4 位元組（32 位元）：最大正整數為 4,294,967,295；
* 8 位元組（64 位元）：最大正整數為 18,446,744,073,709,551,615。

實務上，Unicode 標準使用 0 到 1,114,111 之間的數字來編碼全世界的所有字元，因此只需要 21 位元就能編碼完整範圍。我們可以從這點看出，含有 n 位元的儲存單位可以表示從 0 到最大值 $$2^n -1$$；因此：

* 可儲存在 20 位元中的最大值是 $$2^{20} -1 = 1,048,575$$ （太小）；
* 可儲存在 21 位元中的最大值是 $$2^{21} -1 = 2,097,151$$ （足夠大）。

我們已經注意到，電腦以 1、2、4（或 8）位元組為單位來儲存資料（數字），那麼如果我們必須儲存高達 Unicode 最大值 1,114,111 的數值，儲存單位需要多大？顯然，一個位元組大小的儲存單位最多只能容納 255，而 2 個位元組可儲存 65535：這兩者都不足以儲存 Unicode 編碼所涵蓋的完整字元範圍。下一個可選方案是大小為 4 位元組的儲存單位，它最多可儲存 4,294,967,295 這樣的整數，遠遠超過我們實際所需。因此，如果我們選擇 4 位元組作為儲存單位，當然有足夠的空間來儲存所有 Unicode 值，每個字元都以一個需要 4 位元組（32 位元）的整數來儲存。然而，用 4 位元組來儲存所有東西在空間上非常浪費，因為即使是最大的 Unicode 值也只需要最多 21 位元——這表示如果用 32 位元來儲存，32 個位元中有 11 個永遠不會被用到。

**注意**：雖然 Unicode 範圍從 0 到 1,114,111，但該範圍內的每個值並非都實際使用：基於技術原因，有些值被視為不能實際作為 Unicode 字元使用。

### 那麼，UTF-8 是什麼？

如果你閱讀有關 XeTeX 或 LuaTeX 的資料，幾乎一定會遇到這樣的說明：這些 TeX 引擎會以「UTF-8 格式」讀取文字與 LaTeX 輸入檔。那麼「UTF-8 格式」是什麼？它與 Unicode 又有何關聯？在 Unicode 的術語中，用於編碼世界各地字元的 1,114,112 個值（範圍從 0 到 1,114,111）中的每一個都稱為一個 [碼位](http://www.unicode.org/glossary/#code_point).

我們已經看到， *在理論上*，我們需要將所有以 Unicode 編碼的文字以每個字元 4 位元組的方式儲存，才能表示 Unicode 碼位的完整範圍。然而，在實務上，有些相當聰明的人發明了一種簡單的方法，能把單一 Unicode 數值（碼位）表示成 *token* 由較小數字構成的序列，而這些較小數字中的每一個都儲存在單一位元組中：這是一個會 *將* 把一個（較大的）整數轉換成一串較小的（位元組大小的）數值。由於這種轉換，我們文字檔中的字元不再各自對應單一數值：每個字元都變成一個 *多位元組序列*——文字檔中的 1 到 4 個（連續）位元組都可以表示單一 Unicode 字元（也就是其碼位值）。

UTF 代表 *Unicode 轉換格式* 而這裡的關鍵字是 *轉換*。基本上，你可以把 UTF-8 想成一種將單一 Unicode 碼位值轉換成 1 到 4 個位元組大小片段序列的「配方」或演算法。Unicode 碼位的值越大，所需用來表示它的單一位元組數量也越多。

UTF-8 的建立有技術與歷史上的原因，而 UTF-8 發明背後的故事則 [記錄在一封 2003 年的精彩電子郵件中](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt)，其中在郵件開頭附近有這麼一句：

> 「那不是真的。UTF-8 是 1992 年 9 月某個夜晚，當著我的面，在新澤西一家餐館的餐墊紙上設計出來的，大概就是那時候。」

#### 範例：阿拉伯字母 ل

讓我們以阿拉伯字母 ل（Unicode 名稱 ARABIC LETTER LAM）為例；它被分配的 Unicode 碼位值是 1604（十進位）或 0644（十六進位）：其在 UTF-8 中的表示為 *兩位元組* D9 84（十六進位）的兩位元組序列，或以十進位表示為 217 132。使用 UTF-8 作為文字儲存格式時，並不是以一個單獨的數字 1604 來表示 ل，而是會轉換成兩個位元組大小的值：217 和 132——字元 ل 會以一個 *兩位元組序列*。想更詳細探索 UTF-8 演算法的讀者，可以在我的 [個人部落格網站](http://www.readytext.co.uk/?p=1284).

當某個軟體（例如 XeTeX 或 LuaTeX）讀取 UTF-8 格式的文字時，該軟體需要判定該檔案中每個字元的 Unicode 值，因此它會使用一種演算法來 *反向* 反轉 UTF-8 轉換過程。透過這個「反向演算法」，兩個位元組（217 和 132）會重新組合成整數 1604，接著可辨識為阿拉伯字母 ل 的 Unicode 碼位值。

因此，總之，UTF-8 其實只是用於儲存與傳輸 Unicode 編碼文字的一種中介資料格式。

**注意**：有些系統選擇以每個字元 32 位元來使用／儲存文字，這稱為 [UTF-32](https://en.wikipedia.org/wiki/UTF-32)——另外還有 [UTF-16](https://en.wikipedia.org/wiki/UTF-16) ，但 UTF-8 是儲存 Unicode 編碼文字最常見的方式。

## 多語言 TeX 檔案：XeTeX 與 LuaTeX

XeTeX 與 LuaTeX 都能進行非常精密的多語言排版，雖然它們實現這項功能的機制相當不同，反映出各自引擎的設計／開發哲學。我們不會深入探討這一點，只簡單指出 XeTeX 引擎包含一些軟體元件（內建於其可執行檔中），這些元件在 LuaTeX 中並不存在——最值得注意的是用於 *OpenType 字形塑形* （例如，透過一個名為 [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX 則採取不同的方法：它不是直接把功能建入實際的 TeX 引擎，而是提供一套極其豐富的命令（TeX 原語）以及一個非常強大的 [以 Lua 為基礎的 API](/latex/zh-tw/shen-ru-wen-zhang/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) API，開發者可透過它建立同樣進階的多語言排版解決方案。雖然 LuaTeX 的理念可能會讓 LaTeX 套件開發者多做一些工作，但它提供了大量額外的彈性，因為解決方案並不是「硬編碼」到 LuaTeX 引擎本身，而是由 TeX 與 Lua 程式碼——或者以 C/C++ 撰寫的外掛程式——所建構出來。

**補充**：想進一步探索 OpenType 字形塑形這個迷人但複雜的世界的讀者，或許會有興趣閱讀一個極佳的開源函式庫，名為 [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)——它被許多應用程式使用，包括 Firefox、Chrome 和 LibreOffice，當然也包括 XeTeX。本篇作者曾使用 HarfBuzz 來建立 [用於阿拉伯文排版的 LuaTeX 外掛程式](http://www.readytext.co.uk/?p=3186).

如今已很常見（例如在社群媒體上）傳送包含多種語言字元的文字，而儲存多語言文字的 UTF-8 文字檔很容易包含其 UTF-8 表示長度為 1、2、3 或 4 位元組的字元。因此，實際上，UTF-8 文字檔只是一串單一位元組的串流，但其中每個實際字元都可能長達 1 到 4 個位元組：個別字元已變成 *多位元組序列*.

為了進一步探索處理（排版）多語言文字的一些關鍵面向，我們將使用一個包含阿拉伯文字系統的範例，因為阿拉伯文讓我們有空間討論多個概念。

#### 補充：阿拉伯文字系統

該 [阿拉伯文字系統](https://en.wikipedia.org/wiki/Arabic_script) 採用連筆風格書寫，並由右向左閱讀與書寫。每個阿拉伯字母都有可能依下列情況採用 4 種不同的形狀之一：

* 它是否以單一、獨立（孤立）的字元顯示（未與其他任何字元連接）；
* 它是否出現在一個字內——位於字首、字中或字尾：分別稱為 *起始*, *中間* 和 *final* 形式。

阿拉伯文字系統中的每個字元都有自己的一套連接規則，當它左側、右側，或左右兩側有其他字元時，可能會也可能不會改變形狀／外觀。想進一步探究的讀者可以找到一份 [維基百科上的完整清單](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### 範例：UTF-8 中的阿拉伯文與英文文字

假設我們建立一個 UTF-8 文字檔，包含一行英文與阿拉伯文文字：This is العَرَبِيَّة text!

這行文字包含 3 個空白字元、11 個英文（拉丁文字系統）字元，以及 12 個阿拉伯字元（雖然這點可能不會立刻明顯看出來）。當它儲存為 UTF-8 文字檔時，會佔用 38 位元組的儲存空間，原因如下：

* **拉丁文字系統**：空格加上英文文字：14 × 1 位元組字元 = 14 位元組；
* **阿拉伯文字系統**：12 個阿拉伯字元 × 每字元 2 位元組 = 24 位元組。

合計 14 + 24 = 38 位元組。

#### 深入探究

如果我們將範例文字儲存為一個名為 `arabic.txt` 的 UTF-8 檔案，並在十六進位編輯器中開啟，就可以檢視其中實際包含的位元組。從下面這張有註解的螢幕截圖可看出，阿拉伯文字是以每個字元 2 個位元組來儲存的：

![在十六進位編輯器中開啟的、包含英文與阿拉伯文的 UTF-8 文字檔。](/files/9a2cf86b274ae8d2aba19cfdc427c804a2fe3d8c)

在十六進位編輯器中開啟的、包含英文與阿拉伯文的 UTF-8 文字檔。你可以清楚看到，拉丁文字系統的字元只需要單一位元組，而阿拉伯文字系統的字元則是以每個字元兩個位元組來儲存。

從這張截圖你可以觀察到幾點：

* 阿拉伯文字是以由左到右的序列儲存，而那些字元是阿拉伯字母與母音的原始、未塑形（孤立）版本；
* 在拉丁文字系統的「This is 」之後，沒有任何額外資訊可告知讀取此檔案的軟體，下一個字元是屬於阿拉伯文字系統。

如果你正在排版多語言文件（例如包含英文與阿拉伯文），那麼在讀取／處理輸入文字檔（以位元組串流形式）時，XeTeX 或 LuaTeX 必須能夠偵測每個字元的起始與結束，並讀取正確數量的位元組，以反向還原 UTF-8 轉換並產生對應的 Unicode 碼位。正是 UTF-8 演算法本身讓軟體能做到這一點：它能偵測每個獨立字元的第一個位元組，以及為了計算對應 Unicode 碼位所需讀取的位元組數。UTF-8 使用起來很簡單，但確實相當巧妙。

#### 邏輯順序、顯示順序與 OpenType 字形塑形

如果你仔細看上面的阿拉伯文（العَرَبِيَّة），可能很難看出我們的文字檔確實包含 12 個獨立的阿拉伯字元——尤其當你不熟悉阿拉伯文字系統時更是如此！然而，如果你仔細數上方截圖右側顯示的阿拉伯字元，就會發現總共有 12 個。

對於像阿拉伯文這類複雜文字系統的語言，我們的文字檔 *儲存* 以及你 *在螢幕上看到的* 明顯是 *非常* 實際上是明顯不同的！當你在瀏覽器之類的程式中檢視那段文字時，你看到的是（視所用字型而定）：

![排版後的阿拉伯文字圖片](/files/40207526d651ac2d6a9b92105aed35983c8d9f9a)

但如上方截圖所示，UTF-8 文字檔實際包含的是這個：

![未排版的阿拉伯文字圖片（孤立字元）](/files/4625bf96d09718423cd826a1e6e84e9bf9ea42ee)

即使你不熟悉阿拉伯文字系統的連筆特性，也可以清楚看出，在將文字檔中的阿拉伯字元傳送到排版和／或在螢幕上顯示的過程中，有「某些事情」發生了（以字形的形式）。如果你習慣在 TeX/LaTeX 中使用簡單文字系統語言，例如以拉丁字母為基礎的語言，這確實會非常令人困惑！

這裡牽涉到一些重要概念，因為 Unicode 文字檔負責儲存的是……好吧，文字（Unicode），而排版與顯示系統則負責使用字型與字形（OpenType）：

* 文字檔以由左到右的順序儲存阿拉伯字元，但阿拉伯文是由右到左閱讀／顯示的：文字檔會以所謂的 *邏輯順序*;
* 文字檔包含單一字元，而這些字元與螢幕上實際呈現的顯示結果看起來非常不同：文字檔中所含的是處於孤立、未連接形式的阿拉伯字元。

#### 這裡到底怎麼回事？

在文字檔中，阿拉伯文是以由左到右的孤立形式字元序列儲存的：如果你仔細想想，文字檔是依照 *它們被輸入的* （其中 *邏輯順序*）。只有當該文字被處理以供顯示，或進行排版時，它才會以正確的閱讀順序顯示，這通常稱為 *視覺順序* 或 *顯示順序*；此外，阿拉伯字元的孤立形式會被 *塑形成* 成為在排版上正確的顯示版本。可以這樣理解：簡單的文字檔必須以盡可能基本的形式儲存文字（Unicode 字元）：原始、未塑形、單一的文字字元——系統軟體的工作，則是根據顯示裝置上可用的作業系統、字型以及排版／顯示軟體，將這些字元渲染為可顯示的內容。

當該檔案中的阿拉伯文字被排版／顯示時，它會經歷一個稱為 *排版*。各個阿拉伯字元會轉換為經過塑形的字形，能正確呈現依阿拉伯文字系統與書寫系統的連接規則所需的各種字元變體。此外，高品質的排版軟體（搭配優質的 OpenType 字型）還會透過一個稱為 *OpenType 字形塑形*——一個涵蓋範圍廣泛的排版作業的過程，其中可能包括：

* 以單一複雜的連字字形取代多個個別字形（在阿拉伯文中非常常見），或
* 定位作業，例如根據阿拉伯母音位於哪個字形的上方或下方來調整其位置。

![顯示阿拉伯文字在排版時所經歷轉換的圖片](/files/fd8a6e023631858b715fee5f0481b6a25e784351)

邏輯順序與視覺（顯示）順序之間的差異。在這張圖中，你可以看到儲存在文字檔中的阿拉伯字元，在顯示或排版時會經過重新排序與字形整形。

進階 OpenType 字型的設計師與製作者會投入相當大量的時間與專業知識，以提供其字型中內建的精密排版功能。

若要關閉套用到阿拉伯文字上的字形整形，我們可以使用優秀且免費的 [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) Unicode 文字編輯器（僅適用於 Windows），它可讓你停用字形整形，以查看文字檔中實際存在的原始、個別且未連字（未整形）字元——請見這張合併截圖的下半部：

![顯示 BabelPad 文字編輯器可關閉 OpenType 字形整形功能的圖片](/files/96ed3d3d1082139f88464ea71302edb458afb383)

使用 BabelPad Unicode 文字編輯器開啟 OpenType 字形整形（上圖）或將其關閉（下圖）。關閉 OpenType 字形整形後，編輯阿拉伯文字會容易得多。

邏輯順序與顯示順序的概念，加上字形整形的過程，在你第一次於編輯或排版包含阿拉伯文等複雜文字系統的多語言文字檔時，可能會相當令人困惑：希望以上內容已幫助你避免一些初期的混淆。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/zh-tw/shen-ru-wen-zhang/51-unicode-utf-8-and-multilingual-text-an-introduction.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.