テキスト エンコーディング ASCII (Windows 1251、CP866、KOI8-R) および Unicode (UTF 8、16、32) - クラッカーの問題を解決する方法

今日は、krakozyabrs が Web サイトやプログラムのどこから来たのか、どのようなテキスト エンコーディングが存在し、どれを使用する必要があるのか​​について説明します。基本的な ASCII から始まり、その拡張バージョンである CP866、KOI8-R、Windows 1251 に至るまで、最新の Unicode コンソーシアム エンコーディングである UTF 16 および 8 に至るまで、その開発の歴史を詳しく見てみましょう 。 目次:

• ASCII - ラテンアルファベットの基本的なテキストエンコーディング
• アスカの拡張バージョン - CP866 および KOI8-R エンコーディング
• Windows 1251 - ASCII のバリエーションと krakozyabry が登場する理由
• Unicode - ユニバーサル エンコーディング UTF 8、16、および 32
• ロシア語の文字の代わりにおかしな単語 - それを修正する方法

一部の人にとって、この情報は不必要に思えるかもしれませんが、特にクロール・クラコズヤブル（読めない文字のセット）に関して私がどれだけの質問を受けているかご存知でしょうか。これから、この記事の本文を皆さんに参照してもらい、自分自身の間違いを見つける機会が与えられます。さて、情報を吸収する準備をして、ストーリーの流れに従うようにしてください。

ASCII - ラテンアルファベットの基本的なテキストエンコーディング

テキスト エンコーディングの開発は IT 産業の形成と同時に発生し、この間にかなり多くの変化を経験しました。歴史的には、すべては EBCDIC から始まりました。EBCDIC はロシア語の発音ではやや不協和音であり、制御文字を使用してラテン語のアルファベット、アラビア数字、句読点の文字をエンコードできるようになりました。しかしそれでも、現代のテキスト エンコーディングの開発の出発点は、有名なASCII (American Standard Code for Information Interchange、ロシア語では通常「アスク」と発音されます) であると考えるべきです。英語圏のユーザーが最も一般的に使用する最初の 128 文字 (ラテン文字、アラビア数字、句読点) について説明します。ASCII で記述されたこれら 128 文字には、括弧、ハッシュ マーク、アスタリスクなどのサービス文字も含まれています。実際、これらを自分で見ることができます。 標準となったのは、ASCII のオリジナル バージョンのこれら 128 文字であり、他のエンコーディングでもこれらの文字は必ず見つかり、この順序で表示されます。しかし、実際には、1 バイトの情報を使用すると、128 ではなく、256 もの異なる値 (2 の 8 乗は 256) をエンコードできるため、Asuka の基本バージョンの後、全体がエンコードされます。一連の拡張 ASCII エンコーディングが登場し、128 の基本文字に加えて各国のエンコーディング文字 (ロシア語など) を使用してエンコードすることも可能になりました。ここで、説明で使用されている数値体系についてもう少し説明する価値があるでしょう。まず、皆さんご存知のとおり、コンピューターは 2 進数の数値、つまり 0 と 1 (学校や学校で習った人なら「ブール代数」) でのみ動作します。1 バイトは 8 ビットで構成され、それぞれが 0 から始まり 2 から 7 までの 2 の 2 乗を表します。 このような構成では、0 と 1 のすべての可能な組み合わせが可能であることを理解するのは難しくありません。数値を 2 進数から 10 進数に変換するのは非常に簡単です。2 の累乗とその上の 1 をすべて加算するだけです。この例では、これは、1 (2 のゼロ乗) プラス 8 (2 の 3 乗)、プラス 32 (2 の 5 乗)、プラス 64 (6 乗)、プラス 128 となります。 (7乗)。合計は10進数で233になります。ご覧のとおり、すべては非常にシンプルです。しかし、ASCII 文字を含む表をよく見ると、それらが 16 進エンコードで表されていることがわかります。たとえば、「アスタリスク」は、Aski の 16 進数の 2A に対応します。16 進数体系では、アラビア数字に加えて、A (10 を意味する) から F (15 を意味する) までのラテン文字も使用されていることはおそらくご存知でしょう。さて、2進数を16進数に変換するには次の簡単な方法に頼ってください。情報の各バイトは 4 ビットの 2 つの部分に分割されます。それらの。各ハーフバイトでは、16 個の値 (2 の 4 乗) のみをバイナリでエンコードでき、これは 16 進数として簡単に表現できます。さらに、バイトの左半分では、スクリーンショットに示されているものではなく、度をゼロから再度カウントする必要があります。その結果、スクリーンショットには数値 E9 がエンコードされていることがわかります。私の推論の流れとこのパズルの解決策が理解できたことを願っています。さて、実際にテキスト エンコーディングについて話を続けましょう。

