くだすれPython(超初心者用)　その5

UnicodeError: Shift_JIS decoding error: invalid character 0x878a
args = ('Shift_JIS decoding error: invalid character 0x878a',)
具体的にどんなエラーでしょうか？

>>230
文字コードの指定を間違えてるか、入力ファイルに不正な文字が含まれていてデコードに失敗

不正な文字じゃなくても
「〜」が入ってるとだめだったりするな

>>> '〜'.decode('mbcs')
u'\uff5e'
>>> '〜'.decode('shift_jis')
u'\u301c'
>>> '〜'.decode('cp932')
u'\uff5e'
>>> '〜'.decode('cp932').encode('utf-8')
'\xef\xbd\x9e'
>>> '〜'.decode('shift_jis').encode('utf-8')
'\xe3\x80\x9c'

>>230
WindowsのShift_JISは、厳密にはCP932っていうShift_JISの拡張になってるから
文字コードの指定で"cp932"を与えないと一部の特殊文字とかが読めない。
�鰍ﾁて字が読めてない。

>>231-234
本格的なアプリを作るならともかく使い捨て程度のコードですら文字コードでトラブルというのは
良い仕様とは言えないよな・・・仕様に文句言ってもしょうがないんだけどさ
1Byte圏発のブツだとこういう事が良くあるんだよなぁ

>>235
なんか根本的なところが間違ってる、とまではいわないまでも、考え違いをしているような気がする。
もういちどスタートラインに戻って考え直してみてはいかが？

>>236
日本で使う言語として
print "こんにちは"
が動かないのはどうかと思うのよ

一行目にshebangがあるとして
ソースはUTF-8で保存した上で
二行目に
# -*- coding: utf-8 -*-
すると幸せになる

>>238
幸せになれるというかこれしないと
タイプ数アホみたいに増えるから必須だと思う

>>235
たしかにPythonの文字コードまわりの面倒くささは尋常じゃないね

俺は一旦すべてユニコードにしてから必要なときにエンコードする
ようにしてるけど、ここまで徹底する必要あるのか?と度々思う

そんなんじゃPython3000についてけねーぞ
標準ライブラリですら内部でstrに変換しやがるのがあるくらいだし別に徹底してない

>>240
そこまで徹底するのが、文字化け対策として一番楽なんだよ。

>>237
動かないわけ無いだろ。
Python3では問題ないし、Python2でもソースエンコーディングとターミナルのエンコーディングが一致
していれば動く。

Python2 でターミナルのエンコーディングと違うソースエンコーディング使いたいなら、最初に
from __future__ import unicode_literals
とするか、 u"こんにちは" と書けば良い。

>>240
正解

>>234
ありがとうございます。。
うまくいきましたが、こんどはMS932というので引っかかってしまいました。
.decode('cp932','ignore')ってやるとあとあと困ったりしますか？

困るかもって思うなら
http://www.python.jp/doc/release/lib/codec-base-classes.html#codec-base-classes
ここ見て置換させるとか
2chのdatなんてcp932/shift_jis/shift_jis_2004/shift_jisx0213のどれ使ってもエラー吐くときあるし

>>244
これ便利 => chardet.detect()

別途インストールしないと使えない(多分)のが玉に瑕

chardetはある程度の長さがないと役に立たんのがなあ
まあ仕組上当たり前の事なんだが
ID3タグみたいなエンコーディングどころかロケール情報もないクソフォーマット触った時は頭抱えたわ

def decorder(u):
  if isinstance(u, unicode): return u
  for cd in ['utf-8', 'euc-jp', 'cp932', 'iso-2022-jp', 'latin-1', 'ascii']:
    try:
      u = u.decode(cd)
      break
    except UnicodeDecodeError:
      continue
  else:
    u = u.decode('latin-1', 'replace')
  return u

>>238
それを強要する仕様を初心者向けと謳うのはどうかと思うわけだが
今時のメインシステムはWindowsでSJISだし

とりあえずUTF-8で書いとけってのにはまだ賛同できるが
Emacsスタイルのコメントがむかつく

>>249
なんか今日の変な発言はみんなあんたなのかも知れんが
Pythonには初心者に優しい仕組みを提供するみたいな理念はないぞ
読みやすく、バランス良くって結果がたまたま初心者にもそこそこ使いやすいって状況になっただけ

簡単なものを複雑であるかのように見せかけてはいけない。
複雑なものを簡単であるかのように見せかけてはいけない。

thisってんじゃねーぞ

>>249
いや、コードページがCP932だからといって、スクリプトのエンコーディングまで
勝手にCP932だと仮定されてしまうようだとまずいだろ
スクリプトを書くのは自分だけじゃないんだぞ

日本語Windowsで実行しているからと言ってブラウザがHTMLを
全部CP932だと考えるようではまずいのと同じだ
エンコーディングなんて書いた奴しか分からない（推定はできるが）ので
指定させるのが確実で手っ取り速い、HTMLと同じだろ？

>>250
> Emacsスタイルのコメントがむかつく
別にEmacsスタイルである必要は無いよ
#coding: utf-8
とかでいい
実際には
coding[=:]\s*([-\w.]+) という正規表現で
エンコーディング指定らしきものとパターンマッチしている

