「charset」が一般的な使用法で「エンコード」を本当に意味するのはなぜですか？

私を長い間混乱させてきたのは、多くのソフトウェアが「charset」と「encoding」という用語を同義語として使用していることです。

人々がユニコードの「エンコーディング」に言及するとき、それらは常にユニコード文字をASCIIやUTF-8のようなバイトのシーケンスとして表すためのルールセットを意味します。これは合理的で直感的なようです。これは、指定したルールセットを使用して、これらの文字をバイトとして「エンコード」するという考え方です。

これらのルールセットは、すべてのユニコード文字の一部のサブセットを「エンコード」する機能しか提供しないことがあるので、「文字セット」の短縮形である「文字セット」は、ユニコード文字のセットを意味するだけで、これらの文字はエンコードされます。したがって、エンコーディングは文字セットを意味します（128文字のエンコードに関するルールのみを持つASCIIのようなエンコーディングは、それらの128文字の文字セットに関連付けられます）が、文字セットはエンコーディングを意味する必要はありません（たとえば、UTF-8、UTF） -16とUTF-32はすべて異なるエンコーディングですが、同じ文字セットをエンコードできます）。

それでも-そして、これが私の質問の核心です-「charset」という単語の実際の用法は、単語の構成が意味するものと一致しません。ほとんどの場合、「エンコード」を意味するために使用されます。

例えば：

• charsetHTML の属性は、エンコーディングを指定するために使用されます
• CharsetJavaのsはエンコーディングです
• charsetsとcharacter setsMySQLでは、これもエンコーディングです。

この好奇心の強い（乱用）言語の使用は何歳ですか？この「直感的ではない」「文字セット」の定義はどのようにして生まれましたか？それはおそらく、実際に、使用中のエンコーディングとそれらがサポートする文字セットとの間に1対1のマッピングが実際にあった時代に由来するのでしょうか？それとも、この単語の定義を規定する特に影響力のある標準や仕様はありましたか？

文字セットの概念はUnicodeより古いものです。

Unicode以前は、文字セットは文字のセットと、各文字をビットとして表す方法を定義していました。ほとんどの文字セットは、文字をバイト（256文字のセットを許可）にマップし、一部は2バイトにマップし、一部（ASCIIなど）は7ビットのみにマップしました。異なる文字セットでは同じ文字に異なる値が割り当てられることが多く、使用されているさまざまな文字セット間にユニバーサル変換キーがありませんでした。

Unicodeは、さまざまな文字セットをすべて共通の「スーパーセット」に統合することにより、この問題を解決する試みでした。この目的のために、Unicodeはいくつかの追加の抽象化レベルを導入しました。たとえば、コードポイント値とは別のものとしての文字エンコーディングの概念。これにより、Unicode は、Unicode 以前の文字セットをUnicode文字エンコーディングとして再定義できました。

たとえば、HTMLのcharset属性（HTTP content-typeヘッダーのcharsetパラメータを反映）は、Unicodeが広く採用される前のものですが、インターネットのユニバーサル文字セットとしてUnicodeを受け入れることが決定されたとき、charset属性は使用中のエンコーディングを指定するために再定義されただけですが、下位互換性を保つために名前は変更されていません。

「文字セット」という用語は、もちろん「文字セット」の略です。これは、文字エンコードに使用される古い用語であり、a）バイトと文字のシーケンス間のマッピング、b）整数間のマッピングとして解釈できます。 （コード番号）と文字またはc）抽象文字と整数またはバイトのシーケンスの間のマッピング。

「キャラクターセット」は短くてシンプルな表現なので、採用されました。その中で、「セット」は漠然とした意味を持っています（概念全体が曖昧であるため）が、ダンコネリーの（かつての）有名な文字セットで説明されているように、コレクション（セットの理論的な意味での「セット」）として誤って解釈されることがよくあります。有害と見なされます。

そのとき最も重要だったのは、識別子charsetがMIMEとHTTPで使用されるようになったことです。HTTP 1.0エイリアスRFC 1945はMIME定義を引用し、「オクテットのシーケンスを文字のシーケンスに変換するために1つ以上のテーブルで使用される方法」と混乱についてコメントします。「この「文字セット」という用語の使用は、一般に「文字エンコーディング」と呼ばれます。ただし、HTTPとMIMEは同じレジストリを共有するため、用語も共有することが重要です。」

