Django のようないくつかのフレームワークが至る所で Unicode を使用しているのを目にするので、それは良い考えのように思えます。
一方で、これらすべての余分な 'u' がいたるところに浮かんでいるのは大きな苦痛のように思えます。
これをしないと何が問題になるのですか?
これを行った場合に発生する問題はありますか?
現在、フレームワークとして Pylons を使用しています。
Django のようないくつかのフレームワークが至る所で Unicode を使用しているのを目にするので、それは良い考えのように思えます。
一方で、これらすべての余分な 'u' がいたるところに浮かんでいるのは大きな苦痛のように思えます。
これをしないと何が問題になるのですか?
これを行った場合に発生する問題はありますか?
現在、フレームワークとして Pylons を使用しています。
Python 3 では、すべての文字列が Unicode です。そのため、必要なあらゆる場所で文字列を使用してこれに備えることができます。その後、最終的にツールu''
を使用して Python 3 にアップグレードすると、すべてのs が消えます。また、Unicode 文字列を使用してコードを既にテストしているため、より良い立場に立つことができます。2to3
u
テキスト対を参照してください。Unicode Vs の代わりにデータ。詳細については、 8 ビットを参照してください。
これをしないと何が問題になるのですか?
私は日本に住む西洋人なので、ASCII 以外の文字を扱うために何が必要かを直接見てきました。Unicode 文字列を使用しない場合の問題は、AZ 以外のものを使用する世界の一部にとって、コードがフラストレーションになることです。当社は、特定の Web ソフトウェアで日本語の文字を完全に台無しにせずに処理できるようにするために、多大なフラストレーションを感じてきました。
英語を話す人が Unicode の素晴らしさを理解するには少し努力が必要ですが、コンピューターをすべての文化や言語にアクセスできるようにするのは本当に大変な作業です。
"落とし穴":
出力 Web ページで使用中のエンコーディングが適切に記述されていることを確認し (たとえば、コンテンツ エンコーディング ヘッダーを使用)、出力時にすべての Unicode 文字列を適切にエンコードします。Python 3 Unicode 文字列は、これを正しく行うための大きな改善です。
すべてを Unicode 文字列で行い、出力を行う最後の瞬間にのみ特定のエンコーディングに変換します。PHP などの他の言語では、UTF-8 形式などで Unicode を操作するとバグが発生しやすくなります。Unicode 文字列を切り詰める必要があるとします。内部的に UTF-8 形式の場合、途中でマルチバイト文字が切り捨てられ、ゴミのような出力になる可能性があります。Python が内部で Unicode 文字列を使用しているため、これらの間違いを犯しにくくなっています。
内部で Unicode を使用することは、非 ASCII 文字の問題を回避するための良い方法です。アプリケーションの境界で変換します (受信データを Unicode に、送信データを UTF-8 などに)。Pylons は多くの場合に変換を行うことができます: たとえば、コントローラは安全に Unicode 文字列を返すことができます。SQLAlchemy モデルは Unicode 列を宣言する場合があります。
ソース コードの文字列リテラルについて: 通常、u プレフィックスは必要ありません。ASCII を含む str オブジェクトと unicode オブジェクトを安全に混在させることができます。すべての文字列リテラルが純粋な ASCII であるか、u"unicode" であることを確認してください。