アスカの拡張バージョン - 擬似グラフィックを使用した CP866 および KOI8-R エンコーディング

そこで、私たちは ASCII について話し始めました。ASCII はいわば、すべての最新のエンコーディング (Windows 1251、Unicode、UTF 8) 開発の出発点でした。当初は、ラテン文字、アラビア数字などの 128 文字のみが含まれていましたが、拡張バージョンでは、1 バイトの情報でエンコードできる 256 個の値すべてを使用できるようになりました。それらの。Askiにあなたの言語の文字の記号を追加できるようになりました。ここで、もう一度脱線して、なぜテキストエンコーディングが必要なのか、そしてなぜそれがそれほど重要なのかを説明する必要があります。コンピュータ画面上の文字は、さまざまな文字のベクトル形状 (表現) のセット (コンピュータにインストールされているフォントを含むファイル内にあります) と、その文字を正確に引き出すことができるコードの 2 つの要素に基づいて形成されます。この一連のベクトル形状 (フォント ファイル) から、正しい場所に挿入する必要があるシンボル。フォント自体がベクトル形状を担当することは明らかですが、オペレーティング システムとその中で使用されるプログラムがエンコーディングを担当します。それらの。コンピュータ上のテキストはすべてバイトの集合となり、各バイトがこのテキストの 1 文字をエンコードします。このテキストを画面上に表示するプログラム (テキスト エディタ、ブラウザなど) は、コードを解析するときに、次の文字のエンコーディングを読み取り、これを表示するために接続されている必要なフォント ファイル内で対応するベクトル形式を探します。テキストドキュメント。すべてがシンプルで平凡です。これは、必要な文字 (各国語アルファベットなど) をエンコードするには、2 つの条件を満たす必要があることを意味します。1 つは、この文字のベクトル形式が使用されているフォント内にある必要があり、この文字は拡張 ASCII エンコードでエンコードできることです。 1バイトで。したがって、そのようなオプションがたくさんあります。ロシア語の文字をエンコードするためだけでも、いくつかの種類の拡張 Aska があります。たとえば、最初に登場したCP866 は、ロシア語のアルファベットの文字を使用する機能を備えており、ASCII の拡張バージョンでした。つまり、上のスクリーンショットに示されているように、その上部は Aska の基本バージョン (128 のラテン文字、数字、その他のくだらないもの) と完全に一致していますが、CP866 エンコーディングを使用したテーブルの下部は、次のような外観になっています。すぐ下のスクリーンショットでは、さらに 128 文字 (ロシア語の文字とあらゆる種類の疑似グラフィック) をエンコードできます。 ご覧のとおり、右側の列の数字は 8 で始まります。0 から 7 までの数字は ASCII の基本部分を指します (最初のスクリーンショットを参照)。したがって、CP866 のキリル文字「M」はコード 9C になります (16 進数体系では、対応する行の 9 と数字 C の列の交点に位置します)。これは 1 バイトの情報で書き込むことができます。 、ロシア語の文字を含む適切なフォントがある場合、この文字は問題なくテキストに表示されます。この金額はどこから来たのでしょうか?CP866 の擬似グラフィックス? 重要なのは、このロシア語テキストのエンコーディングは、グラフィカル オペレーティング システムが現在のように普及していなかったあのみすぼらしい時代に開発されたということです。そして、Dosa や同様のテキスト オペレーティング システムでは、疑似グラフィックによって、少なくとも何らかの形でテキストのデザインを多様化することが可能になったので、CP866 や、Asuka の拡張バージョンのカテゴリに属する​​他のすべての同等製品が豊富に含まれています。CP866 は IBM によって配布されましたが、これに加えて、ロシア語の文字用に多数のエンコーディングが開発されました。たとえば、KOI8-R は同じタイプ (拡張 ASCII) に属すると考えられます。 その動作原理は CP866 と同じです。先ほど説明した CP866 の場合 - テキストの各文字は 1 バイトとしてエンコードされます。スクリーンショットは KOI8-R テーブルの後半を示しています。前半は、この記事の最初のスクリーンショットに示されている基本的なアスカと完全に一致しています。KOI8-R エンコーディングの特徴の中で、そのテーブル内のキリル文字が CP866 で行われていたようにアルファベット順ではないことに注意することができます。一番最初のスクリーンショット (すべての拡張エンコーディングに含まれる基本部分) を見ると、KOI8-R ではロシア語の文字がテーブルの対応するラテン文字の文字と同じセルに配置されていることがわかります。表の最初の部分から。これは、1 ビット (2 の 7 乗、つまり 128) だけを破棄して、ロシア語文字からラテン文字に切り替える便宜のために行われました。

