C 拡張機能のバグにより、str インスタンスを含む Unicode データを取得しています。つまり、エンコーディングがまったくない str と Unicode リテラルを取得しています。
したがって、たとえば、これは有効な Unicode リテラルです
>>> u'\xa1Se educado!'
UTF-8 でエンコードされた str は次のようになります。
>>> '\xc2\xa1Se educado!'
ただし、ユニコードリテラルで str を取得します。
>>> '\xa1Se educado!'
そして、そこから unicode インスタンスを作成する必要があります。unicode()エンコーディングが必要なため、使用は機能しません。私はそれ''.join(unichr(ord(x)) for x in s) が私が必要とすることをすると思ったが、それは本当に醜い. より良い解決策が必要です。何か案は？
Unicode リテラルで str を取得します。
'\xa1Se educado!'
そうで\xa1はなく、Unicode 固有のエスケープではありません。\xa1はバイト文字列ではバイト番号 161 を意味\xa1し、Unicode 文字列では文字 (コード ポイント) 番号 161 を意味します (. と同じ) \u00A1。
あなたが持っているのは¡Se educado!、UTF-8エンコーディングの代わりにISO-8859-1エンコーディングを含むバイト文字列です。ISO-8859-1 エンコーディングでは、各バイト番号がたまたま同じコード ポイント番号の Unicode 文字と一致します。ISO-8859-1 バイト文字列を Unicode 文字列にデコードするには、次を使用します。
>>> '\xa1Se educado!'.decode('iso-8859-1')
u'\xa1Se educado!'
ただし、実際に Windows を使用している場合、エンコーディングは'windows-1252'ISO-8859-1 ではなくコード ページ 1252 ( ) である可能性があります。これらは同様のエンコーディングですが、まったく同じではありません。コード ページ 1252 は、Windows が西ヨーロッパおよび米国のロケールで非 Unicode アプリケーションに使用する既定の 'ANSI' コード ページです。同じマシンで実行されている Windows の非 Unicode アプリケーションからこのデータを取得する場合は'mbcs'、ロケール固有のデフォルト コード ページが何であれ、それに対応するエンコーディングを使用してデコードする必要があります。
これらは、すべての Unicode 文字を保持できないレガシー エンコーディングです。おそらく、C 拡張機能は、現在のコード ページ セット以外の文字をまったく処理できないことに気付くでしょう。