nDiki : UTF-8

UTF-8

UCS transformation formats の一つ。

RFC3629 (← RFC2279 ← RFC2044)

2005年9月13日 (火)

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

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

@ HTMLタグ付けを許すのは嫌だ

HTMLタグ付けを許すと

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

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

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

スポンサードリンク

[ permalink ]

Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
[ WiKicker ] form/list の paragraph から... (2003-05-03)
Wikiの文法の標準化 (2004-02-10)
[ WiKicker ] WiKicker へ脚注機能追加 (2004-02-10)

[ 9月13日全て ]

2006年1月22日 (日)

■ amaroK で Linux 上の iTunes 音楽データを聞く

昨日 mt-daapd で Linux BOX を iTunes サーバにしたててみた。しかしサーバにするだけではつまらない。もちろんそのPCでも再生できるようにしておきたい。

xmms で AAC形式の音楽を再生できることはできるのだが、UTF-8 なファイル名のファイルの扱いがよろしくない。xmms-shell から操作すれば日本語も扱えるがあまりにも寂しすぎる。

ということでプレーヤーを物色。

@ プレーヤーいろいろ

amaroK 1.3.8: KDE 系。見た目も格好良いし、機能としては充分。
JuK 2.3: KDE 系。KDE 系ということで見た目は良い。しかし、試したところうまく AAC形式ファイルを指定できなかった。
Rhythmbox 0.9.2: GNOME 系。AAC形式 OK。日本語タグもきちんと表示する。再生機能はシンプル。
gtkpod 0.99.2: AAC 形式 OK。日本語タグもきちんと表示する。再生機能は xmms まかせ。

@ amaroK スナップショットをビルドする

この中では amaroK が一番気にいった。しかし残念ながら安定版(1.3.8)ではまだ、AAC形式ファイルの中のタグに対応していないという問題がある。惜しい。

最新のスナップショットでは対応できているとの事なのでビルドしてしまうことにした。

/usr/local/amaroK-svn 以下にインストールすることにする。

 apt-get build-dep amarok
 svn co -N svn://anonsvn.kde.org/home/kde/trunk/extragear/multimedia
 cd multimedia
 svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin
 svn up amarok
 make -f Makefile.cvs
 ./configure --enable-debug=full --without-akode --prefix=/usr/local/amaroK-svn
 make
 make install

aKode 関連のコードでコンパイルエラーを起こしたので --without-akode でビルド。

で、起動

 KDEDIRS=/usr/local/amaroK-svn:/usr \
 PATH=/usr/local/amaroK-svn/bin:$PATH \
 /usr/local/amaroK-svn/bin/amarok

動いた動いた。iTunes 6 for Windows で取り込んだ AAC形式ファイルのタグに含まれている日本語タイトル・アーティスト等もきちんと表示された。 Amazon.co.jp からのカバーの取得もうまくいっている。

自分の環境だとなぜかトレイに入らなくなったが、それ以外は問題なし。いいね。

@ 追記

トレイに入らないのは amaroK スナップショットのせいではなく、KDE環境が一時的に変になっているせいであった。一旦 KDE 環境を再起動したらきちんとトレイにはいった (2006年2月23日追記)

[ permalink ]

Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
ActivePerl で Ming (2005-02-23)
Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
TrueCrypt で USB メモリに Windows と Linux ... (2006-12-14)
Linux ノート PCを iTunes サーバにしてみる (2006-01-21)

[ 1月22日全て ]

2006年1月26日 (木)

■ amaroK のプレイリストを mt-daapd で共有する

amaroK のコレクション用ディレクトリと mt-daapd での音楽データディレクトリを同一にしている。

この状態でプレイリスト (.m3u) を作成し同じくこのディレクトリに保存すると、mt-daapd で問題なく公開できた。ファイル名を日本語にしておけば、プレイリスト名もきちんと日本語になる。

mt-daapd の mt-daapd.playlist による動的なプレイリストも、設定ファイルを UTF-8 で書いておけば日本語のプレイリスト名も問題ないようである。

