UTF-8でmoblogすると文字化けするバグ直った。。。
ええ，ほんの息抜きのつもりだったんです。前々から気になっていた，COREBlogをUTF-8で運用していてmoblogでエントリーを追加すると文字化けするバグ，どうしてなのかなー，と思って怪しい部分を見ていると，なんとそこに。。。
というわけで直りました(多分)。Ploneなんかと組み合わせてUTF-8でCOREBlogを運用している人とか，UTF-8で送信されたTrackbackが化けてイヤーンな人はこのファイルをダウンロードして，utility.pyと入れ換えてみてください。
あ，念のため，古いutility.pyをバックアップするのと，ダウンロードしたファイルのファイル名をutility.pyに変えるのをお忘れなく。また当然，入れ換えたあとはCOREBlogのProductをリフレッシュするか，Zopeを再起動する必要があります。
- Category(s)
- COREBlog
- The URL to Trackback this entry is:
- http://coreblog.org/ats/184/tbping
moblogの文字化けが直った!
UTF-8でmoblogすると文字化けするバグ直った。。。らしいので、早速、入れ換えてみました。うちの環境(Python2.1+zope2.6.1)だと、pykfがうまく動かなかった(文字化けしたまま)なので、kconvの方...
utility.py のパッチを作りました
excerpt に文字化けが発生するのでパッチ作りました。
文字列を指定された長さで切り出すモジュールが UTF-8 に対応していないようです。Shift_JIS もついでにコードを修正しました。
ここにソースとパッチ置いてあります。
UTF-8 は今のところうまく動作しているよう...
moblogの文字化け直りませんと思ったら。。。
と思った...
最近文字コード変換を少し試してみたのですが、
漢字コードの判定は pykf.guess() より kconv.ChkCoding() の方が少し正確な気がしました。
pykf だと utf-8 の"もじ化け" などの短い文を判定させると Shift_JIS が返ってきました。
一方 kconv の方は ascii の判定をしてくれないので、先行して ascii 判定する処理が必要になるとは思いますが。
あと unicode() メソッドですが python2.2 以降じゃないと誤動作するような気がします(記事を探したけど見付からなかった;;)
使いかたに間違いあるかもしれないので、ツッコミ希望っす。
>owaさん
kconvは，デフォルトだと統計情報かなにかを使って文字コードを判定していますよね。ただ，わたしの経験だとたまに「暴れる」ことがあります
文字列が短いくて，かつエンコード情報がない場合，どうしても判別できないケースがでてきてしまうので，仕方がない部分もあると思います
とはいえ，私もあまり深く追っていません(^^;
UTF-8の"もじ化け" はShiftJISとしても正しい文字列なんで、判定は難しいですねぇ。pykfではUTF-8とSJISだとSJISの方を6.25%ほどひいきしますんで、このようなケースではほぼSJISと判定してしまいます。
漢字の第一水準と第二水準で差をつければもうちょっと精度良くなるのかも知れませんが、あまりやる気無かったり。
>> 仕方がない部分もある
鬼門に入ったかも知れないけど、もう少し勉強してみます。unicode() も。
Blog サイトですが、COREBlog をトップに配置しなくても使えることを知りました。
この方面も応用が利きそうなので、とりあえずそっちに行こうかなと思ってます。
UTF-8で"文字化け"はu'\u6587\u5b57\u5316\u3051'ですね。これは，S-JISの"WS0Q"に相当します
これでは，構文解析でもしないと，UTF-8かS-JISか判別できないですね(^^; 構文解析したとしても，後者は./のハンドルにありそうで，いちがいに判別できないかも。。。
文字コードに関してはとりあえず↓こんなところかな。。。
いやはや，お勉強になります;-)
unicode() の件、嘘ついてしまいました。当該マシンに JapaneseCodecs が入ってませんでした。
ごめんなさい _(.".)_
UTF-8の"もじ化け"の判定は難しいのですね。
これから textarea の入力フィルタ作ろうとしてたところなので参考になります。
字種判定、構文解析、パターン...なんか spam フィルタに似て来る。
もっと修行せねばいけないことだけ解かった。