Windows 1251 - ASCII の最新バージョンとクラックが発生する理由

テキスト エンコーディングがさらに発展したのは、グラフィカル オペレーティング システムの人気が高まり、その中で擬似グラフィックを使用する必要性が時間の経過とともになくなったためです。その結果、本質的には依然としてアスカの拡張バージョン (テキストの 1 文字が 1 バイトの情報のみでエンコードされている) であるが、疑似記号は使用されていないグループ全体が誕生しました。これらは、米国規格協会によって開発された、いわゆる ANSI エンコーディングに属していました。一般的な用語では、キリル文字という名前はロシア語をサポートするバージョンにも使用されました。この例としては、Windows 1251が挙げられます。これは、以前に使用されていたCP866およびKOI8-Rとは、その中の疑似記号の代わりに、ロシア語の活版印刷の欠落記号（アクセント記号を除く）と、ロシア語に近いスラブ言語で使用される記号が使用されたという点で有利に異なりました。ロシア語 (ウクライナ語、ベラルーシ語など): ロシア語のエンコーディングが非常に豊富なため、フォント メーカーやソフトウェア メーカーは常に頭痛の種を抱えており、親愛なる読者の皆さんも私も、同じ悪名高いバグでしばしばトラブルに見舞われました。本文中で使用されているバージョンに混乱があった場合。電子メールでメッセージを送受信するときにこの問題が頻繁に発生し、非常に複雑な変換テーブルの作成が必要でしたが、実際にはこの問題を根本的に解決することはできず、多くの場合、ユーザーは通信にラテン文字の音訳を使用していました。 CP866、KOI8-R、または Windows 1251 などのロシア語エンコードを使用する場合、悪名高い意味不明な表現を避けてください。実際、ロシア語のテキストの代わりに現れる亀裂は、特定の言語のエンコードが誤って使用された結果であり、その言語のエンコードは、言語のエンコードに対応していませんでした。テキスト メッセージが最初にエンコードされたもの。Windows 1251 コード テーブルを使用して CP866 でエンコードされた文字を表示しようとすると、同じ意味不明の文字 (意味のない文字のセット) が表示され、メッセージのテキストが完全に置き換えられてしまうとします。 同様の状況は、Web サイト、フォーラム、ブログを作成および設定するときによく発生します。ロシア語の文字を含むテキストが、サイトでデフォルトで使用されている間違ったエンコーディングで誤って保存されたり、目に見えないギャグが追加される間違ったテキスト エディターで保存されたりする場合です。肉眼でコードを確認できます。結局、多くの人々が、大量のエンコーディングと絶え間なく忍び寄るがらくたを伴うこの状況にうんざりし、既存のものをすべて置き換えて、読めないテキストの出現に関する問題を解決する、新しい普遍的なバリエーションを作成するための前提条件が現れました。 。さらに、中国語などの言語では、言語文字の数が 256 よりもはるかに多いという問題がありました。

Unicode - ユニバーサル エンコーディング UTF 8、16、および 32