[ permalink ]

amaroK で Linux 上の iTunes 音楽データを聞く (2006-01-22)
Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
WiKicker における PageName 最長文字数 (2006-06-10)
AWStats 6.0 (2004-05-21)
Eclipse 3.0 M9 (2004-05-22)

[ 1月26日全て ]

2006年3月8日 (水)

■ Mule-UCS の設定

reStructuredText では表を作る時は文字数で桁揃えして、表セルを表現していく。 ASCII 文字などフォント幅がいわゆる半角幅であるものだけならば、良いのだが全角幅の文字がある場合はちょっと厄介である。

文字数的には1文字なのだが、プレーンテキストファイル上では2文字分の幅を取るので見た目上桁が揃わなくなってしまう。というかそれを忘れて桁を揃えておくと、パーサに怒られる。

このためにパッチがあったり、Docutil 0.4 ではこの対策がほどこされたりしている(不完全であるが)。

さらに厄介なのが Unicode 変換がからむところで、 Emacs + Mule-UCS ではいくつかの(いわゆる)全角文字は UTF-8 で保存すると違う文字に変換されてしまい、これまた Docutils のパーサに、桁があっていないと怒られることになる。

できるだけ全角文字はそのままにしておくということで、以下の設定を追加しておいた。

 (require 'un-define)
 (un-define-change-charset-order
  (append '(ascii japanese-jisx0208)
          unicode-basic-translation-charset-order-list))

またバックスラシュと円記号の方も混乱が少ないように

 (require 'un-supple)
 (un-supple-enable 'windows)

を追加してく。

[ permalink ]

kterm から mlterm へ (2004-11-26)
Docutils 0.4 の日本語文字対応はまだまだ駄目 (2006-02-07)
Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
日本語ファイル名どんとこい (2005-03-07)

[ 3月8日全て ]

2006年6月10日 (土)

■ WiKicker における PageName 最長文字数

WiKicker では PageName をエンコードした文字列を URI に埋め込んだり、サーバで保存する際のファイル名にしたりしている。このため、PageName の最長文字数はそれらの最長文字数に依存しているはずである。

今まで確認を後回しにしていたのだが、新しい機能の追加の際に確認しておく必要があるので調査してみた。

@ WiKicker の実装

WiKicker の実装がらみとして最長を決める要素としては

PageName の UTF-8 表現を URI エスケープしてページ URI に含めている。→ URI、HTTP、HTML、Web サーバ、Web ブラウザの実装による最長の制約
PageName を base64 にエンコードしてファイル名にしている。→ ファイルシステムのファイル名、パス名の最長の制約

がある。

@ 各仕様等による制約

HTTP では URI の長さには制限なし (RFC2616 3.2.1)
Web サーバは Request-URI が長いと 414 Request-URI Too Long を返す (RFC2616 10.4.15)。Apache は LimitRequestLine ディレクティブにより、URI を含むリクエスト行のサイズを制限することができる(配布時には 8190)。
Internet Explorer が扱える URL の長さは 2083文字。
ext2 はファイル名は 255文字まで(増やすこともできる)。
手元の Linux 2.6.15 で試したところ、パス名は 4095文字まで。

@ WiKicker で問題が出ない PageName 最長文字数

上記の中ではファイル名による制約が一番大きい。

WiKicker 内部でファイル名として base64 (の亜種) でエンコードしたものを使っているので、元の文字列はは最長 189バイトまでなければならない。base64 だと3バイトで4文字になるため、189バイトで 252文字となる。

WiKicker ではここでさらにファイル名に ',v'、'-lock' をつける事があるので、実際には元の文字列は最長 186 バイトまでとなる。

PageName が 186 バイトまでだとすると、URL エスケープしたとして558バイト。 WikiEngine のスクリプトの URL や他のパラメータとあわせても、これぐらいなら大丈夫のはずである。

ということで WiKicker では Linux 上だと通常 PageName は 186 バイトが最長と言ってよさそうだ。日本語の文字はだいたい UTF-8 で3バイトになるので、62 文字までということになる。

そのうち、WiKicker に制約チェックを入れることにしよう。そのうち。

[ permalink ]

Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
WiKicker 実装 (2002-10-20)
WiKicker 0.35 リリース - 添付機能の修正など (2006-06-20)
最後がピリオド(.)で終わるファイル名をつけられない (2005-04-19)
[ WiKicker ] If-Modified-Since: 関連作業ほぼ済 (2003-09-19)

[ 6月10日全て ]

2006年7月22日 (土)

■ Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合

入社してから社内情報共有の一環として

Wiki (WiKicker)
ML アーカイブ公開 (MHonArc)
検索システム (Hyper Estraier)
社内 Blog (DiKicker)

といろいろ手をつけてきた。次に狙っているのは SBS である。

Wiki や社内 Blog に書くほどではないけれどメモ程度にブックマークしておきたい URL を、気軽に晒せるようにするのが目的。

はてなブックマークのような公開サービスは

タグ・コメント・傾向などが外に出るのはよろしくない
あるいは、それを気にして活用されない
そもそも社内リソースについてはブックマークできない

という点から、今回は利用できない。

ということで社内に SBS を設置したい考えている。

最初は Scuttle にしてみようと思ったのだが、PHP ベースであるのと MySQL を使うというところで気遅れしている。いや SQLite でもいけそうらしいということで、実は Debian でちょっと試そうとしたのだが、テーブル作成の SQL が MySQL 用で、これを修正するのが面倒なので断念。

次に Perl + SQLite で動く Rubric を試してみることにした。

@ Rubric 0.140

Rubric は CPAN にあがっているので CPAN.pm から install Rubric でインストールできる。モジュールをインストールしたら、セットアップ。

CGI プログラムを動かすディレクトリを決める (以下 $RUBRIC)
Rubric tarball の bin/rubric.cgi を $RUBRIC/ にコピーし、必要なら #! を修正する。
Rubric tarball の templates ディレクトリを $RUBRIC/ にコピーする。
Rubric tarball の style/rubric.css を $RUBRIC/ にコピーする。
Rubric tarball の etc/rubric.yml を $RUBRIC/ にコピーして環境に合わせて編集する。
データベースを初期化する。0.140 には makedb.pl が同梱されていないので、0.13_01 の bin/makedb.pl を参考に perl -MRubric::DBI::Setup -e 'Rubric::DBI::Setup->setup_tables' で初期化する。ちなみに 0.140 付属の rubric コマンドで rubric db -s してみたが、これはうまく動かなかった。
必要に応じて .htaccess を作成・編集し rubric.cgi を CGI プログラムとして実行できるようにする。またその他アクセスされたくないファイルを deny するようにしておく。

これで OK。

rubric.cgi にアクセスしページが表示されればひとまず成功。メニューの「register」から、ユーザ登録する。確認用のメールが届くはずだが、面倒くさいのでこれを待たずに

 rubric user -a ユーザ名

でアクティベートする。

Rubric の HTML フォームからのブックマーキングは成功し、うまく動いているようである。ただし、日本語の処理はどうもよくない。 title や description が化ける。惜しい。

基本的には UTF-8 ベースでうまくいきそうなのだが、どこかで化けるようだ。ちょっと手を入れれば直るかなと思ったが、化けるところと化けないところとがあるので逆に直す場所が多そうなので今日はやめておくことにした。

とりあえず Rubric はおいておいて、他のものも試してみることにするか。

[ permalink ]

Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)
Hyper Estraier で社内 Web コンテンツ検索 (2006-06-01)
Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
DiKicker の出力する HTML コードを小さく (2006-10-05)

[ 7月22日全て ]

2006年10月5日 (木)

■ DiKicker の出力する HTML コードを小さく

容量超過につき www.naney.org の容量削減中。

中でも結構な容量を食っているのが、nDiki (DiKicker) の HTML 変換済み記事データベースである。毎回レンダリングし直すと遅いので、1度 HTML フラグメントに変換したら Bereley DB ファイルに保存しているのだが、これがどうしても大きくなってしまうのである。

NaneyOrgWiki (WiKicker) もそうなのだが、 UTF-8 を使用しているため日本語中心のテキストが思った以上にデカくなるのも痛い。

ということで生成する HTML フラグメントをちまちま小さくするようにすることにした。チェックしてみると自動リンクの URL が絶対 URL になっているではないか。まずはこれを短い URL を吐くように書き直し。

焼け石に水な感もあるが、ちょっとずつでも短くしていきたい。

[ permalink ]

Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
Twitter ステータスを nDiki サイドバーに表示 (2007-11-09)
WiKicker における PageName 最長文字数 (2006-06-10)
[ Perl ] Log::Log4perlのはまりどころ (2004-03-02)
[ WiKicker ] spam と検索エンジン対応に noindex、... (2007-01-13)

[ 10月5日全て ]

2006年12月14日 (木)

■ TrueCrypt で USB メモリに Windows と Linux からアクセスできる仮想暗号化ドライブを

USB メモリといえば、他人の PC とデータをやりとりする際によく使われるメディアだ。

最近どんどん大容量化していることもあり、ついいろいろなデータを入れっぱなしにしがち。

「ファイルをもらうのに渡した USB メモリを、受け取って確認したら見られたくなかったファイルが入ったままだった。」
「USB メモリにファイル入れて渡すのだけれど、今入っている見られたくないファイルを消すの面倒だな。後でまた入れておきたいし。」
「紛失した時が心配」

など、そのまま入れておくのは不安なファイルもある。

ということでやっぱりいくつかのファイルは暗号化しておきたい。さて何かよい暗号化ソフトウェアはないだろうか。

Windows でも Linux でも使えること。
データをやりとりする可能性のあるグループごとに別の領域を用意できること。
暗号化ソフトウェアをインストールしていない Windows PC からでも、ファイルを取り出せること (インストール不要で復号できるソフトウェアを USB メモリに一緒に入れておけること)。

で調べたところ TrueCrypt が有名らしい。Windows と Linux の両方から使えるというのが良い。

ということで試してみた。

@ Linux 版

ライセンスの関係で Debian GNU/Linux には無いので、ビルドしてインストールする。

@ ビルド

まずはビルド。

 tar zxvf truecrypt-4.2a-source-code.tar.gz
 cd truecrypt-4.2a/Linux
 fakeroot ./build.sh

@ インストール

次にインストール。apt-get install dmsetup してから ./install.sh を実行する。

 # ./install.sh
 Checking installation requirements...
 Testing truecrypt... Done.

 Install binaries to [/usr/bin]:
 Install man page to [/usr/share/man]:
 Install user guide and kernel module to [/usr/share/truecrypt]:
 Allow non-admin users to run TrueCrypt [y/N]: y
 Installing kernel module... Done.
 Installing truecrypt to /usr/bin... Done.
 Installing man page to /usr/share/man/man1... Done.
 Installing user guide to /usr/share/truecrypt/doc... Done.
 Installing backup kernel module to /usr/share/truecrypt/kernel... Done.

@ 仮想ドライブボリュームファイルを作成

ここからは実際の利用。まず最初にボリュームファイルを作成する。

 $ truecrypt -c vol.tc
 Volume type:
  1) Normal
  2) Hidden
 Select [1]:

 Filesystem:
  1) FAT
  2) None
 Select [1]:

 Enter volume size (bytes - size/sizeK/sizeM/sizeG): 128M

 Hash algorithm:
  1) RIPEMD-160
  2) SHA-1
  3) Whirlpool
 Select [1]:

 Encryption algorithm:
  1) AES
  2) Blowfish
  3) CAST5
  4) Serpent
  5) Triple DES
  6) Twofish
  7) AES-Twofish
  8) AES-Twofish-Serpent
  9) Serpent-AES
 10) Serpent-Twofish-AES
 11) Twofish-Serpent
 Select [1]:

 Enter password for new volume 'vol.tc':
 Re-enter password:

 Enter keyfile path [none]:

 TrueCrypt will now collect random data.

 Is your mouse connected directly to computer where TrueCrypt is running? [Y/n]:

 Please move the mouse randomly until the required amount of data is captured...
 Mouse data captured: 100%

 Done: 125.85 MB  Speed: 15.66 MB/s  Left: 0:00:00
 Volume created.

