「グリフ」と「キャラクター」の実際の違いは何ですか？

この質問はタイポグラフィのサイトの提案で見ましたが、答えがわからないのではと悩みました。私は常に「グリフ」と「キャラクター」を交換可能として扱いました。

Unicode Character Encoding Modelページで説明を読んだ後、私の理解は大体次のとおりです。

• 文字は、言語の意味、グリフ、外観によって定義されます。したがって、審美的に組み合わせるための合字fi は、1つのグリフですが、2つの文字です。

だから、私の信念は（私が間違っている場合は私を修正してください）実用的な違いは次のようになります：

• テキストの審美性に興味のないテキストパーサーは、グリフをそれぞれの文字として読み取ります。そう：
  • グリフを含むテキストをコピーしてプレーンテキストエディタに貼り付けると、グリフはそれぞれの文字に変換されます（fi 合字グリフはfandになりますi）
  • テキスト解析に基づいた適切に作成された自動化システム（検索エンジンクローラー、スクリーンリーダー、スペルチェッカー）は、グリフをそれぞれの文字として解釈します。
  • 1つの文字に多数のグリフまたはグリフセットを含めることができます。1つのグリフには1つの文字しか使用できないと言いたいのですが、リンクされた記事に3つのグリフと、それぞれが文字と文字のセットに対応しているように見えるグリフセットの例があるので、これは明らかに正しくありません。私はこれがどのように機能するのかよくわかりません：確かにそれはそれらのグリフが解釈される方法に一貫性や曖昧さがあり、インタープリターによって異なることを意味しますか？（または、言語やフォントによって異なりますか？）
  • グリフブラウザ（Illustratorのブラウザなど）にはフォントの完全なグリフセットが含まれていますが、文字マップ（Windowsの文字マップなど）には文字のみが含まれ、合字のような複数の文字であるグリフは含まれていません（これまで気づかなかったもの）

だけではなく、「一つのグリフ複数の文字」ものが、また、合字と行動をコピー＆ペーストすることはできません：私はほとんどそこだけど、私ははっきりと線に沿って誤解何かどこかをしたような気がかなり私が期待したもの：

• リガチャーfiをIllustratorからこの入力ボックスにコピーしますfi。期待どおりに（2文字）貼り付けます。
• HTMLコードを貼り付けfiます（）-コードブロックにないときに合字として表示します（Fi-このフォントでは合字のようには見えませんが、半分だけを選択すると表示されます） ）、およびコードブロック内のコード（fi）、期待どおり。
• レンダリングされた非コードブロック合字をコピーして入力ボックスに貼り付けます。合字文字として貼り付けられ、コードブロック内にあるかどうかに関係なく合字としてレンダリングされます（FIおよびfi）。同様にそれを含む単語：適合ミスフィット（fit misfits）適合ミスフィットとしてペースト（fit misfits）。たぶん、貼り付けられている場所が使用されているエンコーディングを理解しているかどうかに依存しますか？

私の理解はどこまで間違っていますか？誰かが私を正しく言うことができます：グリフと文字の違いの明確な定義を述べて（私のものが間違っているか改善できる場合）、実際にそれが意味するものよりも明確/より正確な例を挙げてください？

グリフはテキストのレンダリング方法、文字はテキストの解釈方法に関連しています。コピー＆ペーストするとき、ソースアプリケーションは通常いくつかの形式の選択を提供します。プレーンテキストはfiの合字をfとiに分解します。HTML形式は、引用符で囲まれたcharエンティティに変換するか、fとiで分解します。

一般に、文字とグリフの関係はn：mです。インド語では、文字の一部が2つのグリフに分割され、単語の異なる場所に配置されます。ラテン語では、その状況に最も近いのは、éを2つのグリフ（eおよび ´）としてレンダリングすることです。アラビア語では、単語内の位置に応じて、各文字に異なるグリフがあります：初期、中間、最終、または孤立。

文字からグリフへの翻訳は、各アプリケーションおよびそれがサポートする活版印刷機能に固有です。ラテン語のテキストの場合、この翻訳は以前は簡単でしたが、OpenTypeフォントには合字、スワッシュ、代替形式、スモールキャップなどの追加機能が導入されていました。

実用上の理由から、アプリケーションがテキストをレンダリングする方法を実装するとき、フォントを設計するとき、または一部のグリフを他のグリフに置き換えるOpenType機能（合字など）を適用するときに、グリフにのみ関心があります。それ以外の場合、Unicodeコードポイントはあなたの友人です。

私はあなたの理解が間違っているとは思わない。あなたが望むと思うものを貼り付けることによってユーザーを助けようとするシステムを見ているだけだ。一部の合字（「fi」、「fl」）は植字システム以外ではかなり一般的であるため、ソフトウェアはユーザーがおそらくそのグリフを入力しなかったことを認識し、別のアプリが入力された文字を変換しました。

要するに、文字とは言語単位を指します。グリフは、大文字、小文字、スモールキャップ、歴史的、または文体的なバリエーションのいずれであっても、そのユニットの設計されたインスタンスを指します。

ここには、グリフと文字に関する適切な情報を提供する回答がいくつかありますが、コピーと貼り付けに関する混乱の原因に実際には対処していません。

