> 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/ja/xiang-xi-ji-shi/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」、「グリフ名」などの話題が出てくることがあります。私たちの目的は、これらの用語やトピックを紹介し、それらがどのように関連しているのかを示す基本的な枠組みを組み立て、できれば今後の作業や問題解決の助けになることです。

これから扱うトピックは、大きく 2 つの主要分野にきれいに分けられます: *Unicode* それは実質的には、テキスト/文字とテキスト符号化の世界に属し、 *OpenType* もう一方はフォントとグリフの世界です。しかしもちろん、この 2 つの世界は相互に結びついており、今回の最初の記事でも多少の重なりがあります。

### どのトピックを取り上げるのでしょうか？

この記事の主な焦点は、Unicode に関するいくつかのトピックです。まず「文字」とは何かを説明し、続いて文字体系/言語、Unicode 符号化、UTF-8 を紹介し、多言語テキストファイルを扱う例を示します。続編の記事では、この内容を土台にして OpenType フォント技術に関連する背景トピックを扱います。もちろん、ブログ記事という制約の中で、私たちが議論したいすべての領域を「深掘り」することはできません。ここでの目的は、いくつかの重要な概念がどのように関連し、連携しているかを示す全体的な枠組みを提供することです。まずは最も基本的な概念、つまり *文字*.

## 文字: 基本的な構成要素

