Bulknews::Subtech RSSフィード

2009/04/08 (水)

DBD::SQLite 1.22_01 と Unicode 16:22  DBD::SQLite 1.22_01 と Unicode - Bulknews::Subtech を含むブックマーク はてなブックマーク -  DBD::SQLite 1.22_01 と Unicode - Bulknews::Subtech

Encountered a 404 error に書いた通りだけど、DBD::SQLite で $dbh->{unicode} オプションをつけたとき、UTF-8 フラグがついていない文字列を渡したときの挙動を変更しました。CPAN に 1.22_01 dev release としてアップロードされてます。

具体的には、いままでは、その文字列の内部エンコーディング(UTF-8 フラグがついてるかどうかにかかわらず)をそのまま保存していて latin-1 の文字列など UTF-8 的に正しくないシーケンスがきたときに DB に壊れた値が入るという問題があったのを、utf8::upgrade を内部的に呼んで、確実に UTF-8 エンコーディングになるようにしました。

もっと日本人のPerlプログラマ的にわかりやすく言うと、UTF-8 な文字列を渡すときはdecode した状態でわたせ、さもなくば二重エンコードになって文字化けするよ、ということです。

これは DBD::SQLite の POD にもずっと書いてあった(unicode オプションのときは文字列は UTF8 フラグつきでやりとりするよ)のだけど、フラグなしで渡したときの動作がドキュメントと食い違っていて latin-1 文字列でバグが起きていました。

これで DBD::mysql の mysql_enable_utf8 とも動作は同じになりますが、以前の(正しくない)動作に依存しているアプリケーションは動かなくなるかもしれません。

具体的に言うと、ちょっと前の Remedie では JSON 文字列をカラムに保存するのに JSON::XS->new->utf8->encode を利用していたので、このパッチがあたった DBD::SQLite では二重エンコードで文字化けしてしまいました。->utf8 オプションを外すか、現在の Remedie のように ->ascii としてそもそも変換を回避するように変更すれば、現状版でもパッチがあたっていてもどちらでも動きます。

というわけで、http://search.cpan.org/~adamk/DBD-SQLite-1.22_01/ にあがっているのでテストよろしく。