すべての開発者がテキストを操作するためのエンコーディングと文字セットについて知っておくべきこと、パート2

これは、すべてのプログラマーがエンコードおよび文字セットをテキストで処理するために絶対に肯定的に知る必要があるという記事の翻訳の第2部です 。第1部はこちらです。

私の文書はどのエンコーディングでも完全にナンセンスです！

ビットのシーケンスが（人の観点から）合理的に見えない場合、これはドキュメントが特定の瞬間に誤って変換された可能性が最も高い場合です。 たとえば、ÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔǵÇ≠ǻǢというテキストを使用し、何も考えずにUTF-8で保存します。 テキストエディターは、Mac Romanでエンコードされたテキストを正しく読み、今度は別のエンコードで保存する必要があることを提案しました。 最終的に、これらの文字はすべてUnicodeで有効です。 つまり、Unicodeには、É、Gなどの条項があります。 したがって、UTF-8で保存するだけです。

11000011 10001001 01000111 11000011 10001001 11000011 10101100 11000011 10001001 01010010 11000011 10000101 01011011 11000011 10001001 01100110 11000011 10001001 01000010 11000011 10001001 11000011 10101100 11000011 10001001 01001111 11000011 10000111 11000011 10010101 11000011 10101100 11000011 10010100 11000011 10000111 11000010 10110101 11000011 10000111 11100010 10001001 10100000 11000011 10000111 11000010 10111011 11000011 10000111 11000010 10100010