私たちの議論の中心にあり（Unicode においても中心的な）基本的な考え方は、「文字」の意味です。これは、日々の作業や会話の中でその意味がしばしば暗黙のうちに前提とされている言葉のひとつです。しかし、Unicode、組版、フォント技術の観点からは、「文字」とは何を意味するのかをもう少し正確に定義する必要があります。たとえば、私たちは **a** や *a* を別々の「文字」だと考えるのはごく自然でしょう。『太字の a』と『斜体の a』です。しかし、そうではありません。これらは同じ根本的な文字を別々に視覚化しただけであり、Unicode ではその正式名として [LATIN SMALL LETTER A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [を文字として定義しています](http://www.unicode.org/glossary/#character) 次のように定義しています：

> 「意味を持つ書記言語の最小の構成要素。特定の形ではなく、抽象的な意味および/または形状を指す…」

これは、文字の具体的な *見た目* 形状 *とその*.

意味 *文字体系*—後述するトピックです。特定のフォントで表示したときに文字が実際にどのように見えるかは、Unicode における文字の定義には関係ありません。重要なのは、 *とその* 文字の *役割と目的* 、つまり文字体系/言語が最終的に構成される一連の構成要素の 1 つとしての役割です。

### 文字体系と言語

ここで、2 つの重要な概念を簡単に述べておく価値があります: *文字体系* や *言語*。Unicode の веб サイトには、 [文字体系の定義](https://www.unicode.org/standard/supported.html):

> が役立つ形で示されています。「Unicode Standard は言語ではなく文字体系を符号化します。複数の言語で使われる書記体系が、歴史的に関連する図形記号の集合を共有している場合、それらすべての図形記号の和集合は、符号化のためには 1 つの文字集合として扱われ、1 つの文字体系として識別されます。」

Wikipedia の [例を用いると](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 フォントの機能に組み込まれており、特定の文字体系/言語の組み合わせに適用すべき規則を識別するために使われます。もちろん、各 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/b448ecbff68480e90591fc8d91c0db51bc8613ce)

このスクリーンショットから、Scheherazade がアラビア文字体系とラテン文字体系をサポートし、さらにアラビア文字体系を使ういくつかの言語に対して専門的なサポートを提供していることがわかります。これは、上の緑枠のボックスに一覧表示されている、いわゆる OpenType 機能によるものです。これらの機能の詳細には立ち入りませんが、ここで伝えたいのは、高品質な OpenType フォントには多くの知能が組み込まれており、フォントに内蔵された組版規則を活用できる組版ソフトウェアですぐに利用できるようになっている、ということです。

興味のある読者は OpenType タグ登録簿を参照して、 [script タグ](https://www.microsoft.com/typography/otspec/scripttags.htm) や [language タグ](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) が OpenType 仕様で現在使われているものを確認できます。

### 文字に戻る: さまざまな文字の役割

文字体系（または言語）の基本要素を構成する文字の集合が、すべて同じ役割を果たすわけではありません。たとえば、ほとんどの言語には次のような文字があります: *句読点*のための文字や、数値の *数字* のための文字、そして私たちが *文字* だと考えるアルファベットの文字があります。なお、いくつかの文字体系では、これらの文字は大文字と小文字の形でも存在します。文字の概念はかなり広く、Unicode Standard には、 *表示することを意図していない* が、その役目は「テキストの解釈や表示を制御すること」です。たとえば、アラビア語のテキストを組版する際に、ある文字の連接動作を強制したり抑止したりしたいことがあります。Unicode Standard には、それを行うための特別な制御文字が用意されています。いわゆる [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) と [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner)です。これらの文字は表示を目的とせず、意図した視覚効果を得るためにテキスト処理中にソフトウェアに「吸収」されます。

Unicode Standard で定義されているすべての文字には、一連のプロパティが割り当てられており、それによって実質的に Unicode 符号化における各文字の役割と目的が記述されています。LATIN SMALL LETTER A のような文字名は、文字のプロパティ一覧の 1 要素にすぎません。これらのプロパティは [Unicode Character Database (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 Standard は世界中の文字を符号化するために 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 までの値を保存しなければならない場合、保存単位はどれくらいの大きさである必要があるのでしょうか。明らかに、1 バイトの保存単位が持てる最大値は 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 エンジンはテキストや LaTeX の入力ファイルを「UTF-8 形式」で読み込む、と説明されているのにほぼ確実に出会います。では「UTF-8 形式」とは何で、Unicode とどう関係するのでしょうか。Unicode の用語では、世界中の文字を符号化するために使われる 0 から 1,114,111 までの 1,114,112 個の値のそれぞれを [コードポイント](http://www.unicode.org/glossary/#code_point).

私たちは見てきたように、 *理論上は*、Unicode で符号化されたテキスト全体を表すには、1 文字につき 4 バイトで保存する必要があります。しかし実際には、ある賢明な人々が、1 つの Unicode 数値（コードポイント）を *列* より小さな数値の列として表す簡単な方法を考案しました。これらの小さな数値のそれぞれは 1 バイトに格納されます。この処理は *変換します* 単一の（より大きな）整数を、より小さな（バイトサイズの）整数の列へ変換するものです。この変換により、テキストファイル内の各文字はもはや 1 つの数値で表されるのではなく、各文字は *マルチバイト列*になります。テキストファイル内の 1 から 4 個の（連続した）バイトで、1 つの個別の Unicode 文字（つまり、そのコードポイント値）を表せます。

UTF は *Unicode Transformation Format* の略であり、ここで重要なのは *Transformation*です。本質的には、UTF-8 は 1 つの Unicode コードポイント値を 1 から 4 個のバイトサイズの断片へ変換するための「レシピ」またはアルゴリズムだと考えることができます。Unicode コードポイントの値が大きくなるほど、UTF-8 形式でそれを表すのに必要な単一バイトの数も増えます。

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（10 進）または 0644（16 進）が割り当てられています。UTF-8 での表現は *2 バイトの* 列 D9 84（16 進）、10 進では 217 132 です。テキストを保存する形式として UTF-8 を使う場合、ل を表すために単一の数値 1604 を含むテキストファイルではなく、それは 2 つのバイトサイズの値 217 と 132 に変換されます。文字 ل は *2 バイト列*として保存されます。UTF-8 アルゴリズムをさらに詳しく調べたい読者は、詳細な説明と C コードを私の [個人ブログサイト](http://www.readytext.co.uk/?p=1284).

ソフトウェア（たとえば XeTeX や LuaTeX）が UTF-8 形式のテキストを読み込むと、そのソフトウェアはそのファイルに含まれる各文字の Unicode 値を判断する必要があるため、アルゴリズムを使って *逆にする* UTF-8 の変換過程を逆にたどります。その「逆変換アルゴリズム」によって 2 つのバイト（217 と 132）が再結合されて整数 1604 が生成され、それがアラビア文字 ل の Unicode コードポイント値として認識されます。

要するに、UTF-8 は Unicode で符号化されたテキストの保存と転送に使われる中間データ形式にすぎません。

**注**：一部のシステムでは、1 文字あたり 32 ビットを使ってテキストを保存することを選びます。これは [UTF-32](https://en.wikipedia.org/wiki/UTF-32)と呼ばれます。さらに [UTF-16](https://en.wikipedia.org/wiki/UTF-16) もありますが、Unicode で符号化されたテキストを保存する最も一般的な方法は UTF-8 です。

## 多言語 TeX ファイル: XeTeX と LuaTeX

XeTeX も LuaTeX も、非常に高度な多言語組版が可能ですが、その実現方法はかなり異なっており、それぞれのエンジンの設計・開発哲学を反映しています。ここでは深く掘り下げませんが、XeTeX エンジンには LuaTeX には存在しないソフトウェアコンポーネント（実行ファイルに組み込まれたもの）が含まれており、とりわけ次の処理のためのソフトウェアが挙げられます *OpenType シェーピング* （たとえば、次のライブラリを通じて [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

これに対して LuaTeX は別のアプローチを採用します。実際の TeX エンジンに機能を直接組み込むのではなく、LuaTeX は非常に豊富なコマンド群（TeX のプリミティブ）と、非常に強力な [Lua ベースの API](/latex/ja/xiang-xi-ji-shi/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) を提供しており、開発者はそれを通じて多言語組版のための同等に高度なソリューションを構築できます。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 つの異なる形のいずれかを取る可能性があります:

* 単独で表示されるかどうか、つまり他と結合しない単独（孤立）文字として表示されるかどうか;
* 単語の中に現れるかどうか—単語の先頭・中央・末尾のいずれかにあるかどうか。これは *語頭*, *語中* や *完成版* の形です。

アラビア文字体系の各文字には独自の連接規則があり、左、右、あるいは左右に別の文字があるときに形や見た目が変わる場合もあれば、変わらない場合もあります。これをさらに調べたい読者は [Wikipedia に完全な一覧があります](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### 例: UTF-8 におけるアラビア語と英語のテキスト

英語とアラビア語のテキストを 1 行だけ含む UTF-8 テキストファイルを作成するとします。This is العَرَبِيَّة text!

この 1 行のテキストには、スペース 3 個、英語（ラテン文字体系）の文字 11 個、アラビア語の文字 12 個が含まれています（ただし、それはすぐには明白ではないかもしれません）。UTF-8 テキストファイルとして保存すると、以下の理由により 38 バイトのストレージを占有します:

* **ラテン文字体系**：スペースと英語テキスト: 14 × 1 バイト文字 = 14 バイト;
* **アラビア文字体系**：アラビア文字 12 文字 × 1 文字あたり 2 バイト = 24 バイト。

合計 14 + 24 = 38 バイトです。

#### さらに掘り下げると

この例のテキストを、次の名前の UTF-8 ファイルとして保存すると `arabic.txt` 、それを 16 進エディタで開けば、含まれている実際のバイトを調べることができます。次の注釈付きスクリーンショットを見ると、アラビア語のテキストは 1 文字あたり 2 バイトで保存されていることがわかります:

![英語とアラビア語のテキストを含む UTF-8 テキストファイルを 16 進エディタで開いた画像。](/files/664383364a0b3a7f261e73de7f66037856e1afc5)

英語とアラビア語のテキストを含む UTF-8 テキストファイルを 16 進エディタで開いた画像。ラテン文字体系の文字は 1 バイトで表される一方、アラビア文字体系の文字は 1 文字あたり 2 バイトで保存されていることがはっきりわかります。

このスクリーンショットから、いくつか観察できます:

* アラビア語のテキストは左から右への順序で保存されており、文字は加工されていない生の（孤立形の）アラビア文字および母音記号のままです;
* ラテン文字体系の「This is 」の後に、このファイルを読むソフトウェアへ次の文字がアラビア文字体系であることを知らせる追加情報はありません。

多言語文書（たとえば英語とアラビア語を含むもの）を組版する場合、入力テキストファイルをバイト列として読み取る過程で、XeTeX や LuaTeX は各文字の開始と終了を検出し、UTF-8 の変換を逆に行って対応する Unicode コードポイントを生成するのに必要な正しいバイト数を読み取らなければなりません。この処理を可能にしているのが UTF-8 アルゴリズムそのものであり、各文字の最初のバイトを検出し、対応する Unicode コードポイントを計算するために何バイト読む必要があるかを判断できるようにしています。UTF-8 は使うのは簡単ですが、実に巧妙です。

#### 論理順、表示順、および OpenType シェーピング

上のアラビア語（العَرَبِيَّة）をよく見ると、私たちのテキストファイルに実際に 12 個の個別のアラビア文字が含まれていることを見抜くのは難しいかもしれません。特にアラビア文字体系に不慣れならなおさらです！ しかし、上のスクリーンショットの右側に表示されているアラビア文字を注意深く数えると、合計 12 個あることがわかります。

アラビア語のような複雑文字体系の言語では、私たちのテキストファイルが *保存するだけです* 、そしてあなたが *画面上で見るもの* は見た目にも *非常に* まったく異なります！ そのテキストを、たとえばブラウザで見たときに表示されるものは（使うフォントによりますが）次のようになります:

![組版されたアラビア語テキストの画像](/files/ca3a14e2403cc489ccafbb90bc7b35cf4632e8e0)

しかし、上のスクリーンショットが示すように、UTF-8 テキストファイルが実際に含んでいるのは次のものです:

![非組版のアラビア語テキストの画像（孤立形の文字）](/files/65e261b001df4613ab4cee3c0f936924d68b0181)

アラビア文字体系の連綿的な性質に不慣れであっても、テキストファイルに含まれるアラビア文字が、組版や画面上での表示に至る過程で（グリフとして）「何か」が起きていることは、はっきりわかります。単純な文字体系の言語、たとえばラテン系言語で TeX/LaTeX を使い慣れていると、これは本当に混乱を招きます。

ここではいくつか重要な概念が関わっています。Unicode テキストファイルは…まあ、テキスト（Unicode）を保存する仕事をしており、一方、組版および表示システムはフォントとグリフ（OpenType）を使う仕事をしているからです:

* テキストファイルはアラビア文字を左から右の順で保存していましたが、アラビア語は右から左へ読み/表示されます。テキストファイルはテキストをいわゆる *論理順*;
* で保存しているのです。テキストファイルには、画面に表示される実際の見た目とはかなり異なる個々の文字が含まれています。つまり、テキストファイルにはアラビア文字が孤立形、非連結形で含まれています。

#### 何が起きているのでしょうか？

テキストファイルの中では、アラビア語は孤立形の文字の左から右への並びとして保存されます。考えてみれば、テキストファイルはアラビア語テキストを *入力された順序で* （the *論理順*保存しているのです）。そのテキストが表示用に処理される、あるいは組版されるときに初めて、正しい読み順で表示されます。これはしばしば *視覚順* または *表示順*と呼ばれます。さらに、アラビア文字の孤立形は *シェーピングされ* て、組版上正しい表示形へと変換されます。これを考える一つの方法は、単純なテキストファイルはテキスト（Unicode 文字）を可能な限り最も基本的な形、つまり生の、加工されていない個々の文字として保存しなければならず、それらの文字を表示用にレンダリングするのは、利用可能なオペレーティングシステム、フォント、組版/レンダリングソフトウェアに基づくシステムソフトウェアの役目だ、というものです。

そのファイル内のアラビア語テキストが組版/表示されるとき、それは *シェーピング*という処理を受けます。個々のアラビア文字はシェーピングされたグリフに変換され、アラビア文字体系および書記体系の連接規則に従って必要な各文字の変種が正しく表現されます。さらに、高品質の組版ソフトウェア（良い OpenType フォントを使用するもの）は、次の処理と呼ばれる追加の組版上の洗練を適用することで、さらなる処理を行います *OpenType シェーピング*—以下を含みうる、幅広い組版処理を含むプロセスです：

* 複数の個々の字形を 1 つの複合リガチャ字形に置き換えること（アラビア語では非常によく見られます）、または
* たとえば、どの字形の上または下にあるかに基づいて、アラビア語の母音記号の位置を調整する配置処理。

![組版時にアラビア語テキストに生じる変化を示す画像](/files/ff9f80518bfade799432a09328cc2aeac58f94cb)

論理順序と視覚（表示）順序の違い。この図では、テキストファイルに保存されたアラビア文字が、表示または組版される際に並べ替えと字形変換を受けることがわかります。

高度な OpenType フォントの設計者や制作者は、フォントに組み込まれた高度な組版機能を提供するために、非常に多くの時間と専門知識を注いでいます。

アラビア語テキストに適用されている字形変換をオフにするには、優れた無料の [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) Unicode テキストエディター（Windows 専用）を使うと、字形変換を無効にして、テキストファイル内に実際に存在する、結合されていない（字形変換前の）個々の文字を確認できます—次の合成スクリーンショットの下半分を参照してください：

![BabelPad テキストエディターで OpenType の字形変換をオフにできることを示す画像](/files/318faec3ccd54a7ef744f752a0fc444078f8ba73)

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/ja/xiang-xi-ji-shi/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.