TOKUHIROM MEMO

 | 

2009-06-12

utf8 things 08:30

http://subtech.g.hatena.ne.jp/cho45/comment?date=20090612#c

dan さんがつっこむとおもうので、裏の日記でこっそりと感想メモ

encode/decode の覚えかた

(いつも適当にどっちかやって is_utf8 ダンプするハメになる。perldoc utf8 みてもわからない)

encode は「Perlの内部表現からなにかのエンコーディングエンコードする」

decodeは「なにかのエンコーディングからPerlの内部表現にデコードする」

ってこと。

ある文字列 (サブルーチンの返り値とか) が utf8 flagged かどうかわからないときどうすればいいか

誰がその文字列の状態に責任を持ってるのか

誰かが責任をはたせていない場合にできることは?

自分はどこまで責任を持てばいいのか

実際問題これってよくあると思うんだけど……

入出力をするライブラリ責任をもてばよくて、それ以外のライブラリフラッグの有無を気にする必要はない。DBI とか File related とか、そういうのだけが気にするべき。

use utf8 の意味

フラグが立ったり立たなかったりするのは混乱する

use utf8 せずに全部に utf8::decode すべきなんじゃ?

use utf8 は、「このスクリプトは utf8 でかいてますよ」という宣言になっている。フラッグ存在意識したら負け。

全く utf8 フラグ考慮してない場合にどうなるか

海外製のだいたいの CPAN ライブラリのこと

複雑奇怪な問題を全ての人が「知っている」ことを前提にするのは間違いだと思う

上記責任の問題もあるのだけど、他人が果たせない責任を果たすことはよくあることなのだから、そういうことが確実にできるようでないと使えない。

海外製の CPAN モジュールでもメジャーなものは utf8 フラッグ意識して開発されている。逆にいうと今時 utf8 flag 関連で問題がおきるモジュールは使わない方がいい(というのはたぶん、いいすぎ)。

正規表現マッチを正しくさせるには?

正規表現エンコーディングは?

use utf8; していれば、その regexp は utf8 でマッチしてくれる。regexpstring も両方 flagged にしておくのがポイント

普通に開発していて latin-1 が必要になることはあるのか?

ライブラリの返り値でそうなることがあるとか?

decode を明示的にしてない文字列はすべて latin-1 扱いになる。これは下位互換のため。

latin-1 と byte 列はちがうのか?

utf8 文字列 / latin-1 文字列 / バイト列 ?

用語の問題ですね。バイト列とlatin-1文字列は同じものですね。バイト列という表現は python から輸入してきたものかとおもいます。

なんでこんな複雑なのか

下位互換性、というのはわかる、けど、

慣れてしまえばそんなに問題にならないんですけどね。

ゲスト



トラックバック - http://tokuhirom.g.hatena.ne.jp/tokuhirom/20090612
 |