ダミーのためのユニコード

私自身は「ダミー/鍋/鍋用のポケモンジュース」のような見出しはあまり好きではありませんが、これは事実と思われます-基本的なことについて話します。 「なぜ機能しないのですか？」 まだ怖い、および/またはユニコードを理解していない場合-私は猫を求めます。

なんで？

初心者の主な質問であり、印象的なエンコーディングと、一見複雑なメカニズム（Python 2.xなど）に遭遇します。 短い答えは、それが起こったためです:)

コーディングは、知らないうちに、コンピューターのメモリー（ゼロ単位\数字で読みます）で数字、ブナ、その他すべての文字を表す方法と呼ばれます。 たとえば、スペースは0b100000（バイナリ）、32（10進数）、または0x20（16進数）として表されます。

そのため、メモリが非常に少なくなり、すべてのコンピューターに必要なすべての文字（数字、小文字/大文字のラテンアルファベット、一連の文字、いわゆる制御文字-すべての127の数字が誰かに与えられました）を表すのに十分な7ビットがありました。 当時のエンコーディングは1つのASCIIでした。 時間が経つにつれて、誰もが幸せで、誰も幸せではありませんでした（読む-「©」またはネイティブの文字「u」を欠く人）-残りの128文字を自由裁量で使用しました。 そのため、 ISO-8859-1と（キリル文字の） cp1251とKOI8が登場しました 。 それらに加えて、タイプ0b1 *******（つまり、128から255の文字\番号）のバイトを解釈する問題が発生しました-たとえば、cp1251エンコーディングの0b11011111はISOのネイティブ「I」であり、 8859-1はギリシャ語のドイツ語のEszett（ 月の出を告げる）で「ß」です。 HTTPプロトコルの「Content-Encoding」などのヘッダー、電子メールメッセージ、HTMLページが状況を少し保存したにもかかわらず、ネットワーク通信と異なるコンピューター間のファイル共有だけが地獄の知識に変わりました。

その瞬間、明るい頭脳が集まり、新しい標準であるUnicodeを提案しました。 これはエンコードではなく標準です。Unicodeだけでは、文字がハードドライブに保存される方法やネットワーク経由で送信される方法は決定されません。 文字と特定の数字の間の関係のみを定義し、これらの数字がバイトに変換される形式はUnicodeエンコード（ UTF-8またはUTF-16など ）によって決定されます。 現在、Unicode標準には10万文字を少し超える文字がありますが、UTF-16では100万を超える文字（UTF-8など）をサポートできます。

このトピックについて、壮大なJoel Spolskyが絶対に最小のすべてのソフトウェア開発者であり、ユニコードと文字セットについて絶対に前向きに知っておく必要があるトピックを読むことをお勧めします。

要点をつかもう！

当然、PythonでもUnicodeがサポートされています。 しかし、残念ながら、Python 3でのみすべての文字列がユニコードになり、初心者は次のようなエラーについて自殺しなければなりません。

>>> with open('1.txt') as fh: s = fh.read() >>> print s  >>> parser_result = u'-' #   ,  ,     -  >>> parser_result + s 

 Traceback (most recent call last): File "<pyshell#43>", line 1, in <module> parser_result + s UnicodeDecodeError: 'ascii' codec can't decode byte 0xea in position 0: ordinal not in range(128) 

または：

 >>> str(parser_result) 

 Traceback (most recent call last): File "<pyshell#52>", line 1, in <module> str(parser_result) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-3: ordinal not in range(128) 

それを理解しましょうが、順番に。

誰かがユニコードを使用しているのはなぜですか？

お気に入りのHTMLパーサーがUnicodeを返すのはなぜですか？ 通常の文字列を返すようにしましょう。そうすれば、すでにそこで対処します。 そう？ そうでもない。 Unicodeに存在する各文字は（おそらく）いくつかのシングルバイトエンコーディング（ISO-8859-1、cp1251などはシングルバイトと呼ばれます。文字を1バイトで正確にエンコードするため）ですが、文字列に文字がある場合はどうでしょうか異なるエンコーディングから？ 各文字に個別のエンコーディングを割り当てますか？ いいえ、もちろん、Unicodeを使用する必要があります。

なぜ新しいタイプの「ユニコード」が必要なのですか？

だから、私たちは最も興味深いことになりました。 Python 2.xの文字列とは何ですか？ これらは単なるバイトです。 何でもかまいません。 実際、次のようなものを書くとき：

 >>> x = 'abcd' >>> x 'abcd' 

