まず、いくつかの用語を説明する価値があります。 コードページ-事前に既知のサイズのテーブル。各位置（またはコード）は単一の文字またはその不在に関連付けられています。 たとえば、文字「G」が71番目の位置に対応する次元256のコードページ。 エンコーディング-文字を数値表現でエンコードするためのルール。 特定のコードページのエンコードが作成されます。 たとえば、
Abrwalエンコーディングの「G」文字は値71を取ります。ところで、最も単純なエンコーディングはそうします。コードテーブルの値で文字を表し、
ASCIIもこれらに適用されます。
以前は、エンコードには文字あたり7ビットで十分でした。 そして何？ 128の異なる文字に十分な、その時間のユーザーに必要なすべてが見つかりました：英語のアルファベット、句読点、数字、いくつかの特殊文字。 対応するコードページを備えた主要な英語の7ビットエンコードは
ASCII（情報交換用のアメリカ標準コード）と呼ばれ、将来の基盤も築きました。 後に、コンピューターが英語圏以外の国に広まると、各国語が必要になりました。ここでは
ASCII財団が役に立ちました。 コンピューターはバイトレベルで情報を処理し、
ASCIIコードは最初の7ビットのみを取ります。 8番目を使用すると、互換性を失わずにスペースが256箇所に拡張され、英語のサポートが重要になりました。 この事実に基づいて、英語以外のコードページとエンコードの大部分が構築されています。下位128の位置は
ASCIIの場合と同じで、上位128は国内のニーズのために予約され、最上位ビットでエンコードされます。 ただし、独自のページおよびエンコードの各言語（同様の言語のグループ）の作成により、オペレーティングシステムおよびソフトウェア全般の開発者によるこのような経済のサポートに問題が生じました。
この状況を克服するために、Unicode標準を開発および提案するコンソーシアムが組織されました。 世界のすべての言語の兆候を1つの大きなテーブルにまとめることが想定されていました。 さらに、エンコーディングが決定されました。 最初に、全員が65,535シートで十分であると判断し、16ビットの固定コード長のエンコーディングである
UCS-2を導入しました。 しかし、アジア人はマルチボリュームABCを使用しており、計算は崩れました。 コード領域が2倍になり、
UCS-2が対応できなくなり、32ビット
UCS-4が登場しました 。
UCSエンコードの具体的な利点は、2つのコード長の定数倍と単純なエンコードアルゴリズムであり、どちらもTexコンピューターの処理速度に貢献しました。 しかし、同時に、不当で無駄なスペースの無駄がありました。ASCII00010101、
UCS-2 00000000 00010101、
UCS-4はすでに000000000000000000000000 00010101であると想像してください。やるべきことがありました。
Unicodeの開発は、受信コードの可変長を使用したエンコーディングに向いています。 現時点では
UCS-4と同じであるため、代表者は
UTF-8 、
UTF-16および
UTF-32で、後者は仮釈放されています。
UTF-8の各文字は
8〜32ビットで、
ASCIIとの互換性があり
ます。 UTF-16、16または32ビット、
UTF-32-32ビット（Unicodeスペースが2倍になった場合、32または64ビット）では、これら2つは
ASCIIとは
異なります。 占有バイト数は、Unicodeテーブルの文字位置によって異なります。 明らかに、最も実用的なエンコーディングは
UTF-8です。 ASCIIとの互換性、メモリへの小さな食い違い、かなり単純なエンコードルールにより、最も一般的で有望なUnicodeエンコードです。 さて、結論として、文字コードを
UTF-8に変換するための美しいスキーム：
