「charset」が一般的な使用法で「エンコーディング」を本当に意味するのはなぜですか？
長い間私を混乱させてきたのは、多くのソフトウェアが「charset」と「encoding」という用語を同義語として使用していることです。
人々がユニコードの「エンコーディング」に言及するとき、それらは常にユニコード文字をASCIIやUTF-8のようなバイトのシーケンスとして表すためのルールセットを意味します。これは合理的かつ直感的です。これは、指定したルールセットを使用して、これらの文字をバイトとして「エンコード」するという考え方です。
これらのルールセットは、すべてのUnicode文字の一部のサブセットを「エンコード」する機能しか提供しないことがあるので、「charset」を想像するかもしれません「set」の略文字の「」-単にユニコード文字のセットを意味します-それらの文字がどのようにエンコードされているかは関係ありません。したがって、エンコードは文字セットを意味します（128文字のエンコードのルールのみを持つASCIIのようなエンコードはそれらの128文字の文字セットに関連付けられます）が、文字セットはエンコードを意味する必要はありません（たとえば、UTF-8、UTF） -16とUTF-32はすべて異なるエンコーディングですが、同じ文字セットをエンコードできます）。
それでも-そして、これが私の質問の核心です-単語「charset」の実際の使用法は、単語の構成が意味するものと一致しません。ほとんどの場合、「エンコード」を意味するために使用されます。
例えば：
- HTMLの
charset属性は、エンコーディングを指定するために使用されます Charsets in Java is encodingscharsetsおよびcharacter setsMySQLの場合も、エンコーディングです。
この好奇心の強い（乱用）言語の使用は何歳ですか？この「直感的ではない」「文字セット」の定義はどのようにして生まれましたか？それはおそらく、実際にがあった、実際には、使用中のエンコーディングとそれらがサポートする文字のセットとの1対1のマッピングがあった時期に由来しますか？ ？それとも、この単語の定義を規定する特に影響力のある標準や仕様はありましたか？
文字セットの概念はUnicodeより古いものです。
Unicode以前は、文字セットは文字のセットandを定義し、各文字をビットとして表す方法を示していました。ほとんどの文字セットは、文字をバイト（256文字のセットを許可）にマップし、一部は2バイトにマップし、一部（ASCIIなど）は7ビットのみにマップしました。異なる文字セットでは同じ文字に異なる値が割り当てられることが多く、使用されているさまざまな文字セット間にユニバーサル変換キーがありませんでした。
Unicodeは、さまざまな文字セットをすべて共通の「スーパーセット」に統合することにより、この問題を解決する試みでした。この目的のために、Unicodeはいくつかの追加の抽象化レベルを導入しました。たとえば、文字encodingsの概念をコードポイント値とは別のものとして導入しました。これにより、Unicodeはredefineプレユニコード文字セットをユニコード文字エンコーディングとして使用できました。
たとえば、HTMLのcharset属性（HTTP content-typeヘッダーのcharsetパラメータを反映）は、Unicodeが広く採用される前のものですが、インターネットのユニバーサル文字セットとしてUnicodeを受け入れることが決定されたとき、charset属性は使用中のencodingを指定するために再定義されただけですが、後方互換性を保つために名前は変更されていません。
「文字セット」という用語は、もちろん「文字セット」の略です。これは、文字エンコードに使用される古い用語であり、a）バイトと文字のシーケンス間のマッピング、b）整数間のマッピングとして解釈できます。 （コード番号）と文字またはc）抽象文字と整数またはバイトのシーケンスの間のマッピング。
「キャラクターセット」は短くてシンプルな表現なので、採用されました。その中で、「セット」は漠然とした意味を持っていますが（概念全体が曖昧であるため）、ダンコネリーの（かつての）有名な- 文字セット有害と見なされます 。
そのとき最も重要だったのは、識別子charsetがMIMEとHTTPで使用されたことです。 HTTP 1. エイリアスRFC 1945はMIME定義を引用し、「オクテットのシーケンスを文字のシーケンスに変換するために1つ以上のテーブルで使用される方法」、そして混乱についてコメントします。 「文字セット」という用語はより一般的に「文字エンコーディング」と呼ばれます。ただし、HTTPとMIMEは同じレジストリを共有するため、用語も共有することが重要です。」
テキストの転送に適用できるエンコーディングが少なくとも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ビット文字エンコーディングの異なる言語で使用されていました。 。これらの文字セットには、その言語または言語ファミリに必要な文字が含まれています。追加の文字は、異なる文字セットの異なる値にエンコードされる場合があります。英語のユーザーは、拡張句読点（左と右の引用符、ダッシュ）でこれに気付くでしょう。誤った文字セットが使用されていると、正しく表示されないため、8ビット文字エンコーディングで使用されている文字セットを知ることが重要になります。
シングルバイトエンコーディングでは、文字セットの文字のみをエンコードできます。一部の言語では、文字セットをカバーするためにマルチバイトエンコーディングが必要でした。 Unicode（UCS）文字セットでは、ASCII文字セット以外の文字にはマルチバイトエンコーディングが必要です。この文字セットは、すべての言語固有のエンコーディングのスーパーセットです。UTF-8は、 UCS文字セット。ASCII追加のバイトは不要で、ほとんど（すべて？）のヨーロッパ言語の文字は1バイトまたは2バイトとしてエンコードできます。完全なUCS-2文字セットは1バイトでエンコードできます。現在のUCS文字セットのすべての文字を1〜4バイトにエンコードできます。
FWIW、IIRC、64日前のコモドールでは、文字セットは{0、... 255}から、すべてのuxv白黒画像のセットまでの関数で、uとvはおそらく8と12でした。文字セット」とは、BASIC言語のPOKEコマンドを使用して、これらのイメージを保持するように指定されたメモリ位置を変更することを意味しました。たとえば、ASCIIコード65はAを意味し、Aのイメージはメモリアドレスa * 65 + bから開始して一部のbに格納されますが、a = u * vと推測します。