インタープリターは、ラテンアルファベットの最初の4文字を含む変数を作成しませんが、シーケンスのみを作成します

 ('a', 'b', 'c', 'd') 

4バイトで、ラテン文字はこの特定のバイト値を示すためにのみ使用されます。 つまり、ここでの「a」は「\ x61」を記述するための単なる同義語であり、もう少しではありません。 例：

 >>> '\x61' 'a' >>> struct.unpack('>4b', x) # 'x' -    signed/unsigned char- (97, 98, 99, 100) >>> struct.unpack('>2h', x) #   short- (24930, 25444) >>> struct.unpack('>l', x) #   long (1633837924,) >>> struct.unpack('>f', x) #  float (2.6100787562286154e+20,) >>> struct.unpack('>d', x * 2) #    double- (1.2926117739473244e+161,) 

それだけです！

そして、質問への回答-「ユニコード」が必要な理由はより明白です-バイトではなく文字で表されるタイプが必要です。

まあ、私はラインが何であるか理解しました。 次に、PythonのUnicodeとは何ですか？

「タイプユニコード」は、主にユニコードの概念（それらに関連付けられた文字と数字のセット）を実装する抽象化です。 「ユニコード」タイプのオブジェクトは、もはやバイトのシーケンスではなく、文字自体のシーケンスであり、これらの文字がコンピューターのメモリにどのように効果的に保存されているかについてはまったくわかりません。 必要に応じて、これはバイト文字列よりも高い抽象化レベルです（Python 3では、Python 2.6で使用される通常の文字列と呼ばれます）。

Unicodeの使用方法

Python 2.6でUnicode文字列を作成するには、3つの（少なくとも自然な）方法があります。

• u ""リテラル：

   >>> u'abc' u'abc' 

  
  
• バイト文字列のデコードメソッド：

   >>> 'abc'.decode('ascii') u'abc' 

  
  
• Unicode関数：

   >>> unicode('abc', 'ascii') u'abc' 

  
  

最後の2つの例のasciiはエンコードとして指定され、バイトを文字に変換するために使用されます。 この変換の段階は次のようになります。

 '\x61' ->  ascii ->   "a" -> u'\u0061' (unicode-point   )  '\xe0' ->  c1251 ->   "a" -> u'\u0430' 

Unicode文字列から通常を取得する方法は？ エンコードする：

 >>> u'abc'.encode('ascii') 'abc' 

コーディングアルゴリズムは、当然上記の逆です。

覚えておいてください-混同しないでください-Unicode ==文字、文字列==バイト、およびバイト->意味のあるもの（文字）はデコード（デコード）であり、文字->バイトはエンコード（エンコード）です。

エンコードされていない:(

記事の最初から例を見てみましょう。 文字列とUnicode文字列の連結はどのように機能しますか？ 単純な文字列はUnicode文字列に変換する必要があり、インタープリターはエンコードを知らないため、デフォルトのエンコードであるasciiを使用します。 このエンコードが文字列のデコードに失敗すると、weいエラーが発生します。 この場合、正しいエンコーディングを使用して、文字列をUnicode文字列にキャストする必要があります。

 >>> print type(parser_result), parser_result <type 'unicode'> - >>> s = '' >>> parser_result + s 

 Traceback (most recent call last): File "<pyshell#67>", line 1, in <module> parser_result + s UnicodeDecodeError: 'ascii' codec can't decode byte 0xea in position 0: ordinal not in range(128) 

 >>> parser_result + s.decode('cp1251') u'\xe1\xe0\xe1\xe0-\xff\xe3\xe0\u043a\u043e\u0449\u0435\u0439' >>> print parser_result + s.decode('cp1251') - >>> print '&'.join((parser_result, s.decode('cp1251'))) -& #   :) 

「UnicodeDecodeError」は通常、正しいエンコーディングを使用して文字列をUnicodeにデコードする必要があることの証拠です。

現在、strおよびUnicode文字列を使用しています。 「str」およびユニコード文字列を使用しないでください:)「str」ではエンコーディングを指定する方法がないため、デフォルトのエンコーディングが常に使用され、128文字を超えるとエラーが発生します。 「エンコード」メソッドを使用します。

 >>> print type(s), s <type 'unicode'>  >>> str(s) 

 Traceback (most recent call last): File "<pyshell#90>", line 1, in <module> str(s) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128) 

 >>> s = s.encode('cp1251') >>> print type(s), s <type 'str'>  

「UnicodeEncodeError」は、Unicode文字列を通常の文字列に変換するときに正しいエンコードを指定する必要があることを示します（または「encode」メソッドで2番目のパラメーター「ignore」\「replace」\「xmlcharrefreplace」を使用します）。

