仕様¶

このPEPはデフォルトソースエンコーディングをASCIIからUTF-8へ変更することを提案します。代替となるソースエンコーディング [1] 、つまり明示的なエンコーディング定義をデフォルトよりも優先することは継続的にサポートします。

小歴史¶

システムの基本的な実行文字コードのスーパーセット(例えば、ほとんどのシステムではASCIIのスーパーセット)を使用しなければならなかったソースエンコーディングを除けば、Python1ではソースエンコーディングが未定義でした。ソースエンコーディングは、文法上のキーワード、識別子、句読点や改行等のキーワードを表す文字のバイトデータにのみ関係していました。そして、文字列のリテラルはソース上のファイルからそのままコピーされました。

Python2.0では、ソースエンコーディングはユニコード文字の提供による副作用でLatin-1へ変更されました。ユニコード文字列のリテラルは、それでもソースファイルからそのままコピーされていましたが、基本的には文字単位で拡張されました。ユニコードはコードポイントを固定して解釈されるので、少なくともユニコード文字列のリテラルにASCII文字を含まないファイルにとってはこのアルゴリズムは効率良くソースエンコーディングを扱いました。

PEP263では、ユニコード文字列のリテラルの中にLatin-1も含めたユニコード文字が使用できるという課題を確認しました。そして、ソースエンコーディングを定義するための構文を紹介しました。もしソースエンコーディングが定義されていなければ、デフォルトはASCIIになります。Python2.0と2.1の互換性とファイルに関しては移行期間のためLatin-1として解釈されました。この移行期間はPython 2.5で終了しました。もしASCIIではない文字を発見して、ソースエンコーディングが定義されていなければエラーが発生します。

論理的根拠¶

PEP263でPythonファイルにASCIIではない任意の文字コードを使用することが可能になりましたが、つまらないものでした。その理由の1つは明示的にエンコーディングの定義を追加しなければならない点です。(IDLEやEmacsのような)エディタによってはPEP263の定義をサポートしましたが、多くのエディタはまだサポートされていません(きっと今後もしないでしょう)。つまり、本来はエディタが基本機能としてファイル単位に推測するエンコーディングをユーザが明示的に指定しなければなりません。

そのデフォルトエンコーディングがUTF-8へ変更されると、Pythonが扱うファイルへASCIIではないテキストを追加することが簡単で移植性の高いものになります。つまり、(例えば、ロケールにUTF-8を使用するUnix)システムによっては、エディタはテキストファイルを保存するときに自動でUTF-8を選択するでしょう。一方、他のシステムでは、エディタはファイルを読み込んでエンコーディングを推測するでしょう。そして、UTF-8は推測し易いエンコーディングです。また別のエディタでは、UTF-8と.pyのようなファイル拡張子とデフォルトエンコーディングをユーザが関連付けるのをサポートします。

Python2のために、UTF-8ではないエンコーディグを使用する大きな理由は、バイト文字列のリテラルが実行時にソースエンコーディングとなり、バイト文字列のリテラルをファイルへ出力する、又はユーザへそのまま表示するようにすることでした。Python3では、全ての文字列がユニコード文字列なのでソースファイルのオリジナルのエンコーディングは実行時に何の影響も与えません。

実装¶

そのパーサーはソースエンコーディングが指定されていない場合、127 バイトより大きなマルチバイト文字を許容するように変更する必要があります。つまり、エラーを発生させる代わりにマルチバイト文字列が一般的なUTF-8であるかをチェックします(デコーディングは必要ではなく、取りあえずパーサーが全ソースコードをUTF-8へ変換します)。

IDLEはデフォルトエンコーディングにUTF-8を使用するように変更する必要があります。

参照¶

著作権¶

このドキュメントはパブリック・ドメインに属します。