東南アジア言語グループのこれらの数千の文字は、ASCII の拡張バージョンで文字をエンコードするために割り当てられた 1 バイトの情報ではおそらく記述できません。その結果、ユニバーサル テキストエンコーディングの出現に関心を持つ多くの IT 業界のリーダー (ソフトウェアを作成する者、ハードウェアをエンコードする者、フォントを作成する者) の協力を得て、Unicode (Unicode コンソーシアム) と呼ばれるコンソーシアムが設立されました。Unicode Consortium の後援の下でリリースされた最初のバリエーションはUTF 32でした。エンコーディング名の数字は、1 つの文字をエンコードするために使用されるビット数を意味します。32 ビットは、新しいユニバーサル UTF エンコーディングで 1 文字をエンコードするのに必要な 4 バイトの情報に相当します。その結果、ASCII の拡張バージョンと UTF-32 (後者の場合) でエンコードされたテキストを含む同じファイルのサイズ (重さ) は 4 倍になります。これは良くありませんが、UTF を使用して 2 の 32 乗に等しい数の文字 (本当に必要な値を膨大なマージンでカバーできる数十億の文字) をエンコードできるようになりました。しかし、ヨーロッパグループの言語を持つ多くの国では、エンコードにそれほど膨大な数の文字を使用する必要はまったくありませんでしたが、UTF-32 を使用すると、理由もなくテキストドキュメントの重量が 4 倍に増加しました。その結果、インターネット トラフィックの量と保存されるデータの量が増加します。これは多額であり、誰もそのような無駄を買う余裕はありません。Unicode の開発の結果、UTF-16が登場しました。これは非常に成功し、使用するすべての文字の基本スペースとしてデフォルトで採用されました。1 文字をエンコードするのに 2 バイトを使用します。これがどのように見えるかを見てみましょう。Windows オペレーティング システムでは、「スタート」-「プログラム」-「アクセサリ」-「システム ツール」-「文字テーブル」のパスをたどることができます。その結果、システムにインストールされているすべてのフォントのベクトル形状を含むテーブルが開きます。「詳細オプション」で Unicode 文字セットを選択すると、フォントごとに、そのフォントに含まれる文字の全範囲を個別に表示できます。ちなみに、それらのいずれかをクリックすると、4 つの 16 進数で構成される UTF-16 形式の 2 バイト コードが表示されます。16 ビットを使用して UTF-16 でエンコードできる文字は何文字までですか? 65,536 (2 の 16 乗)、これは Unicode の基本スペースとして採用された数値です。さらに、これを使用して約 200 万文字をエンコードする方法もありますが、それらは 100 万文字のテキストの拡張スペースに制限されていました。しかし、この成功した Unicode エンコード バージョンでも、たとえば英語だけでプログラムを作成する人にはあまり満足できませんでした。拡張バージョンの ASCII から UTF-16 に移行した後、ドキュメントの重みが 2 倍になったためです (1 バイトあたり 1 バイト)。 Aski では 1 文字、YUTF-16 では同じ文字の 2 バイト）。Unicode コンソーシアムの全員とすべてを満足させるために、可変長エンコーディングを考案することが決定されました。それはUTF-8と呼ばれていました。名前に 8 が含まれているにもかかわらず、実際には可変長です。テキストの各文字は、長さ 1 ～ 6 バイトのシーケンスにエンコードできます。実際には、UTF-8 は 1 ～ 4 バイトの範囲のみを使用します。コードが 4 バイトを超えると、理論的には何も想像できなくなるからです。古き良き ASCII と同様に、その中のすべてのラテン文字は 1 バイトにエンコードされます。注目すべき点は、ラテン文字のみをエンコードする場合、Unicode を理解できないプログラムでも YTF-8 でエンコードされたものを読み取ることができるということです。つまり、Asuka の基本的な部分が Unicode コンソーシアムの考案者に移されただけです。UTF-8 のキリル文字は 2 バイトでエンコードされ、たとえばグルジア語文字は 3 バイトでエンコードされます。Unicode コンソーシアムは、UTF 16 と 8 を作成した後、主要な問題を解決しました。現在、フォント内に単一のコード スペースが存在します。そして現在、メーカーは自社の強みと機能に基づいて、ベクトル形式のテキスト文字を入力することしかできません。上記の「文字テーブル」では、フォントごとにサポートされる文字数が異なることがわかります。Unicode を多用したフォントの中には、非常に重いものもあります。しかし、これらの違いは、異なるエンコーディング用に作成されたという事実ではなく、フォントの製造元が単一のコード空間を特定のベクトル形式で埋めたかどうかという点にあります。

ロシア語の文字の代わりにおかしな単語 - それを修正する方法

ここで、テキストの代わりに krakozyabrs がどのように表示されるか、つまり、ロシア語テキストの正しいエンコーディングがどのように選択されるかを見てみましょう。実際には、このテキストそのもの、またはテキストの断片を使用するコードを作成または編集するプログラム内で設定されます。テキスト ファイルを編集および作成するには、個人的には、非常に優れたHtml および PHP エディターである Notepad++を使用します。ただし、他の何百ものプログラミング言語やマークアップ言語の構文を強調表示でき、プラグインを使用して拡張する機能もあります。提供されたリンクで、この素晴らしいプログラムの詳細なレビューをお読みください。Notepad++ のトップメニューには「エンコーディング」という項目があり、既存のオプションをサイトでデフォルトで使用されているオプションに変換することができます。 Joomla 1.5 以降のサイトの場合、次のようになります。 WordPress 上のブログの場合と同様に、Krakozyabrov がBOM なしの UTF 8 オプションを選択したように見えることは避けるべきです。BOM プレフィックスとは何ですか? 実際のところ、彼らは YUTF-16 エンコーディングを開発していたときに、何らかの理由で文字コードを順方向 (0A15 など) と逆方向 (150A) の両方で記述できる機能を付加することに決めました。 。そして、プログラムがどのような順序でコードを読み取ればよいのかを理解するために、文書の先頭にさらに 3 バイトを追加することで表現されるBOM (バイト オーダー マーク、言い換えれば署名) が発明されました。UTF-8 エンコーディングでは、Unicode コンソーシアムで BOM が提供されていなかったため、署名 (文書の先頭にある悪名高い余分な 3 バイト) を追加すると、一部のプログラムがコードを読み取れなくなるだけです。したがって、ファイルを UTF で保存する場合は、常に BOM なし (署名なし) オプションを選択する必要があります。したがって、krakozyabrsからの這い出しから事前に身を守ることができます。注目に値するのは、同じ悪名高い Windows メモ帳など、Windows の一部のプログラムではこれができないことです (BOM なしではテキストを UTF-8 で保存できません)。文書は UTF-8 で保存されますが、文書の先頭に署名 (3 バイト) が追加されます。さらに、これらのバイトは常に同じです。コードを直接順番に読んでください。しかし、サーバー上では、この小さなことが原因で問題が発生する可能性があります。犯罪者が出てくるのです。したがって、いかなる状況でも通常の Windows メモ帳は使用しないでください。亀裂を生じさせたくない場合は、サイト上のドキュメントを編集します。私は、すでに述べた Notepad++ エディターが最良かつ最もシンプルなオプションであると考えています。これには実質的に欠点はなく、利点だけで構成されています。Notepad++ では、エンコードを選択するときに、テキストを Unicode 標準に非常に近い性質の UCS-2 エンコードに変換するオプションがあります。また、メモ帳ではテキストを ANSI でエンコードできるようになります。ロシア語に関して言えば、これは Windows 1251 であり、すでに上で説明しましたが、この情報はどこから来たのでしょうか? これは Windows オペレーティング システムのレジストリに登録されます。ANSI の場合はどのエンコーディングを選択するか、OEM の場合はどのエンコーディングを選択するか (ロシア語の場合は CP866 になります)。コンピュータに別のデフォルト言語を設定すると、これらのエンコーディングは、同じ言語の ANSI または OEM カテゴリの類似したエンコーディングに置き換えられます。必要なエンコーディングで文書を Notepad++ に保存するか、編集のためにサイトから文書を開いた後、エディターの右下隅にその名前が表示されます。 混乱を避けるため、上記の手順に加え て、 、サーバーまたはローカル ホストで混乱が生じないように、サイトのすべてのページにこのエンコーディングに関する情報のヘッダーにソース コードを記述すると便利です。一般に、Html を除くすべてのハイパーテキスト マークアップ言語は、テキスト エンコーディングを指定する特別な XML 宣言を使用します。

<?xml version="1.0" encoding="windows-1251"?>

コードを解析する前に、ブラウザは、使用されているバージョンと、その言語の文字コードをどのように正確に解釈する必要があるかを認識します。ただし、注目すべき点は、ドキュメントをデフォルトの Unicode で保存する場合、この XML 宣言を省略できることです (エンコーディングは、BOM がない場合は UTF-8、BOM がある場合は UTF-16 とみなされます)。HTML ドキュメントの場合、Meta 要素は、 Head タグの開始タグと終了タグの間に配置され、エンコーディングを示すために使用されます。

<head>
...
<meta charset="utf-8">
...
</head>

このエントリは Html 4.01 の標準とはまったく異なりますが、Html 5 標準に完全に準拠しており、現在使用されているブラウザで正しく理解されます。理論的には、HTML ドキュメントのエンコーディングを示す Meta 要素は、ドキュメント ヘッダーのできるだけ高い位置に配置することをお勧めします。そうすることで、テキストが基本的な ANSI 以外の最初の文字に遭遇するまでに (文字は常に正しく読み取られます)あらゆるバリエーション)、ブラウザーはこれらの文字のコードをどのように解釈するかについての情報をすでに持っているはずです。 元のソースへのリンク: ASCII テキスト エンコーディング (Windows 1251、CP866、KOI8-R) および Unicode (UTF 8、16、32) - クラッカーの問題を解決する方法