もっと欲しい！

さて、上記の例の馬場やがを再び使用します。

 >>> parser_result = u'-' #1 >>> parser_result u'\xe1\xe0\xe1\xe0-\xff\xe3\xe0' #2 >>> print parser_result áàáà-ÿãà #3 >>> print parser_result.encode('latin1') #4 - >>> print parser_result.encode('latin1').decode('cp1251') #5 - >>> print unicode('-', 'cp1251') #6 - 

この例は完全に単純ではありませんが、すべて（まあ、またはほとんどすべて）があります。 ここで何が起こっていますか：

1. 入り口には何がありますか？ IDLEがインタープリターに渡すバイト。 出口で何が必要ですか？ Unicode、つまり文字。 バイトを文字に変換することは残っていますが、エンコードが必要ですよね？ どのエンコーディングが使用されますか？ さらに調べます。
   
2. 重要なポイントは次のとおりです。

    >>> '-' '\xe1\xe0\xe1\xe0-\xff\xe3\xe0' >>> u'\u00e1\u00e0\u00e1\u00e0-\u00ff\u00e3\u00e0' == u'\xe1\xe0\xe1\xe0-\xff\xe3\xe0' True 

   ご覧のとおり、Pythonはエンコードの選択を気にしません-バイトは単にUnicodeポイントに変わります：
   

    >>> ord('') 224 >>> ord(u'') 224 

3. ここにのみ問題があります-cp1251の224番目の文字（インタープリターが使用するエンコード）は、ユニコードの224とまったく同じではありません。 このため、Unicode文字列を印刷しようとするとkrakozyabraが取得されます。
   
4. 女性を助ける方法は？ 最初の256個のUnicode文字は、それぞれISO-8859-1 \ latin1エンコードと同じであることがわかります。それを使用してUnicode文字列をエンコードすると、入力したバイトを取得します（気にするのは-Objects / unicodeobject.c 、関数「unicode_encode_ucs1」の定義を探しています）：
   

    >>> parser_result.encode('latin1') '\xe1\xe0\xe1\xe0-\xff\xe3\xe0' 

5. 女性をユニコードにする方法は？ 使用するエンコードを指定する必要があります。
   

    >>> parser_result.encode('latin1').decode('cp1251') u'\u0431\u0430\u0431\u0430-\u044f\u0433\u0430' 

6. ポイント5からのメソッドは確かにそれほど暑くはありません。組み込みのunicodeを使用する方がはるかに便利です。

実際、問題はコンソールでのみ発生するため、「u」リテラルのすべてがそれほど悪いわけではありません。 実際、ソースファイルで非ASCII文字が使用されている場合、Pythonは "＃-*-coding：-*-"（ PEP 0263 ）のようなヘッダーの使用を要求し 、Unicode文字列は正しいエンコーディングを使用します。

たとえば、キリル文字を表すために「u」を使用する方法もあり、エンコードまたは読み取り不能なUnicodeポイント（つまり、「u '\ u1234'」）を指定しません。 この方法は完全に便利ではありませんが、興味深いのはユニコードエンティティコードを使用することです。

 >>> s = u'\N{CYRILLIC SMALL LETTER KA}\N{CYRILLIC SMALL LETTER O}\N{CYRILLIC SMALL LETTER SHCHA}\N{CYRILLIC SMALL LETTER IE}\N{CYRILLIC SMALL LETTER SHORT I}' >>> print s  

まあ、すべてがそうです。 主なヒントは、「エンコード」と「デコード」を混同しないで、バイトと文字の違いを理解することです。

Python 3

経験がないため、コードはありません。 目撃者は、すべてがそこでより簡単でより楽しいと主張します。 ここ（Python 2.x）とそこ（Python 3.x）の違い-尊敬と尊敬の違いを実証するために、誰が猫を引き受けますか。

役に立つ

エンコーディングについて話しているので、時々krakozyabraを克服するのに役立つリソース-http://2cyr.com/decode/?lang=enをお勧めします

繰り返しになりますが、Spolskyの記事へのリンク- すべてのソフトウェア開発者が絶対的かつ積極的にUnicodeおよび文字セットについて知っておく必要のある絶対最小値です。

Unicode HOWTOは、Python 2.xのUnicodeの場所、方法、理由に関する公式ドキュメントです。

ご清聴ありがとうございました。 プライベートでのコメントに感謝します。

PSは、Spolsky- Absolute Minimumの翻訳へのリンクを投げました。これは、すべてのソフトウェア開発者がUnicodeと文字セットについて知っている必要があります。