したがって、テキストÉGÉìÉRÅ[ÉfÉBÉìÉOÇÕìÔǵÇ≠ǻǢは、UTF-8のビットのシーケンスで表されます。 このビットシーケンスは、元のドキュメントにあったものとは完全に分離されています。 このシーケンスを開くエンコーディングに関係なく、ソーステキストが表示されることはありません。 彼は単に失われています。 元のShift-JISエンコーディングを知っていて、テキストをMac Romanと見なし、UTF-8で保存した場合は、復元できます。 しかし、そのような奇跡はまれです。



多くの場合、特定のエンコードでは特定のビットシーケンスが正しくありません。 ASCIIで元のドキュメントを開こうとすると、一部の文字が認識され、一部の文字が認識されないことがわかります。 使用するプログラムは、現在のエンコードに適合しないバイトを単に破棄するか、疑問符に置き換えることを決定できます。 または、Unicodeの特別な置換文字： （U + FFFD）。 不適切な文字を保存した後にドキュメントを保存すると、それらは永久に失われます。



エンコードを誤って推測し、それをもう1つに保存すると、ドキュメントが台無しになります。 あなたはそれを修正しようとすることができますが、これらの試みは通常成功に終わりません。 ビットシフトされた魔法は、通常、アイドルの魔法のままです。まるで死んだ湿布のようです。

そして、エンコーディングを変更する方法は？

これは本当に簡単です！ 特定のテキスト（ビットシーケンス）のエンコーディングを知り、それを復号化に適用する必要があります。 それが行われる必要があるすべてです。 ユーザーからテキストを受け取るプログラムを作成している場合、どのエンコードでそれを行うかを決定します。 テキストフィールドは、どのエンコードでデータを受け取るかを知っている必要があります。 ユーザーがプログラムにロードできるファイルのタイプについては、エンコードを定義する必要があります。 または、ユーザーに質問する方法が必要です。 情報は、ファイル形式またはユーザーが提供できます（ほとんどの人は、もちろん記事を読むまで知りません）。



あるエンコーディングから別のエンコーディングにテキストを転送する必要がある場合は、特別なツールを使用してください。 変換は、2つのコードページを比較し、エンコーディングAの文字152がエンコーディングBの文字4122と一致することを決定し、その後ビットを変更するという面倒な作業です。 車輪を再発明する必要はありません。すべての一般的なプログラミング言語には、テキストをエンコードからエンコードに変換するためのビットおよびコードページから抽象化されたツールがあります。



アプリケーションがGB18030のファイルを受け入れる必要があるが、内部的にはUTF-32で作業しているとします。 iconvツールは、iconv（ 'GB18030'、 'UTF-32'、$文字列）の1行で変換を実行できます。 ビット表現が変更されても、文字は変更されません。

文字GB18030エンコードUTF-32エンコード

縧10111111 01101100 00000000 00000000 01111110 00100111

以上です。 彼の人間の理解における文字列の内容は変更されていませんが、現在はUTF-32の正しい文字列です。 UTF-32で引き続き作業する場合、読めない文字に問題はありません。 ただし、前述したように、すべてのエンコードがすべての文字を表示できるわけではありません。 ヨーロッパ言語のエンコードでは、文字encodeをエンコードすることはできません。 そして、恐ろしいことが起こるかもしれません。

Unicodeのすべて

だからこそ、21世紀にはUnicodeを使用しないという言い訳はありません。 特定の言語では、ヨーロッパ言語用の一部の特殊なエンコードはUnicodeよりも生産性が高い場合があります。 しかし、テラバイトの特別なテキストを扱う必要はありませんが（これは非常に多く）、心配する必要はありません。 互換性のないエンコーディングに起因する問題は、ギガバイトの損失よりもはるかに深刻です。 そして、この議論は、データストレージとチャネル幅の成長とコスト削減によってのみ重要になります。



システムが他のエンコーディングを使用する必要がある場合、まずテキストをUnicodeに変換し、どこかに表示する必要がある場合はそれを転送します。 そうでない場合は、データにアクセスする各ケースを慎重に監視し、可能であれば情報を失うことなく必要な変換を実行する必要があります。

幸せな偶然

データベースに接続されたWebサイトがありました。 私のアプリケーションはUTF-8のようなすべてを処理し、そのようにデータベースに保存しましたが、すべてがスーパーでしたが、データベースの管理パネルに行ったとき、何も理解できませんでした。

-匿名のbydloder

エンコードが正しく処理されない場合もありますが、すべてが正常に機能します。 データベースのエンコードがlatin-1に設定され、アプリケーションがUTF-8（またはその他）で動作することがよくあります。 一般に、1と0の任意の組み合わせは、シングルバイトlatin-1で有効です。 データベースがアプリケーションからフォーム11100111 10111000 10100111のデータをアプリケーションから受信する場合、アプリケーションが縧を意味すると考えて、喜んでそれらを保存します。 どうして？ 後で、データベースは同じビットをアプリケーションに返します。これは、意図したUTF-8シンボルreceivedを受け取ったため、満足しています。 しかし、db管理インターフェイスはlatin-1が使用されていることを認識しており、結果は次のとおりです。理解することは不可能です。

愚か者は単に宝くじに当たったが、星は彼の味方ではなかった。 データベース内のテキストに対する操作はすべて機能しますが、データベースがテキストを正しく解釈しないため、意図したとおりに実行されない場合があります。 最悪の場合、データベースは誤ってテキスト全体を破壊し、誤ったエンコードのためにインストール後2年で任意の操作を実行します（もちろんバックアップはありません）。

UTF-8およびASCII

UTF-8の天才はASCIIとのバイナリ互換性であり、これはすべてのエンコーディングの事実上の基礎です。 すべてのASCII文字はUTF-8で最大バイトを占有し、ASCIIと同じビットを使用します。 つまり、ASCIIはUTF-8で1：1に反映されます。 非ASCII文字は、UTF-8で2バイト以上を占めます。 ソースコードエンコーディングとしてASCIIを使用するほとんどのプログラミング言語では、テキストに直接UTF-8のテキストを含めることができます。

$ string = "漢字";

UTF-8に保存すると、シーケンスは次のようになります。

00100100 01110011 01110100 01110010 01101001 01101110 01100111 00100000

00111101 00100000 00100010 11100110 10111100 10100010 11100101 10101101

10010111 00100010 00111011

17の12バイト（1で始まるもの）のみがUTF-8文字（それぞれ3バイトの2文字）です。 他の文字はASCIIです。 パーサーは次を読み取ります。

$ string = "11100110 10111100 10100010 11100101 10101101 10010111";

パーサーは、引用符の後ろのすべてを、そのまま別の引用符まで処理する必要のあるビットのシーケンスとして認識します。 このシーケンスを単に出力する場合は、テキストをUTF-8で出力します。 他に何もする必要はありません。 パーサーは特にutf-8をサポートする必要はありません。文字通りに行を取得するだけです。 単純なパーサーは、実際にはUnicodeをサポートしなくても、この方法でUnicodeをサポートできます。 ただし、多くのプログラミング言語はユニコードを明示的にサポートしています。

エンコーディングとPHP。

PHPはUnicodeをサポートしていません。 確かに、彼は彼を十分にサポートしています。 前の段落は、UTF-8がASCIIと下位互換性があるため、問題なくプログラムテキストにUTF-8文字を直接含める方法を示しています。これはすべてのPHPのニーズです。 ただし、「PHPはUnicodeをサポートしていません」という主張は、PHPコミュニティで多くの問題を引き起こすため、真実です。

偽りの約束

utf8_encodeおよびutf8_decode関数は、私の唯一のカルスになりました。 「PHPでUnicodeを使用するには、入力テキストにutf8_encodeを呼び出し、出力にutf8_decodeを呼び出す必要があります。」 これら2つの関数は、何らかの種類の自動テキスト変換UTF-8を約束します。これは、「PHPはUnicodeをサポートしていないため」と思われます。 この記事を斜めに読んでいないなら、あなたはそれを知っている

1. UTF-8に固有のものはありません
2. 事後、UTF-8でテキストをエンコードすることはできません

ポイント2について説明します：テキストはすでに何かでエンコードされています。 ソースコードに行を貼り付けると、既にエンコードがあります。 より正確には、テキストエディタが現在使用しているエンコーディング。 データベースから取得する場合、それらはすでにエンコードされています。 あなたがファイルからそれらを読んだら...既に知っていますか？



テキストはUTF-8でエンコードされているか、エンコードされていません。 そうでない場合は、ASCII、ISO-8859-1、UTF-16などでエンコードされます。 UTF-8ではないが、「UTF-8文字」が含まれていると想定される場合、認知的不協和があります。 テキストにUTF-8でエンコードされた目的の文字がまだ含まれている場合は、UTF-8になります。



utf8_encodeは一体何をするのでしょうか？

「文字列ISO-8859-1をエンコーディングUTF-8に変換します」

うん！ 著者は、関数がテキストをISO-8859-1からUTF-8に変換すると言いたいと思っていました。 ここでは何のためです。 そのような恐ろしい名前は、もてなしの良いヨーロッパ人によって彼女に与えられたのでしょう。 utf8_decodeについても同じことが言えます。 これらの関数は、ISO-8859-1からUTF-8への変換以外には適用できません。 別のエンコーディングのペアが必要な場合は、iconvを使用します。

utf8_encode-これは魔法の杖ではありません。「PHPはUnicodeをサポートしていないため」すべての単語を振り回す必要があります。 それは解決するよりも多くの問題を引き起こします-そのヨーロッパ人と無知なプログラマーのおかげです。

ネイティブ規範

それで、言語がユニコードをサポートすると言うとき、彼らは何を意味しますか？ 言語が1文字が1バイトを占めると仮定するかどうかは重要です。 そのため、PHPでは、選択した文字にアクセスして、文字列を文字配列として処理できます。

echo $ string [0];

$文字列にシングルバイトエンコーディングがある場合、最初の文字が返されます。 ただし、「文字」がシングルバイトエンコーディングの「バイト」と一致するからです。 PHPは、文字を1つも考えずに最初のバイトを返すだけです。 PHPの文字列は、バイトシーケンスにすぎず、多かれ少なかれもありません。 これらの「読み取り可能な文字」は、人のフィクションにすぎません。PHPはそれらについて気にしません。

01000100 01101111 01101110 00100111 01110100

D on 't

01100011 01100001 01110010 01100101 00100001

気をつけて！

同じことが、substr、strpos、trimなどの多くの標準関数にも当てはまります。 サポートは、バイトと文字の間の対応が終了するところで終了します。

11100110 10111100 10100010 11100101 10101101 10010111

漢字

指定された文字列の$ string [0]は、11100110に等しい最初のバイトのみを返します。つまり、漢字の3番目のバイトです。 シーケンス11100110はUTF-8では無効であるため、文字列も正しくありません。 これもあなたに思える場合は、11100110が有効なランダム文字になる別のエンコードを試すことができます。 楽しむことはできますが、バトルサーバーではできません。



以上です。 「PHPはUnicodeをサポートしていません」とは、言語のほとんどの関数が1バイトが1文字に等しいと想定しているため、マルチバイト文字の切り捨てまたは文字列の長さの誤った計算につながることを意味します。 これは、PHPでUnicodeを使用できないこと、またはテキストをutf8_encode、または他の愚かなことで実行する必要があることを意味しません。



幸いなことに、すべての重要な文字列関数を追加する特別な拡張機能がありますが、マルチバイトエンコーディングがサポートされています。 上記の行のmb_substr（$文字列、0、1、 'UTF-8'）は、漢字に対応するシーケンス11100110 10111100 10100010を正しく返します。 関数は何をするかを考える必要があるという事実のために、エンコーディングを渡す必要があります。 したがって、これらの関数は$ encodingパラメーターを受け入れます。 ところで、エンコーディングは、mb_internal_encodingを使用して、すべてのmb_関数に対してグローバルに設定できます。

PHPエラー処理の使用と乱用

PHPでの（非）Unicodeサポートの全体的な問題は、インタープリターが気にしないことです。 バイトシーケンス、ha。 どういう意味でも。 文字列をメモリに保存する以外は何も行われません。 PHPには、エンコードという概念さえありません。 また、行を操作する必要はありませんが、これは重要ではありません。 作業はバイトシーケンスで行われます。これは、誰かが文字として認識することができます。 PHPでは、ASCIIと互換性のあるソースコードを保存するだけで済みます。 PHPパーサーは、何をすべきかを伝える特定の文字を探しています。 00100100によると、「変数を宣言する」、00111101-「割り当てる」、00100010-行の先頭または末尾など。 パーサーにとって重要ではないものはすべて、バイトシーケンスのリテラルとして認識されます。 これは、引用符で囲まれたすべてのものにも適用されます。 意味：

1. PHPでソースをASCII互換性のないエンコーディングに保存することはできません。 たとえば、UTF-16では、引用符は00000000 00100010としてエンコードされます。すべてをASCIIとして処理するPHPの場合、これは引用符が後に続くNULバイトです。 PHPは、おそらくすべての文字でしゃっくりして、NULになることがわかります。
2. PHPをASCII互換エンコーディングに保存できます。 最初の128個のエンコードポイントがASCIIと一致する場合、PHPはそれらを食べます。 PHPのすべての重要な文字は、ASCIIで定義された最初の128ポイント内にあります。 文字列リテラルにこの制限を超えるものが含まれている場合、PHPは注意を払いません。 ソースは、ISO-8859-1、Mac Roman、UTF-8、またはその他のエンコーディングで保存できます。 コード内の文字列文字は、ファイルを保存するエンコードを受け取ります。
3. PHPの外部ファイルには、任意のエンコーディングを使用できます。 パーサーがファイルを処理する必要がない場合、それは満足されたままになります。
   
   
   
   

   $ foo = file_get_contents（ 'bar.txt'）;

   
   
   
   
   上記は、bar.txtのバイトを$ foo変数に単純に入れます。 PHPは、コンテンツの解釈、エンコード、またはその他の不正行為を試みません。 ファイルにはバイナリデータまたは画像が含まれる場合がありますが、PHPは気にしません。
4. 外部エンコーディングと内部エンコーディングが一致する必要がある場合、実際に一致する必要があります。 ローカリゼーションは一般的なケースです。コードではecho localize（ 'Foobar'）のようなものを記述し、外部ファイルでは次のようにします。
   
   
   
   

   msgstr "フーバー"
   
   msgstr "フーバー"
   
   

   
   
   
   
   両方のFoobar文字列は、同じビット表現でなければなりません。 ソースコードがASCIIであり、ローカライズコードがUTF-16である場合、運が悪い。 追加の変換を実行する必要があります。
   
   

賢明な読者は、たとえば、ソースファイルのリテラルにUTF-16バイトを順番にASCIIで保存することは可能かと尋ねるかもしれません。もちろん、答えは常に次のとおりです。

echo "UTF-16";

エディターに強制的にエコー「」をASCIIおよびUTF-16からUTF-16で保存すると、すべてが機能します。 以下はバイナリ表現です。

01100101 01100011 01101000 01101111 00100000 00100010

エコー」

11111110 11111111 00000000 01010101 00000000 01010100

（UTF-16マーカー）UT

00000000 01000110 00000000 00101101 00000000 00110001

F-1

00000000 00110110 00100010 00111011

6 ";

最初の行と最後の2バイトはASCIIからのものです。 残りは、文字ごとに2バイトのUTF-16で表されます。 2行目の先頭の11111110 11111111は、UTF-16のテキストの開始を示すマーカーです（標準で必要とされるため、PHPはこれについて気にしません）。 このスクリプトは、UTF-16でエンコードされた文字列「UTF-16」を表示します。これは、2つの引用符の間のバイトを表示するだけで、テキスト「UTF-16」がUTF-16でエンコードされるためです。 一方、ソースはASCIIまたはUTF-16で完全に正しいわけではないため、エディターを開いて楽しんでください。

合計

PHPはUnicodeをサポートしていますが、パーサーに作業を行わせることができ、開発者がその機能を理解できる限り、エンコードはかなり正確です。 文字列を操作するときのみ注意する必要があります：分割、スペースの削除、カウント、およびバイトではなく文字の操作を必要とする他のすべての操作。 読み取りと出力を除いて、行で何も行われない場合、他の言語では見られない問題はほとんどありません。

サポートされている言語のエンコード

それでは、言語がユニコードをサポートすることはどういう意味ですか？ たとえば、JavascriptはUnicodeをサポートします。 実際、Javascriptの文字列はすべてUTF-8でエンコードされています。 そして、これはJavascriptで動作する唯一のエンコーディングです。 JavascriptでUTF-8以外の文字列を取得しないでください。 JavascriptはUnicodeを崇拝しますが、その程度は、言語のコアに異なるエンコードを操作するためのツールがないだけです。 Javascriptはほとんどの場合ブラウザで実行されるため、問題はありません。ブラウザはI / Oのエンコードとデコードの簡単なロジックを実行できます。



他の言語はエンコードをサポートするだけです。 内部作業は、単一のエンコーディングで、多くの場合UTF-16で実行されます。 しかし、これは、テキストをエンコードする際にプロンプ​​トを表示する必要があることを意味します。そうしないと、ユーザー自身がそれを判断しようとします。 ソースコードが保存されているエンコード、ファイルが保存されているエンコード、読み取り対象のエンコード、出力に必要なエンコードを指定する必要があります。 Unicodeを使用する必要があることが示されている場合、言語はその場で変換されます。 彼らは、PHPがバックグラウンドのどこかで半自動モードで行う必要があることをすべて行います。 PHPほど良くも悪くもなく、まったく異なります。 幸いなことに、文字列関数はようやく機能するようになりました。文字列にマルチバイト文字が含まれているかどうか、作業のために選択する関数、およびPHPで行う必要があるその他のことを考える必要はありません。

デブリユニコード

Unicodeは非常に多くの異なる問題を解決し、多くの異なるシナリオで機能するため、荒野を掘って代金を支払う必要があります。 たとえば、Unicode標準には、YAKKジオグリフの統一などの問題の解決に関する情報が含まれています。 日本、中国、韓国に共通する多くのキャラクターは、わずかに異なる方法で描かれています。 または、文字を小文字から大文字に、またはその逆、または往復に変換する問題。これは、西ヨーロッパ言語のエンコーディングの場合ほど簡単ではないことがあります。 一部のキャラクターは、異なるポイントで表される場合があります。 たとえば、文字öは、パラグラフU + 00F6（「ラテン語の小文字のディエレシス」）または2つのパラグラフU + 006F（「小文字のレターO」）およびU + 0308（「代替糖尿病」）で表すことができます。 ¨で。 UTF-8では、これは2バイトまたは3バイトで、どちらの場合も通常の文字です。 したがって、標準には正規化ルールがあります。 これらのフォームを別のフォームに変換する方法。 これ以上のことはこの記事の範囲を超えていますが、これらの点について知る必要があります。

再びナイアシリル！

1. テキストは常にビットのシーケンスであり、テーブルを使用して自然言語に翻訳する必要があります。 無効なテーブル-無効な文字。
2. テキストを直接操作することはできません。常に抽象化されたビットを操作します。 エラーは、抽象化の1つのエラーに関連しています。
3. 互いに情報を送信するシステムは、常に機能するエンコードを示す必要があります。 たとえば、サイトはブラウザに情報をUTF-8に送信していることを伝えます。
4. 現在、UTF-8は、ほとんどすべての文字をエンコードできるにもかかわらず、ASCIIと下位互換性がありますが、ほとんどの場合比較的有効です。 他のエンコーディングも適用されますが、Unicodeの一部のみをサポートするエンコーディングで苦しむ深刻な理由がなければなりません。
5. プログラムとプログラマの両方が、バイトと文字の一致の問題に対処する必要があります。

再びテキストを台無しにしたときに正当化するものは何もありません。