Unicode標準の範囲外では、文字は1つ以上の書記で構成されるテキストの個別の単位です。。Unicode標準で「文字」と定義されているのは、実際には書記素と文字の混合です。Unicodeは、並置された書記素を個々の文字として解釈するためのルールを提供します。
Unicodeの コードポイントは、それぞれに割り当てられた固有の番号であるUnicode文字（文字または書記素のいずれかです）。
残念ながら、Unicodeの規則により、並置された一部の書記素は、独自のコードポイント（合成済みの形式）を既に持っている他の書記素として解釈できます。つまり、Unicodeには文字を表現する方法が複数あります。Unicode正規化はこの問題に対処します。
グリフは、文字を視覚的に表現したものです。フォントは、（Unicode文字ではなく）特定の文字セットに一連のグリフを提供します。すべての文字に対して、可能なグリフの数は無限です。
マークアメリーへの返信
まず、先に述べたように、各文字には可能なグリフの数が無限にあるため、文字は「常に単一のグリフで表される」わけではありません。Unicodeはグリフとあまり関係がなく、コードチャートで定義されているものはグリフではありません。問題は、どちらもすべてのキャラクターではないということです。それで、彼らは何ですか？
より大きな実体、書記素または文字はどれですか？文字や句読点ではないテキストのグラフィック要素を何と呼びますか？すぐに思い浮かぶのが「書記素」です。これは、「テキスト内のグラフィカルユニット」の概念を正確に想起させる言葉です。私はこの定義を提供します：書記素は、書面での最小の個別のコンポーネントです。
逆に言えば、書記素は文字で構成されていると言うこともできますが、それらは「中国語の書記素」と呼ばれ、中国の書記素を構成するすべてのビットとピースは、代わりに「文字」と呼ばれる必要があります。しかし、それはすべて逆です。書記素は、特徴的な小さな断片です。キャラクターはより発達しています。「グリフは合成可能」という語句は、Unicodeのコンテキストでは「文字は合成可能」としてより適切に記述されます。
Unicodeは文字を定義しますが、他の書記素や文字で構成される書記素も定義します。あなたが作成したそれらの怪物は、この良い例です。もし彼らが多分それに追いついたら、彼らは新しいバージョンのユニコードで独自のコードポイントを得るでしょう;）
これにはすべて再帰的な要素があります。より高いレベルでは、書記素は文字になり、書記素になりますが、書記素はずっと下にあります。
TSへの返信
第1章標準のでは、「Unicode文字エンコーディングは、アルファベット文字、表意文字、および記号を同等に扱います。つまり、これらは任意の組み合わせで、同等の機能で使用できます。」この声明が与えられれば、規格内の用語の融合に備える必要があります。標準が発展するにつれ、適切な用語が振り返ってみると明らかになることがあります。
言語の正式な定義では、2つの基本的なものが相互に定義されていることがよくあります。たとえば、
XMLでは、要素は開始タグとして定義され、その後にコンテンツが続き、その後に終了タグが続きます。コンテンツは、要素、文字データ、または他のいくつかの可能なものとして順に定義されます。自己参照定義のパターンは、Unicode標準でも暗黙的です。
書記素は、コードポイントまたは文字です。
文字は、1つ以上の書記素のシーケンスから構成されます。
最初にこれらの2つの定義に直面したとき、読者はコードポイントが文字であるという理由で最初の定義に反対するかもしれませんが、常にそうであるとは限りません。図2.7に示すように、2つのコードポイントのシーケンスは、正規化の下で1つのコードポイントをエンコードする場合があり
、そのエンコードされたコードポイントは文字を表し
ます。他のコードポイントをエンコードするコードポイントのシーケンス。これは少しトリッキーになっており、UTF-8などの文字エンコーディングスキームを使用してコードポイントをバイトシーケンスにエンコードする層にも到達していません。
一部のコンテキストでは、たとえば、発音区別符号に関する学術記事
や、文字の個々の部分が単独でテキストに表示される場合があります。そのコンテキストでは、個々の文字部分は文字と見なすことができるため、Unicode標準も同様に柔軟であることに意味があります。
マーク・エイブリーが指摘したように、キャラクターはより複雑なものに構成することができます。つまり、必要に応じて、各文字を書記素として使用できます。すべての構成の最終結果は、「ユーザーがキャラクターとして考える」ものです。標準でもこのディスカッションでも、最高レベルではユーザーが個々の文字として考えるこれらのものがテキストにあるという考えには、実際の抵抗はないようです。その用語のオーバーロードを回避するために、文字を構成するために使用されるパーツを参照したいすべての場合に「書記素」を使用できます。
時々、ユニコード標準はその用語で至る所にあります。たとえば、第3章で
はUTF-8を「エンコーディングフォーム」として定義していますが、用語集では「エンコーディングフォーム」を別のものとして定義し、UTF-8を「文字エンコーディングスキーム」として定義しています。もう1つの例は、「Grapheme_Base」と「Grapheme_Extend」です。これらは間違いであることが認められていますが、それらを削除することは少しのタスクなので、それは持続します。規格で採用されている用語を厳しくするために行うべき作業がまだあります。
「書体とは、ユーザーが文字と考えるものに対応する1つ以上のエンコードされた文字のシーケンスである」と述べたときに、COMBINING GRAPHEME JOINERの追加に関する提案が間違っていました。代わりに、「1つまたは複数の書記素のシーケンスは、ユーザーが文字として考えるものを構成します」と読む必要があります。次に、「文字シーケンス」という用語とは区別して「書記シーケンス」という用語を使用できます。どちらの用語も役に立ちます。「書記素シーケンス」は、小さな断片からキャラクターを構築するプロセスを適切に意味します。「文字シーケンス」とは、私たち全員が通常、直感的に意味するものを意味します。「ユーザーが文字と考えるもののシーケンス」。
プログラマーが本当に書記素シーケンスのレベルで操作したい場合があるので、それらのシーケンスを検査および操作するメカニズムが利用できるはずですが、通常、テキストを処理するときは、「文字シーケンス」（ユーザーが考えていること）を操作するだけで十分です。キャラクターとして）、システムに下位レベルの詳細を管理させます。
この説明でこれまでに取り上げたすべてのケースで、「grapheme」を使用して分割不可能なコンポーネントを参照し、「character」を使用して合成エンティティを参照する方がわかりやすくなっています。この使用法は、両方の用語の長い間確立された意味をよりよく反映しています。