Perl におけるテキスト文字列 (text strings)*1の内部形式(internal format)が UTF-8 になっているかどうかを表すために使われるフラグ。
テキスト文字列(text strings)で常に立っているとは限らないので注意。内部形式が Latin-1(または EBCDIC) なテキスト文字列もあり得る。
内部形式が Latin-1(または EBCDIC)なテキスト文字列の内部形式を UTF-8 にし UTF8 フラグを立てるには utf8::upgrade() を使う。既に UTF8 フラグが立っている場合は無視してくれる。
sv.h で SVf_UTF8 という名前のマクロで定義されており、値(ビット)は 0x20000000 である。
*1オクテット列として扱う文字列はバイナリ文字列 (binary strings) と呼ぶ。
等を使用する。
WiKicker の文字化けであるが Perl 5.6.x という環境が怪しそう。 ということで、ローカルに Perl 5.6.2 を入れてテスト。
tar zxvf perl-5.6.2.tar.gz cd perl-5.6.2 rm -f config.sh Policy.sh sh Configure -de -Dprefix=/usr/local/perl-5.6.2 make make test make install
で /usr/local/perl-5.6.2/bin/perl -MCPAN -e shell でもりもり必要なモジュールをインストール。
で WiKicker のテスト。化けた。 追いかけてみると、Locale::Maketext モジュールが use utf-8 をしているため、l10n した文字列は UTF-8 として mark されてしまっているようだ*1。 で、mark されていない他の部分の(バイト列としてのUTF-8)文字列と結合したりしたところで化けたと。
ということで、Perl 5.6.x では maketext で帰ってきた文字列の UTF-8 mark を外すようにする。
if (5.006 <= $] && $] < 5.7) { return eval "no utf8; my \$tmp = \$language_handle->maketext(\@param); \$tmp =~ /^(.*)\$/; \$1"; }
という緊急処置コード。 Perl 5.005_03 では utf8 プラグマ自体が無いので、eval の中に入れておく。 v5.6.x での UTF-8 mark の外し方が良くわからないので、とりあえず正規表現に全マッチさせるというダサいコード(v5.8 だと utf8::* にそこら辺の関数があるのだが)。
*1Perl 5.6.x では Perl 5.8.x のように "UTF8" flag という呼び名はないのかな?
データファイルをYAMLで扱おうと思い、YAML Perl モジュール (0.35)でちょこちょこと実験。
ある UTF-8 で書かれたファイルを読み込んで YAMLで Dump したら、日本語の部分がことごとく quote される。 これはいただけない。
my $ESCAPE_CHAR = '[\\x00-\\x08\\x0b-\\x0d\\x0e-\\x1f]';
で判別している。手抜きではないか。 さてどうしたものか。
と考えていたら、よく考えたら Perl 5.8.x だとバイト単位ではなく文字単位で正規表現マッチングさせられるんだったことを思い出した。 手抜きだなんて思って失礼しました。
データファイルを読んで utf8::decode してから YAML で Dump するようにしたらクオートされなくなった。Good.
Perl 5.6 系だとどうすればいいんだろ。 YAML.pm を直接書き換えて
use utf8;
を追加すれば期待通りにはなるのだが、ちょっと嫌だな。
短い sequence は
- a - b - c
ではなく
[a, b, c]
の形式で出して欲しい。YAML.pm のチェックしたところ
my $y = YAML->new; $y->InlineSeries(5); print $y->dump($data);
のようにインラインにしてよい上限の個数を指定すればよいことを知る。
[ UTF8 フラグ ]
"UTF8" flag に起因する既知の問題のようだ。
Perl 5.8.4 において Template Toolkit 2.14 だと化けるが、2.13 以前 (2.13 と 2.10 で確認)だと大丈夫。
Template::Providerを継承して UTF8 フラグまわりの処理をする自前の Provider を作ってそれを使うという手もあるようだが、今回は 2.13 を使う事で対処。
Template Toolkit で UTF-8 なファイルを INCLUDE すると文字化けする問題だが、ソースを読んでみると Template::Provider に UNICODE という undocumented な初期化パラメータを発見。
Template (か Template::Provider) を new するときに UNICODE => 0 すれば化けなくなった。 "UTF8" flag を立てないで文字列を扱っているスクリプトはこれでOKか?
WiKicker では、直接 WikiPage にHTMLタグを記述して表示に反映させる機能を提供していない。
HTMLタグ付けを許すと
が起きやすくなるし、ページのソースの単純さが大きく失われてしまう。 レンダリングしてHTMLにした時に、正しいHTMLを出力されることを保証することが困難になるとともに、HTML以外へのレンダリング/コンバートもかなり難しくなる。
この機能を導入すると、Wiki の良さの半分(あるいはもうちょっと沢山か、もうちょっと少なめ)が失われてしまう。
とはいえ欲しいという声があることも事実。 オープンな WikiForum では全くお勧めできないが、閉じたユーザグループの中ではまぁ必要悪なのかもしれぬ。
また正直ちょっとした表現を追加したい時に、WiKicker 用のプラグインを書くのも面倒だというのは確かにある。
WiKicker では開始・終了マーカによる複数行にまたがるブロックを表すための文法は(閉じ忘れを避けるため)意図的に排除してある。 このため、複数行にわけて書きたいような長いデータを扱うような拡張も導入しにくい。
ちょっと手抜きして「生HTML書けちゃえば」という誘惑はなくはない。
ということでまあ自分に言い訳をしつつ、標準ではオフというかたちで HTMLタグ付けブロックを導入することにした。 スイッチは hell mode とかにしたい (今回は syntax.html というプロパティ名にしたけれど)。
記法は単純に、
normal wiki syntax text... <html> html tagged text... ... </html> normal wiki syntax text...
のように行頭が <html> である行から、行頭が </html>である行までをHTMLタグ付けブロックとすることに。 このため、<html>ではじまる段落が書けなくなるという小さな非互換が発生するが、いたしかたない。
HTMLタグを直接使えるようにするとはいえ、全てを許してしまうのはあまりに危険で非人道的すぎる。 有効なHTMLタグや属性は限定的であるべきだ。
このあたりの処理は面倒だが、幸いにしてCPANにモジュールがある。 今回は HTML::Scrubber を使うことにした。 HTML::Parserを使って parse し、指定したルールに従ってサニタイズしてくれる。
ちょっと使ってみた範囲では日本語(UTF-8、UTF8 フラグなし)でも問題ないようだし、文法的に正しくなくてもきちんとサニタイズできているようだ。
ということで、これを採用することに。
どの要素・属性を許すかはまだきちんと決めかねる。 当面は様子をみながら、調整していく予定。 サニタイザは設置者が置き換えられるようにプラガブルにしておかねばならないな。
2002年10月19日から開発を始めてしばらく公開・運用をしていた WikiEngine だけれど最近は WikiEngine そのものは使っていなくて、今はそのコードをベースに作った日記システム の DiKicker 部分しか使っていない。DiKicker の方は自分自身で今後も使っていくんだけれど、さすがにいろいろ古いのでそろそろ大改修しようかなと。基盤部分的には
などをして今後も使っていけるようにしたい。既に使っていないアプリケーションとしての WikiEngine 部分は移行させていく手間をかける必要はないと思うので、コードを削除していくことにした。WikiForum 立てるなら既にいろいろ他の選択肢があるしね。
CVS での管理もやめて Git 管理に変更。最後の公開 tarball を展開して git init して最初のコミットとし、その後に変更した作業ディレクトリを Git 側の作業ツリーに上乗せしていったんコミット。あらためて最後の公開コードの上に差分を積んでいくつもり。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。