基本的にはデフォルトで OK。確保容量とパスワードはそれぞれ決めて入力する。

@ 仮想ドライブをマウントしてみる

マウントポイントを作成してマウントする。自分の場合ロケールを ja_JP.UTF-8 にしているので、日本語ファイル名を読み書きするために -M utf8 しておく必要がある。

 cd
 mkdir mnt
 truecrypt -M utf8,fmask=133 -u vol.tc mnt         # マウント
 Enter password for '/home/naney/vol.tc': # パスワード入力

マウントができたら後は普通に読み書きができる。読み書きが終わったら、truecrypt -d でアンマウント。

 truecrypt -l         # マウントされているもののリスト
 truecrypt -d mnt     # アンマウント

@ Windows 版

Windows 版は truecrypt-4.2a.zip を展開して、中に含まれているインストーラを使ってインストール。

TrueCrypt を起動して、先ほど作成したボリュームファイルとつけたいドライブ名を指定してマウントすると、うまく中身を読み書きすることができた。

@ トラベラーモード

また TrueCrypt にはトラベラーモードというものがある。メニューから [Tools] -> [Traveller Disk Setup] を実行して、指定したいメディア(ディレクトリ)に、インストールせずに実行するのに必要なファイル群を配置することができる(オプションで autorun.inf を作ることも可能)。

