UnicodeとASCIIの正確な違いは何ですか？
ASCIIは合計128文字です（拡張セットでは256文字）。
Unicode文字のサイズ指定はありますか？
回答:
ASCIIは128文字を定義し、0〜127の数字にマップされます。ユニコード定義2つの（以下）21、同様に、番号0~2にマップ文字、21（ただし、すべての数が現在割り当てられていない、といくつかは予約されています）。
UnicodeはASCIIのスーパーセットであり、0〜127の数字は、ASCIIでもUnicodeと同じ意味です。たとえば、数値65は「ラテン大文字 'A'」を意味します。
Unicode文字は一般に1つの8ビットバイトに収まらないため、UTF-32やUTF-8など、Unicode文字をバイトシーケンスに格納する方法は多数あります。
理解なぜ ASCIIおよびUnicodeが最初の場所で作成されたが、私は両者の違いを理解して助けました。
ASCII、起源
他の回答で述べたように、ASCIIは7ビットを使用して文字を表します。7ビットを使用することで、最大2 ^ 7（= 128）の異なる組み合わせ*を持つことができます。つまり、最大128文字を表すことができます。
待って、7ビット？しかし、なぜ1バイト（8ビット）ではないのでしょうか。
ほとんどのASCII文字は、abc、ABC、123、？＆！などのアルファベットの印刷可能な文字です。その他の文字は、キャリッジリターン、ラインフィード、タブなどの制御文字です。
以下のASCIIのいくつかの文字のバイナリ表現を参照してください。
0100101 -> % (Percent Sign - 37)
1000001 -> A (Capital letter A - 65)
1000010 -> B (Capital letter B - 66)
1000011 -> C (Capital letter C - 67)
0001101 -> Carriage Return (13)
ASCIIは英語のみを意味していました。
何？なぜ英語だけなのか？非常に多くの言語があります！
コンピュータ業界の中心は当時アメリカにあったからです。結果として、アクセントや、á、ü、ç、ñなどの他のマーク（別名発音区別符号）をサポートする必要はありませんでした。
ASCII拡張
一部の賢い人々は、8番目のビット（パリティーに使用されるビット）を使用して、言語をサポートするために（たとえば、フランス語の「é」をサポートするために）より多くの文字をエンコードし始めました。1つの余分なビットを使用するだけで、元のASCIIテーブルのサイズが2倍になり、最大256文字（2 ^ 8 = 256文字）にマップされます。以前のように2 ^ 7ではありません（128）。
10000010 -> é (e with acute accent - 130)
10100000 -> á (a with acute accent - 160)
この「ASCIIは以前のように7ビットではなく8ビットに拡張されました」の名前は、単に「拡張ASCII」または「8ビットASCII」と呼ばれる場合があります。
以下のよう@Tomは以下の彼のコメントで指摘があっ「などというものではありません拡張ASCIIは」まだこれは、この8ビットのトリックを参照するための簡単な方法です。8ビットASCIIテーブルには多くのバリエーションがあります。たとえば、ISO 8859-1、ISO Latin-1とも呼ばれます。
Unicode、The Rise
拡張されたASCIIは、ラテンアルファベットに基づく言語の問題を解決します...完全に異なるアルファベットを必要とする他の言語についてはどうですか？ギリシャ語？ロシア？中国語など？
まったく新しい文字セットが必要だったでしょう...それがUnicodeの背後にある合理的です。Unicodeにはすべての言語のすべての文字が含まれているわけではありませんが、膨大な数の文字が含まれていることは確かです（この表を参照）。
テキストを「Unicode」としてハードドライブに保存することはできません。Unicodeはテキストの抽象的な表現です。この抽象表現を「エンコード」する必要があります。ここでエンコーディングが機能します。
エンコーディング：UTF-8 vs UTF-16 vs UTF-32
この答えは基本を説明するのにかなり良い仕事をします：
UTF-8は、最初の128文字にASCIIセットを使用します。これは、ASCIIテキストがUTF-8でも有効であることを意味するので便利です。
ニーモニック：
注意：
なぜ2 ^ 7なのか？
これは一部の人にとっては明白ですが、念のためです。7つのスロットがあり、0または1（バイナリコード）で埋められています。それぞれに2つの組み合わせがあります。7つのスポットがある場合、2 * 2 * 2 * 2 * 2 * 2 * 2 = 2 ^ 7 = 128の組み合わせになります。これは、7つのホイールが付いたコンビネーションロックであり、各ホイールには2つの番号しかない。
出典：ウィキペディア、この素晴らしいブログ投稿、および私が最初にこの概要を投稿したMocki。
ASCIIには、0から127までの128のコードポイントがあります。これは、単一の8ビットバイトに収まり、128から255の値は、他の文字に使用される傾向があります。互換性のない選択により、コードページに障害が発生します。あるコードページでエンコードされたテキストは、別のコードページを想定または推測するプログラムでは正しく読み取ることができません。
この災害を解決するために、Unicodeが登場しました。バージョン1は65536のコードポイントから始まり、通常は16ビットでエンコードされています。後にバージョン2で110万のコードポイントに拡張されました。現在のバージョンは6.3で、利用可能な110万のコードポイントのうち110,187を使用しています。それはもはや16ビットには適合しません。
16ビットでのエンコードは、v2が登場したときに一般的であり、MicrosoftやAppleオペレーティングシステムなどで使用されていました。そしてJavaのような言語ランタイム。v2仕様では、これらの110万のコードポイントを16ビットにマッピングする方法が考案されました。UTF-16と呼ばれるエンコーディング。1つのコードポイントに2バイトまたは4バイトを使用できる可変長エンコーディング。元のv1コードポイントには2バイト、追加されたものには4バイトかかります。
* nixオペレーティングシステムとツールで使用される非常に一般的なもう1つの可変長エンコーディングはUTF-8です。コードポイントは1〜4バイトで、元のASCIIコードは1バイト、残りはさらに多くかかります。非可変長のエンコーディングはUTF-32のみで、コードポイントには4バイトが必要です。無駄が多いのであまり使われません。UTF-1やUTF-7など、広く無視されているものもあります。
UTF-16 / 32エンコーディングの問題は、バイトの順序がテキストストリームを作成したマシンのエンディアンに依存することです。そのため、UTF-16BE、UTF-16LE、UTF-32BE、UTF-32LEを組み合わせて追加します。
これらの異なるエンコーディングの選択があると、コードページの惨事がある程度もたらされ、UTFの選択が「最適」であるというプログラマ間の激しい議論が起こります。オペレーティングシステムのデフォルトとの関連付けは、かなり線引きしています。1つの対抗策は、BOMの定義、バイトオーダーマーク、テキストストリームの先頭にある特別なコードポイント（U + FEFF、ゼロ幅スペース）であり、残りのストリームのエンコード方法を示します。これは、UTFエンコーディングとエンディアンの両方を示し、テキストレンダリングエンジンに対して中立です。残念ながらそれはオプションであり、多くのプログラマーはそれを省略する権利を主張しているため、事故は依然としてかなり一般的です。
javaはUnicodeのサポートを提供します。つまり、すべてのワールドワイドアルファベットをサポートします。したがって、Javaのcharのサイズは2バイトです。範囲は0〜65535です。
ASCIIには128個のコード位置があり、グラフィック文字と制御文字（制御コード）に割り当てられています。
Unicodeのコード位置は1,114,112です。現在、約100,000個が文字に割り当てられており、多くのコードポイントは永続的に非文字（つまり、文字のエンコードに使用されていない）になっており、ほとんどのコードポイントはまだ割り当てられていません。
ASCIIとUnicode に共通する唯一のものは次のとおりです。1）それらは文字コードです。2）Unicodeの最初の128個のコード位置は、ASCIIと同じ意味を持つように定義されています。ただし、ASCII制御文字のコード位置は、ASCII名に対応する名前を持つ制御文字を示すものとして定義されているだけですが、その意味はUnicodeでは定義されていません。
ただし、Unicodeは（Unicode標準でも）、「ワイドASCII」として特徴付けられる場合があります。これは主に、UnicodeがASCIIと同じようにユニバーサル文字コードになることを意図しているという考えを主に伝えようとするスローガンです（ただし、ASCIIの文字レパートリーはユニバーサルな使用にはどうしても不十分でした）。さまざまなシステムとアプリケーション、さまざまな言語。
Unicode自体は、文字の「論理サイズ」のみを定義します。各文字には、特定の範囲のコード番号があります。これらのコード番号は、さまざまな転送エンコーディングを使用して表すことができ、内部的には、メモリ内で、Unicode文字は通常、文字範囲に応じて、1文字あたり1つまたは2つの16ビット数量を使用して表されます。
ASCIIとUnicodeは2つの文字エンコーディングです。基本的に、これらはデジタルメディアで書き込み、保存、送信、読み取りできるように、差分文字をバイナリで表す方法の標準です。2つの主な違いは、文字をエンコードする方法と、それぞれに使用するビット数です。ASCIIは当初、各文字のエンコードに7ビットを使用していました。これは後に拡張ASCIIで8に増加し、オリジナルの明らかな不十分さに対処しました。対照的に、Unicodeは可変ビットエンコーディングプログラムを使用しており、32、16、および8ビットエンコーディングから選択できます。より多くのビットを使用すると、より大きなファイルを犠牲にしてより多くの文字を使用できますが、より少ないビットは限られた選択肢を提供しますが、多くのスペースを節約します。より少ないビットを使用する（つまり、
Unicodeが問題であった主な理由の1つは、多くの非標準の拡張ASCIIプログラムから生じました。マイクロソフトや他のほとんどのソフトウェア会社で使用されている一般的なページを使用しているのでない限り、ボックスとして表示される文字で問題が発生する可能性があります。Unicodeは、すべての文字コードポイントが標準化されているため、この問題を事実上解消します。
Unicodeのもう1つの大きな利点は、最大で膨大な数の文字に対応できることです。このため、Unicodeには現在ほとんどの記述言語が含まれており、さらに多くの余地があります。これには、英語のような典型的な左から右のスクリプト、さらにはアラビア語のような右から左のスクリプトも含まれます。中国語、日本語、およびその他の多くのバリアントもUnicodeで表現されます。したがって、Unicodeがすぐに置き換えられることはありません。
当時広く使用されていた古いASCIIとの互換性を維持するために、Unicodeは最初の8ビットが最も一般的なASCIIページのビットと一致するように設計されました。したがって、ASCIIエンコードされたファイルをUnicodeで開いても、ファイルにエンコードされた正しい文字が得られます。これにより、すでにASCIIを使用していたユーザーに新しいエンコード標準を採用することによる影響が軽減されたため、Unicodeの採用が容易になりました。
概要：
1.ASCII uses an 8-bit encoding while Unicode uses a variable bit encoding.
2.Unicode is standardized while ASCII isn’t.
3.Unicode represents most written languages in the world while ASCII does not.
4.ASCII has its equivalent within Unicode.
引用元：http : //www.differencebetween.net/technology/software-technology/difference-between-unicode-and-ascii/#ixzz4zEjnxPhs
与えられた数字は1文字を格納するためのものです
Unicodeには120,000文字を超えるレパートリーがあるため、ASCIIは128文字を定義します。
UTFがどのようにASCIIのスーパーセットであるかを超えて、ASCIIとUTFの間で知っておくべきもう1つの良い違いは、ディスクファイルのエンコーディングとデータ表現およびランダムメモリへの格納の点です。プログラムは、データの先頭で特別なバイトオーダーマークコードを検出するか、またはプログラマーからデータがテキストであると想定し、そのことを示すパターンをチェックすることにより、特定のデータをASCIIまたはUTF文字列として理解する必要があることを認識しています。あるテキストエンコーディングまたは別のテキストエンコーディングで。
0x16進データの従来の接頭表記を使用すると、基本的に適切な参照は、ASCIIテキストがバイト値で始まり、考えられるASCII文字値の 1つ0x00を0x7F表すことです。UTFテキストは通常0xEF 0xBB 0xBF、UTF8 のバイトで始まることで示されます。UTF16の場合、開始バイト0xFE 0xFF、または0xFF 0xFEが使用され、テキストバイトのエンディアン順は開始バイトの順序で示されます。可能なバイト値のASCII範囲にないバイト値の単純な存在は、データがおそらくUTFであることも示しています。
異なるコードを使用してデータを特定のエンコード標準でエンコードされたテキストとして解釈する必要があることを示す他のバイトオーダーマークがあります。