RFC2045はMIMEに「文字セット」を導入しましたが、そのときまでに、すべてのエンコーディングが1つの文字を1つのオクテットにマッピングしているわけではありませんでした。RFC2130はこの履歴についてもう少し詳しく説明しています。

基本的に、「charset」は、これらの標準が作成されたときにより一般的な用語でした。「文字エンコーディング」や「テキストエンコーディングスキーム」よりも簡潔で、「エンコーディング」よりもあいまいではありません。

テキストの転送に適用できるエンコーディングは少なくとも2つあります。文字エンコードは、文字（グリフ）のエンコード方法を示します。すべての言語は、多くの場合8ビット値にエンコードされるUCS文字セットのサブセットを使用します。標準化された文字セットには標準の文字エンコーディングがあり、これらの用語は一般的に互換的に使用されます。

転送エンコーディングは、テキストの転送方法を記述し、通常は文字エンコーディングとは無関係です。ほとんどの転送エンコーディングは透過的ではなく、転送されるバイトシーケンスを変更します。8ビット転送エンコーディングは、8ビットエンコーディングに対して透過的です。7ビット転送エンコーディングは、ASCIIなどの7ビット文字セットのみを転送できます。

ASCIIは、7ビットでエンコードされた95の印刷可能な文字とキャリッジコントロール（ラインフィード、フォームフィード、キャリッジリターン、バックスペース、およびタブ）にさらに数文字を使用します。残りの値を使用する追加の制御文字があります。ASCIIは、UCS文字セットおよび8ビット文字セットの多くの適切なサブセットです。ISO-8859-1もUCS文字セットの適切なサブセットですが、これらの文字は、127より大きい文字値に複数のバイトを使用するUTF-8で異なるエンコーディングを持っています。

IBMメインフレームは、異なる8ビットエンコーディングを使用するEBCDIDを使用します。ASCIIとECBDICの文字エンコーディング間で印刷可能な文字をマッピングする変換テーブルがあります。ECBDICには、ASCIIでは使用できない句読点があるため、ASCIIよりも大きな文字セットがあります。これにより、初期エンコードがECBDICである場合、これら2つのエンコード間の完全な往復変換が妨げられる可能性があります。

これらのエンコードは、ASCII印刷可能文字でカバーされていない文字を含む言語には不十分でした。Microsoftなどは、ASCII文字セットに8ビット拡張を使用し、127を超える値を持つ追加の文字をエンコードしました。これらの拡張は、文字セットに最大96文字しか追加しなかったため、すべての言語に単一の拡張では不十分でした。その結果、複数の文字セット（charset）が、異なる8ビット文字エンコーディングの異なる言語で使用されていました。これらの文字セットには、その言語または言語ファミリに必要な文字が含まれています。追加の文字は、異なる文字セットの異なる値にエンコードされる場合があります。英語のユーザーは、長い句読点（左と右の引用符、ダッシュ）でこれに気付く可能性が高く、間違った文字セットが使用されていると、正しく表示されません。

シングルバイトエンコーディングでは、文字セットの文字のみをエンコードできます。一部の言語では、文字セットをカバーするためにマルチバイトエンコーディングが必要でした。Unicode（UCS）文字セットでは、ASCII文字セット以外の文字にマルチバイトエンコーディングが必要です。この文字セットは、すべての言語固有のエンコーディングのスーパーセットです。UTF-8は、UCS文字セットのコンパクトなエンコーディングです。ASCIIは追加のバイトを必要とせず、ほとんど（すべて？）のヨーロッパ言語の文字は1バイトまたは2バイトとしてエンコードできます。完全なUCS-2文字セットは、1〜3バイトでエンコードできます。現在のUCS文字セットのすべての文字は、1〜4バイトにエンコードできます。

FWIW、IIRC、64日前のコモドールでは、文字セットは{0、... 255}からすべてのuxv白黒画像のセットまでの関数であり、uとvはおそらく8と12でした。文字セット」とは、BASIC言語のPOKEコマンドを使用して、それらのイメージを保持するように指定されたメモリ位置を変更することを意味しました。たとえば、ASCIIコード65はAを意味し、Aのイメージは一部のbのメモリアドレスa * 65 + bから格納され、a = u * vと推測します。