これを実行して USB メモリに TrueCrypt を入れておけば、TrueCrypt をインストールしていない Windows PC 上でも TrueCrypt をトラベラーモードで実行してマウントできるようになる (ただし、管理者権限が必要)。

@ これから

母艦である Linux BOX からアクセスできるというのが便利。 Linux BOX に USB メモリを挿した後、truecrypt でマウントして Unison で同期してアンマウントまでの一連の処理を流れ作業でできるようにしたい。

[ permalink ]

xyzzyを読み取り専用メディアから起動する (2004-07-28)
Unison + Zebedee (2004-06-11)
Windows でも Linux でも動くタスク管理ツール Task Coach (2006-01-12)
Linux で入力して Windows で参照できるパスワード管理ツール ... (2006-12-31)
amaroK で Linux 上の iTunes 音楽データを聞く (2006-01-22)

[ 12月14日全て ]

2007年12月29日 (土)

■ Twitter ベイジアンフィルタプロキシ

Twitter で following が増えてくるにつれて、タイムラインに目を通すのが大変になってきた(という程きちんと見ている訳ではないが)。さっとタイムラインをなめて面白そうな情報をピックアップしたい時は、「おはよう」とか「風呂入った」とか「トイレ」とかは除外して読みたい(そういう書き込み自体は嫌いじゃないのだが、人生はあまりにも短い)。

