UTF-8よりもASCIIエンコードを選択する利点は何ですか？

ASCIIのすべての文字は、ストレージを増やすことなくUTF-8を使用してエンコードできます（どちらも1バイトのストレージが必要です）。

UTF-8には、「ASCII文字」を超える文字サポートの利点があります。その場合は、なぜ我々がします今までに UTF-8を超えるASCIIエンコードを選ぶのか？

UTF-8の代わりにASCIIを選択するユースケースはありますか？

場合によっては、個々のキャラクターへのアクセスを高速化できます。str='ABC'UTF8およびASCIIでエンコードされた文字列を想像してください（そして、言語/コンパイラ/データベースがエンコードについて知っていると仮定します）

C多くのプログラミング言語で採用されている配列アクセス演算子を使用して、この文字列から3番目の文字（）にアクセスするには、次のようにしc = str[2]ます。

これで、文字列がASCIIエンコードされている場合、必要なことは、文字列から3番目のバイトをフェッチすることだけです。

ただし、文字列がUTF-8でエンコードされている場合、最初の文字が1バイトまたは2バイトの文字であるかどうかを最初にチェックする必要があり、次に2番目の文字で同じチェックを実行する必要があり、その後のみ3番目の文字にアクセスできます。パフォーマンスの違いは、文字列が長くなるほど大きくなります。

これは、たとえば、UTF-8でエンコードされたVARCHARの「後」に配置された列の先頭を検索するデータベースエンジンでの問題です。データベースは、VARCHARフィールドに文字数だけでなく、それぞれが使用する多くのバイト。

UTF-8のUS-ASCII（またはISO 646）サブセットのみを使用する場合、どちらにも実質的な利点はありません。実際、すべてが同じようにエンコードされます。

US-ASCII文字セットを超えて、（たとえば）典型的な西ヨーロッパ言語で使用されるアクセント、ウムラウトなどの文字を使用する場合、違いがあります。 ISO 8859では1バイトでエンコードされますが、UTF-8でエンコードされる場合は2バイト以上が必要になります。欠点は、もちろん、もあります：ISO 8859を使用すると、帯域外のいくつかを使用すると、使用されているエンコーディングを指定することを意味する必要があり、それが唯一のサポート1を一度にこれらの言語の。たとえば、キリル文字（ロシア語、ベラルーシ語など）のすべての文字を1バイトのみを使用してエンコードできますが、それらをフランス語またはスペイン語の文字（US-ASCII以外の文字と混合する必要がある場合） / ISO 646サブセット）かなり運が悪い-それを行うには文字セットを完全に変更する必要があります。

ISO 8859は、実際にはヨーロッパのアルファベットに対してのみ有用です。ほとんどの中国語、日本語、韓国語、アラビア語などのアルファベットで使用されるほとんどのアルファベットをサポートするには、まったく異なるエンコーディングを使用する必要があります。これらのいくつか（たとえば、日本語のシフトJIS）は、対処する絶対的な苦痛です。サポートする可能性があれば、万が一に備えてユニコードを使用する価値があると思います。

ANSIには多くのものがありますが、ほとんどの場合、この点で8ビット文字セットです（Windowsのコードページ1252など）。

おそらく、7ビットでUTF-8の適切なサブセットであるASCIIを考えていたのでしょう。つまり、有効なASCIIストリームも有効なUTF-8ストリームです。

8ビットの文字セットを考えている場合、1つの非常に重要な利点は、すべての表現可能な文字が正確に8ビットであるということです。UTF-8では最大24ビットです。

はい、ASCIIが理にかなっているいくつかのユースケースがまだあります：ファイル形式とネットワークプロトコル。特に、次の用途で：

• コンピュータープログラムによって生成および消費されるデータがあり、エンドユーザーに提示されることはありません。
• しかし、開発とデバッグを容易にするために、プログラマーが読むことができると便利です。

エンコードとしてASCIIを使用することで、少なくともある程度の人間可読性を維持しながら、マルチバイトエンコードの複雑さを回避できます。

いくつかの例：

• HTTPは、オクテットのシーケンスで定義されたネットワークプロトコルですが、「少なくとも」英語のプログラマーにとっては、「GET」、「POST」、「Accept-Language」などの単語のASCIIエンコーディングに対応していることが非常に便利ですなど。
• PNG画像形式のチャンクタイプは4オクテットで構成されますが、IDAT「画像データ」とPLTE「パレット」を意味するPNGエンコーダーまたはデコーダーをプログラミングする場合に便利です。

もちろん、データが実際にエンドユーザーに表示されないように注意する必要があります。なぜなら、データが表示されるようになった場合（URLの場合）、ユーザーはそのデータが正しく表示されることを当然期待するからです。彼らが読むことができる言語で。

まず第一に：あなたのタイトルは/ d ANSIを使用していますが、テキストではASCIIを参照しています。ANSIはASCIIと等しくないことに注意してください。ANSIにはASCIIセットが組み込まれています。ただし、ASCIIセットは最初の128個の数値（0-127）に制限されています。

すべてのデータがASCII（7ビット）に制限されている場合、ANSIとUTF-8の両方が完全なASCIIセットを組み込むため、UTF-8、ANSI、またはASCIIのいずれを使用してもかまいません。つまり、0から127までの数値は、ASCII、ANSI、UTF-8のまったく同じ文字を表します。

ASCIIセット以外の文字が必要な場合は、エンコードを選択する必要があります。ANSIを使用することもできますが、すべての異なるコードページの問題に遭遇します。マシンAでファイルを作成し、マシンBで読むと、数値nnnがこれらのコードページの異なる文字を表すため、これらのマシンが異なるコードページを使用するように設定されている場合、おかしなテキストが生成される場合があります。

この「コードページの地獄」が、Unicode標準が定義された理由です。UTF-8はその標準の単一のエンコーディングにすぎませんが、さらに多くのエンコーディングがあります。UTF-16は、Windowsのネイティブエンコーディングであるため、最も広く使用されています。

したがって、ASCIIセットの128文字を超えるものをサポートする必要がある場合、UTF-8を使用することをお勧めします。この方法は重要ではなく、ユーザーがシステムをセットアップするコードページを心配する必要はありません。