そういうことじゃなくて幸せになれるのは誰かってこと
Windowsでそこらのエディタ使ってる初心者が幸せになれるわけじゃないよね

あとPEPから正規表現抜いてくるんなら
引用元書いたほうが勉強してる人が幸せになれるよ

WindowsっていつまでSJIS使うんだろうなwww

C の初心者は
#include <stdio.h>
を
#include <studio.h>
と平気で書いたりするからな
python でも
# code: shift_jis
とか書いて動かないとか言い出す香具師が出てきてもおかしくない
「初心者」と「アホ」は区別して良いと思う

>>254
ブラウザは実用に支障のないレベルで文字コードを自動判別してくれるぞ
そこまでは行かなくてもWindows向けインタプリタのデフォルト文字コードは
mbcsでも良いはずだ

どうですか？
http://boost.cppll.jp/HEAD/libs/date_time/doc/BuildInfo.html

スレ的にはこっちが良かったかな
http://boost.cppll.jp/HEAD/libs/python/doc/index.html

>>258
> そこまでは行かなくてもWindows向けインタプリタのデフォルト文字コードは
> mbcsでも良いはずだ

それじゃ全然ダメなんだよ
他人が書いたモジュールやスクリプトのことも考えろ

mbcsの意味がCP932なのは日本語ウィンドウズの話であって
外国ではWindows-1252だったりするわけだ
Windows-1252な環境の連中の書いたモジュールやスクリプトを
CP932でデコードして動くとでも思うのか？

>>258
誤爆する可能性のある判別法を自動適用するとかアホすぎるぞ

ブラウザにhtmlの文字コード自動判定する機能があるからといって、それに依存して
きちんとヘッダを書かないのは間違い。
ブラウザは自動判定ミスっても間違って表示するだけだけど、
プログラムが自動判定ミスって間違って動作するとマズイだろ。

曲がりなりにもプログラミング言語なのに
まともにHTMLすら書けないレベルの奴はさすがに相手にしてないだろｗ

#coding: cp932のようにソースエンコーディングを指定するのも
#include <stdio.h>とか書くのも
何かを足すときに+と書くのも
全部言語仕様であり決まりごとに過ぎんと思うが

>>261
配布されているコードは文字コードが書いてあるんだからデフォルトの文字コードが
何になっていようが問題ないのではないかい？

> 配布されているコードは文字コードが書いてあるんだから
運用ルールで済ませるのではなく、「確実に」強制する方法を
Pythonが選んだというだけだろ
それ以外に「確実に」強制する方法は存在しないわけだし

1byte圏の人間がどんだけ文字エンコーディングに関心を持たないかなんて
知ってるだろ
こんだけやってくれてるのはむしろ有難いと思ったほうがいいぞ

そうだな、これだけ厳密にやってくれてるから、Python製で日本語でも問題起きない
アプリが多いんだよな。

>>260
そこヘッダにエンコードも書いてあるのに
なんで化けるんだろう？

エラーは明示的に、という設計思想だから一見文字コードのエラー(UnicodeEncode/DecodeEroor)が多いように見えるが、
どこがまずいのかを明確に指摘してくれるから俺のような初心者には逆にありがたい。

>>269の2行目は「それはどこがまずいのか明確に指摘してくれるってことだから〜」にしてくれ
>>268
レスポンスヘッダがUTF-8になってるから

HTTPサーバのレスポンスヘッダの方が優先されるのね。不思議

>>271
ttp://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/charset.html
HTML4.0仕様の5.2.2に優先順位が書いてある
サーバレスポンスが一番優先順位が高い

>>270
なるほど�d
Apacheのバージョン変えたときに
AddDefaultCharset UTF-8 のままにしちゃってるパターンか
中のひと分かってるのかなぁ

馬鹿よけのためにわざとやってるサイトがあるという話を聞いたことがある

「原則unicodeで必要なときだけstrに変換すべき」
理想ではあるけど現実的じゃないよね

utf-8派がutf-8化の強制を目的としてわざとやることはある。

そう、従わない奴が多いからPython3はああいう仕様になった
そういう意味では現実的ではない

最近はUTF-8が増えてきたとは言え文字コードの扱いなんてそれぞれの言語圏で
育った文化の上に成り立っている物だし、それをガン無視して「仕様なんだから、こうしろ」とか
言っても不満が噴出して当然だよな

日本なんかいまだにJIS、SJIS、EUC-JP、UTF-8やらが入り乱れている状態だしなｗ

意味が分からん
少なくともプログラマが吐くセリフじゃない

Unicodeには言語学者とかも係わってくるから騒ぎが大きいけど、
Pythonには不満が噴出するほど人がいない。

プログラマなら UTF-8 一択だろ JK

>>281
バカか？ｗ
扱う文字コードをすべてUTF-8に統一できるわけがないだろうｊｋ

それはお前がおかしい。

>>281
みたいなのがプログラマだったら大変だな
「仕様書が悪い」とか言い出しそうだｗ

>>282
扱う文字コードではなく、ソースコードのエンコーディングの話をしてるんだぞ？

意味が分からん
少なくともプログラマが吐くセリフじゃない