Twit や P3:PeraPeraPrv では NG ワード指定ができて、それらを含むステータスは表示しないようにできるのだが、Twitter の書き込みは揺らぎが激しすぎて指定しきれないという弱点がる。

ということでベイジアンフィルタでフィルタリングしてみることにした。

自前で Twitter クライアントを作る気はないので、proxy の形でさっと実装してみた。

 #!/usr/bin/perl

 use strict;
 use warnings;

 use HTTP::Proxy;
 use HTTP::Proxy::BodyFilter::complete;

 my $proxy = HTTP::Proxy->new(port => 8088);
 $proxy->push_filter(response => HTTP::Proxy::BodyFilter::complete->new,
                     mime     => 'application/xml');
 $proxy->push_filter(response => Bsfilter->new,
                     mime     => 'application/xml');
 $proxy->start;

 {

   package Bsfilter;

   use File::Temp qw/tempfile/;
   use XML::XPath;
   use base qw(HTTP::Proxy::BodyFilter);

   sub filter {
     my ($self, $dataref, $message, $protocol, $buffer) = @_;
     return unless defined($$dataref) && $$dataref ne '';
     eval {
       my $xml = XML::XPath->new(xml => $$dataref);
       my @nodes = $xml->findnodes('/statuses/status/text/text()');
       return unless @nodes;
       for my $node (@nodes) {
         my $text = $node->getNodeValue;
         if (is_NG($text)) {
           $node->setNodeValue("[NG] $text");
         }
       }
       $$dataref = qq(<?xml version="1.0" encoding="UTF-8"?>\n);
       $$dataref .= $xml->get_context->toString;
       utf8::encode($$dataref);
     };
     if ($@) {
       warn $@;
     }
   }

   sub will_modify { 1 }

   sub is_NG {
     my ($text) = @_;

     my ($fh, $filename) = tempfile();
     utf8::encode($text);
     print $fh $text;
     close($fh);
     my $result
       = system(
       "bsfilter --homedir ~/.twitter-bsfilter --ignore-header --auto-update $filename"
       );
     unlink($filename);

     return !$result;
   }
 }

@ HTTP proxy の作成

Perl で HTTP proxy を作ろうとして真っ先に思い浮かんだのは POE だけれど、ちょっとヘビーなので今回は HTTP::Proxy をチョイス。もともとフィルタリング HTTP proxy を作ることを念頭に置いた Perl モジュールなので今回の目的にぴったり。

1つはまった点といえば、filter の呼び出しがレスポンス全てを取得してからではなく一部分ずつの呼び出しになるところ。その仕様に気がつくのにちょっと時間がかかってしまった。例えば XML 形式のレスポンスをフィルタしようとしても、普通に HTTP::Proxy を使うと XML の一部ずつがフィルタに渡されるため、XML のパースがうまくいかない。

これについては HTTP::Proxy::BodyFilter::complete を使うことで、まとめてフィルタに渡せるようになった。

@ レスポンスの処理

Twitter のタイムライン取得については P3:PeraPeraPrv が XML 形式で取得しているので、そのタイプのレスポンスをフィルタするようにした。

XML::XPath でステータス部分を抜き出して NG 判定し、NG であれば先頭に [NG] を追加する。これで Twitter クライアント側で [NG] を NG ワード指定すれば、表示されないようにすることができる。

@ bsfilter による NG 判定

NG 判定は普段メールの spam フィルタとして使っている bsfilter を使った。単純に system 関数で呼び出して結果を取得するだけ。

今回は対象がメールではないので --ignore-header を指定。また自動的に学習するように --auto-update を指定。それと普段メールのフィルタリングに使っているのとは bsfilter のデータベースを別にしたいので、--homedir も指定しておく。

@ NG と非 NG の学習。

NG ワードを twitter-NG.txt に、非 NG ワードを twitter-clean.txt に書いて以下のコマンドを実行。

 bsfilter --add-clean --ignore-header --homedir ~/.twitter-bsfilter twitter-clean.txt
 bsfilter --add-spam --ignore-header --homedir ~/.twitter-bsfilter twitter-NG.txt
 bsfilter --update --homedir ~/.twitter-bsfilter

自分の環境 (Debian GNU/Linux sid)では、UTF-8 で書いておいて問題なかった。

@ フィルタリングしてみる

あとは先の proxy を起動し、P3:PeraPeraPrv でプロキシとして localhost:8088 を指定すれば OK。

タイムラインを取得するたびに bsfilter が動いて NG なステータスには [NG] が挿入される。

@ フィルタリングの精度

これについては、まだまだチューンの必要ありかな。

事前の学習データが少ない。
--auto-update していることもあり、最初に NG 判定が多いとそちら側に強化されすぎる。
毎回 bsfilter を呼んでいるため、同じステータスが何度も学習される。

まだ使える精度まで上がってないけれど、教師データを増やせばそれなりにいけるかもしれない。

proxy の枠組ができたので、(@～は抜いてから bsfilter に渡すとか、前後の文脈も含めるとか)いろいろ試して遊べそうではある。別に bsfilter にこだわらず、正規表現による判定などをしてもよいし。

この辺り P3 は Java で書かれているので、プラグインを書いて拡張できるよう将来になると面白いなと思ってみたり。

[ permalink ]

今日のさえずり - スーツに着た回数を記録する仕組みが欲しい (2007-12-24)
今日のさえずり - 100g 減る前にアタック買いだめ (2008-05-28)
今日のさえずり - Twitter 日本語表示みた (2008-04-23)
POE で HTTP プロキシサーバ (2005-10-15)
reStructuredText いいんじゃない? (2005-11-22)

[ 12月29日全て ]

2008年1月7日 (月)

■ ケータイ用にプライベート Wiki を設置

パケ・ホーダイを契約してから、MovaTwitter・RTM・モバイル Gmail などで携帯電話を活用するようになった。そんななか、決定打がないのが、ノートアプリケーション。電車の中などの隙間時間に、この nDiki の下書きなどはケータイでできるようにしたい。

Google ドキュメントが使えればいいが、前年ながらまだiモードでは使えない。メールベースでやる手もあるが、メモには良いものの再編集を繰り返したいようなものに難がある。

ということで自前でプライベート Wiki を立てそこに書き込んでみることにした。

@ iモードから WiKicker

使う WikiEngine はいつも通り自作の WiKicker。

書き込んだテキスト内のキーワードを nDiki へ自動リンクさせることができるので、パーソナルナレッジベースとして自分にとっては一番便利。書式も同じなので、Wiki に書いた下書きを、そのまま nDiki で使える。

肝心のケータイからの書き込みだが Ajax 等凝った技術を使っていないおかげで、問題なく FOMA 端末(D703i)からiモードで読み書きできた。WiKicker は UTF-8 でページを出力しているが、網側か端末側の処理かは知らないが今のところ問題なし。

なお認証は簡単に Basic 認証で済ますことにした。安全とは言えないがそれほど重要なデータを置くわけではないしいいかな。 cookie は必要ないし WikiEngine に手を入れなくてもよいので、すぐできるのはコレ。

ユーザ名とパスワード付きのトップページ URL を端末でブックマークしておけば1発でアクセスできる。

@ Google Mobile Proxy 経由で使う

これでケータイ(と PC)から使えるプライベート Wiki を設置できたわけだが、なにぶんもともとケータイをサポートしている WikiEngine ではないため、長いページの分割機能などはないのがちょっと不安。PageName で生成される URL が長くなった時の振る舞いもちょっと不安。

そこで Google Mobile Proxy (http://www.google.co.jp/gwt/n) 経由で Wiki を使うことにした。ページを携帯端末向けに変換してくれる proxy で、Basic 認証もできるしフォームの POST もできる。

Google Mobile Proxy 経由で見たページ内のリンク先も全て自動的に proxy 経由になるので、 PC 向け Web ページの URL を書いておけばそのまま携帯電話で見ることができる。

安全のためか、比較的短い一定時間立つと認証の再確認画面が表示されてしまうが、ユーザ名とパスワードを入力すれば、セッションは継続される。テキスト編集に時間がかかってしまうと POST する時にひっかかってしまい認証の再入力がちょっと面倒だが、再認証が通れば POST リクエスト自体は有効で書き込みがロストすることはないようだ。

しばらくはこれで読み書きしてみよう。

[ permalink ]

[ 1月7日全て ]

Related web page

UTF-8 エンコーディングの危険性 - WebOS Goodies

昨日の記事で公開した Ruby 用の JSON パーサーに UTF-8 の検証機能を追加しましたが、本日はこれについて少し補足説明しようと思います。 UTF-8 は比較的扱いやすいエンコーディングですが、単純にデコードすると ASCII コードと同じ値になってしまうマルチバイトコードが存在するため、注意が必要です。文字エンコーディングについて詳しい方には当たり前のことかもしれません
http://webos-goodies.jp/archives/51072404.html

Uno, dos, tres, quatro!UTF-8で動かすgrepは遅い

IRCでおもしろい話があったので試してみました。タイトルの通り、LC_CTYPE=*.UTF-8の場合にgrepを動作させると遅いというのです。というわけで、IRCのログから"それPla"という文字列の検索を、LC_CTYPE=en_US.UTF-8の場合とLC_CTYPE=Cの場合の2通りでやってみました。結果 % export LC_CTYPE=en_US.UTF-8 % grep それPla *.txt > /dev/null real 0m53.583s user 0m22.545s sys 0m0.416s % export LC_CTYPE=C % grep それPla *.txt > /d
http://blog.33rpm.jp/speed-up-grep.html

UTF-8 による TeX 文書の作成

日本語混在の多言語 TeX 文書を作成する場合，いちばん困ることはロシア語，フランス語などの非 ASCII コードの言語をすべて ASCII コードで表現せざるをえないことである． "Я люблю вас." というロシア語は，ローマントランスクリプションによって，"YA lyublyu vas." となどと記述する．同様にフランス語 "Ça, déjeunons!" は "\c{C}a, d\'{e}jeunons!" と．これでは面倒だし，直感的でない
http://yasuda.homeip.net/tex/utf82tex.html

404 Blog Not Found:UTF-8 vs. ISO-10646

これだとLiberalなUTF-8ですね。 [を] UTF-8 の文字にマッチする正規表現UTF-8の文字にマッチする正規表現の素直版。
http://blog.livedoor.jp/dankogai/archives/50410033.html

404 Blog Not Found:追記: UTF-8 vs. ISO-10646

文字集合(Character Set)と符号化(Encoding)について、より適切な表現と追補すべきネタがあったのでEntry quinta essentia - Character Set vs. Encodingとなって、U+7FFFFFFF まで許すという話もあって、ややこしさが増す。
http://blog.livedoor.jp/dankogai/archives/50276188.html

use encoding 'utf-8' & encoding::warnings: blog.bulknews.net

たしかに内部的に UTF-8 フラグを落としてバリバリつなげちゃえば、場当たり的に楽は楽なんだけど、内部的に Unicode フラグをもったまま処理して、最後に出力するときに落とす（encode する）というのが正当なわけです。また、Unicode flagged + non-Unicode flagged な処理を行ったときに warning もしくは例外をとばすプラグマ encoding::warnings なんてのもありますし（実験的なのでプロダクシ
http://blog.bulknews.net/mt/archives/001819.html

いやなブログ: UTF-8 のオクテット数

UTF-8 で表現した 1文字は最長で 6オクテット (バイト) と思っていたのですが、新しい方の RFC では 4 オクテットまでとなっているのを知りました。...
http://namazu.org/~satoru/blog/archives/000049.html

404 Blog Not Found:UTF-8 Flagを落とそうとして思わぬBugを見つけた話

これじゃ、駄目。 UTF-8 フラグと戦う人へ - にぽたん研究所UTF-8 フラグがどうもウザいという人向けにこんな CPAN モジュールがあるそうな。 Unicode::RecursiveDowngrade
http://blog.livedoor.jp/dankogai/archives/50097405.html

UTF-8 フラグと戦う人へ - にぽたん研究所

ひさびさに Blog を書いてみる。 UTF-8 フラグがどうもウザいという人向けにこんな CPAN モジュールがあるそうな。 Unicode::RecursiveDowngrade hashref とか、arrayref とか複雑な構造になった変数 (たとえば XML や RSS を XML::Simple や XML::RSS 等で parse した構造) を、構造を変えることなく、値全ての UTF-8 フラグを一括で落としたい場合にﾍﾞﾝｰﾘ。こんなんして使える模様。 use strict; use XML::Sim
http://blog.livedoor.jp/nipotan/archives/50228106.html

PARALYSIS / UTF-8