まず、あなたの理解は根本的に正しいです：

文字は、言語の意味、グリフ、外観によって 定義されます。したがって、fiを審美的に結合するための合字は1つのグリフですが、2つの文字です。

文字のリストは、テキストを機械可読形式でエンコードする権限があるため、Unicode Consortiumによって公開されているUnicode標準によって定義されていることを強調する価値があります。上記の定義は基本的に、Unicodeコンソーシアムのメンバーが、Unicodeへの追加の提案が文字であるため含める価値があるかどうか、またはグリフでありフォントレンダラーで処理する必要があるかどうかを判断するために使用する主要なガイドラインです。

上記であなたが経験した混乱は、ユニコードにいくつかの合字（グリフではない）が存在するという事実によるものだったので、私はこれに言及します。たとえば、U+FB01合字の文字は次のとおりです。http： //unicode.org/charts/PDF/UFB00.pdf

Unicodeで合字を使用することは、文字としてUnicode規格にどのような種類のものを含めるべきかについて、上記の定義の精神には実際にはありません。ユニコードの人々は自然にこれを認識しており、合字に関するユニコードのFAQも同様に認めています。

既存の合字は、基本的に互換性と非Unicode文字セットとのラウンドトリップのために存在します。それらの使用は推奨されません。

このキャラクターの存在は、最終的に混乱の原因となります。

正しく実装されたソフトウェアでは、テキストのコピーでは、グリフではなく、指定された文字を常にコピーする必要があります。これが3つの例で行われていることです。

1）最初の例では、Illustratorに入力fしiて、単一の合字グリフをレンダリングしました。レンダリングされたグリフを選択してコピーすると、Illustratorはf（U+0066）およびi（U+0069）文字をクリップボードに正しくコピーしました。

2）第二の例では、結紮のためのHTMLコードを入力した文字（&#64257）入力ボックスにして、正しく結紮ましたグリフ結紮表す文字を（。根底にあるので、文字は実際に私が言及した曖昧な、比較的無意味リガチャー文字です上記では、そのグリフを選択すると単一の文字がコピーされますU+FB01。

3）3番目の例では、パート2でレンダリングされた、レンダリングされた合字キャラクター U+FB01をコピーします。これは、常にそのキャラクターとして貼り付けられます。主な混乱は、HTMLエンティティコードと文字の違い、特にそれらがコードブロックの内外でどのようにレンダリングされるかという点に関するもののようです。

HTMLエンティティコードfiは、8つの異なる文字の文字列です。WebブラウザーのHTMLレンダラーは、これらの8文字U+0026 U+0023 U+0036 U+0032 U+0035 U+0037 U+0023を単一の Unicode文字U+FB01で置き換え、適切にレンダリングします。ただし、<code>HTML のタグはこの動作を無効にし、これらの8文字をそのままにします。

レンダリングされたHTMLからコピーすると、レンダリングされた文字（レンダリングされたグリフとは異なります）をコピーします。したがって、レンダリングされたHTMLエンティティをコピーすると、単一のU+FB01文字がクリップボードにコピーされます。

fi U+FB01文字をHTMLに貼り付けると、置換を行う必要がありません<code>。つまり、ブロック内にあるかどうかに関係なく、文字は合字としてレンダリングされます。

文字とは、テキストファイルに格納され、アプリケーションによって処理され、動き回る文字のことで、グリフは視覚的な表現です。

明確な画像を得るために、アプリケーションが画面上にテキスト文字列をレンダリングしようとしたときに何が起こるかを見てみましょう（少し簡略化した方法で）：

• アプリケーションは最初にテキスト文字列、つまりディスクまたはメモリに保存されている文字列を読み取ります。
• 次に、目的のフォント、テキスト言語などの他のプロパティの中で、テキストレイアウトエンジンに送信します。
  • テキストレイアウトエンジンは、基本的には、各文字に対応するグリフ（複数可）のためにそれを要求し、（のためのグリフを置き換えるようないくつかのグリフ置換を行い、フォントファイルを開くfと、i合字グリフのとfiと（カーニングのように）配置します）。
  • 最後に、レイアウトエンジンには、一連のグリフ、互いに対する相対的な位置、および入力文字と出力グリフ間のマッピングがあります。文字からグリフへのマッピングは、単語の最初の2文字がfile2つの最初のグリフ（fi合字）、3番目の文字が2番目のグリフ、4番目の文字が3番目のグリフに対応することを認識できるようにします。
• 次に、グラフィックレンダリングライブラリを使用して、フォントの図形を使用して画面にこれらのグリフを「描画」します。
• ユーザーが画面で「グリフ」を選択すると、アプリケーションはレイアウトエンジンが提供するグリフからテキストへのマッピングを参照して、入力テキストのどの部分がユーザーの選択内容に対応するかを見つけ、そのテキストをクリップボードに送信しますユーザーがそれをコピーします。
• ユーザーがカーソルをテキストの真ん中に挿入して入力を開始すると、同じことが起こります。マッピングは、入力テキストの新しい文字を挿入する場所を決定し、更新テキストは処理および再描画などのためにレイアウトエンジンに送信されます。