nDiki : UTF8 フラグ

UTF8 フラグ (UTF8 flag (UTF-8 flag))

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) と呼ぶ。

UTF8 フラグが立っているかどうかの確認

  • Encode::is_utf8(STRING, [, CHECK])
  • utf8::is_utf8(STRING)
  • Devel::Peek::Dump の FLAGS 情報

等を使用する。

関連ドキュメント

  • perldoc perlunicode
  • perldoc perluniintro
  • perldoc Encode
  • perldoc utf8 (このドキュメントでは UTF8 flag と UTF-8 flag という用語が混在している)
  • perldoc perlunifqa

スポンサード リンク

2004年2月3日 (火)

[WiKicker] WiKicker の文字化け対応

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 という呼び名はないのかな?

スポンサード リンク
[ 2月3日全て ]

2004年5月19日 (水)

YAML Perl モジュール

データファイルをYAMLで扱おうと思い、YAML Perl モジュール (0.35)でちょこちょこと実験。

日本語がことごとく quote される。

ある 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 をインラインで

短い sequence は

 - a
 - b
 - c

ではなく

 [a, b, c]

の形式で出して欲しい。YAML.pm のチェックしたところ

 my $y = YAML->new;
 $y->InlineSeries(5);
 print $y->dump($data);

のようにインラインにしてよい上限の個数を指定すればよいことを知る。


[ UTF8 フラグ ]

[ 5月19日全て ]

2004年10月29日 (金)

Template ToolkitUTF-8 なファイルを INCLUDE すると文字化け

"UTF8" flag に起因する既知の問題のようだ。

Perl 5.8.4 において Template Toolkit 2.14 だと化けるが、2.13 以前 (2.13 と 2.10 で確認)だと大丈夫。

Template::Providerを継承して UTF8 フラグまわりの処理をする自前の Provider を作ってそれを使うという手もあるようだが、今回は 2.13 を使う事で対処。

[ 10月29日全て ]

2004年11月3日 (水)

Template Toolkit 2.14 の UNICODE パラメータ

Template ToolkitUTF-8 なファイルを INCLUDE すると文字化けする問題だが、ソースを読んでみると Template::Provider に UNICODE という undocumented な初期化パラメータを発見。

Template (か Template::Provider) を new するときに UNICODE => 0 すれば化けなくなった。 "UTF8" flag を立てないで文字列を扱っているスクリプトはこれでOKか?

[ 11月3日全て ]

2005年9月13日 (火)

[ WiKicker ] hell mode - HTMLタグ付けブロックの導入

WiKicker では、直接 WikiPageHTMLタグを記述して表示に反映させる機能を提供していない。

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-8UTF8 フラグなし)でも問題ないようだし、文法的に正しくなくてもきちんとサニタイズできているようだ。

ということで、これを採用することに。

どの要素・属性を許すかはまだきちんと決めかねる。 当面は様子をみながら、調整していく予定。 サニタイザは設置者が置き換えられるようにプラガブルにしておかねばならないな。

[ 9月13日全て ]

2014年2月19日 (水)

いよいよ WiKicker から WikiEngine のコードを抜いて DiKicker のみにする

2002年10月19日から開発を始めてしばらく公開・運用をしていた WikiEngine だけれど最近は WikiEngine そのものは使っていなくて、今はそのコードをベースに作った日記システムDiKicker 部分しか使っていない。DiKicker の方は自分自身で今後も使っていくんだけれど、さすがにいろいろ古いのでそろそろ大改修しようかなと。基盤部分的には

  • Perl 5.005_03Perl 5.6 系との互換処理を捨てる。
  • 文字列処理をバイナリ文字列ベースから(いわゆる UTF8 フラグ界隈的な)テキスト文字列ベースにする。
  • CGI.pm ベースから PSGI ベースへ移行する。
  • 中間管理用のストレージを Berkeley DB から SQLite にする。

などをして今後も使っていけるようにしたい。既に使っていないアプリケーションとしての WikiEngine 部分は移行させていく手間をかける必要はないと思うので、コードを削除していくことにした。WikiForum 立てるなら既にいろいろ他の選択肢があるしね。

CVS での管理もやめて Git 管理に変更。最後の公開 tarball を展開して git init して最初のコミットとし、その後に変更した作業ディレクトリを Git 側の作業ツリーに上乗せしていったんコミット。あらためて最後の公開コードの上に差分を積んでいくつもり。

[ 2月19日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.052305s / load averages: 1.03, 0.62, 0.44
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker