nDiki : UTF-8

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)

を追加してく。

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

2006年6月10日 (土)

WiKicker における PageName 最長文字数

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

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

WiKicker実装

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

がある。

仕様等による制約

  • 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 に制約チェックを入れることにしよう。 そのうち。

[ 6月10日全て ]

2006年7月22日 (土)

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

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

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

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

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

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

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

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

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

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

Rubric 0.140

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

  1. CGI プログラムを動かすディレクトリを決める (以下 $RUBRIC)
  2. Rubric tarball の bin/rubric.cgi を $RUBRIC/ にコピーし、必要なら #! を修正する。
  3. Rubric tarball の templates ディレクトリを $RUBRIC/ にコピーする。
  4. Rubric tarball の style/rubric.css を $RUBRIC/ にコピーする。
  5. Rubric tarball の etc/rubric.yml を $RUBRIC/ にコピーして環境に合わせて編集する。
  6. データベースを初期化する。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 してみたが、これはうまく動かなかった。
  7. 必要に応じて .htaccess を作成・編集し rubric.cgi を CGI プログラムとして実行できるようにする。またその他アクセスされたくないファイルを deny するようにしておく。

これで OK。

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

 rubric user -a ユーザ名

でアクティベートする。

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

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

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

[ 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 を吐くように書き直し。

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

[ 10月5日全て ]

2006年12月14日 (木)

TrueCryptUSB メモリWindowsLinux からアクセスできる仮想暗号化ドライブを

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

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

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

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

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

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

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

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 で同期してアンマウントまでの一連の処理を流れ作業でできるようにしたい。

[ 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 の作成

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

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

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

レスポンスの処理

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

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 で書かれているので、プラグインを書いて拡張できるよう将来になると面白いなと思ってみたり。

[ 12月29日全て ]

2008年1月7日 (月)

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

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

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

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

iモードから WiKicker

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

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

肝心のケータイからの書き込みだが Ajax 等凝った技術を使っていないおかげで、問題なく FOMA 端末(D703i)からiモードで読み書きできた。WiKickerUTF-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 リクエスト自体は有効で書き込みがロストすることはないようだ。

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

[ 1月7日全て ]

2008年9月17日 (水)

今日のさえずり: 上げ潮特大号

2008年09月17日

[ 9月17日全て ]

2010年6月3日 (木)

今日のさえずり: ガントチャート上で線をぴゅっと動かして

2010年06月03日

[ 6月3日全て ]

2010年9月9日 (木)

ptexliveUTF-8 pLaTeX2e 文書対応

LaTeX2e 美文書作成入門

また久しぶりに LaTeX2e でドキュメントを作成したくなった。 今まで Linux でも Windows でもコンパイルが通るように ISO-2022-JP で書いていたのだが差分も取りにくいし、そろそろ UTF-8 にしたい。 調べたら Linux なら ptexliveUTF-8 対応の pLaTeX2e が使える模様。Windows については W32TeX が対応済みのようだ。

Debian GNU/Linux では ptexlive がないので、野良インストールした。

~/tmp/ptexlive の下でビルドして /usr/local/texlive/p2009 の下にインストール

以下手順メモ:

依存 Debian パッケージインストール

手元の環境では以下を追加インストールした。

  • libxt-dev
  • libxaw7-dev
  • gs-cjk-resource
  • poppler-data

ptexliveTeX Live をダウンロードしてビルドインストール

~/tmp/ptexlive を作りファイルをダウンロード。 ptexlive アーカイブを展開、TeX Live の方は ISO イメージを展開してマウントする。

 cd
 mkdir -p tmp/ptexlive
 cd tmp/ptexlive
 wget http://tutimura.ath.cx/~nob/tex/ptexlive/ptexlive-20100711.tar.gz
 wget http://www.t.ring.gr.jp/pub/text/CTAN/systems/texlive/Images/texlive2009-20091107.iso.xz
 tar zxvf ptexlive-20100711.tar.gz
 7za e texlive2009-20091107.iso.xz
 mkdir texlive
 mount -t iso9660 -o loop texlive2009-20091107.iso $PWD/texlive

(2010年9月18日追記: ここで TeX live をインストールする)

次に ptexlive を展開してディレクトリに移動して ptexlive.cfg を用意し編集する。

 cd ptexlive-20100711
 cp ptexlive.sample ../ptexlive.cfg
 emacs ../ptexlive.cfg

変更したところは以下。

そしてビルド。なお既存の ~/.texmf-var があると正しくないビルドができる可能性があると警告されるので移動しておく。

 mv ~/.texmf-var ~/.texmf-var-tmp
 make
 make otf

最後にテストがこけるがこれは無視してもよいらしい。

そしてインストール

 su
 make install
 exit

以上で完了。

使用する

環境 PATH を通す。Debian GNU/LinuxTeX 関連パッケージより優先して使うように既存の PATH の前に設定。

 export PATH=/usr/local/texlive/p2009/bin/i686-pc-linux-gnu/@:$PATH

UTF-8 なサンプル pLaTeX2e ファイルを作成して platex、dvipdfmx が通ることを確認。

Happy TeXing!

今日のさえずり: パスワードを暗記しておくのに何バイト消費しているのだろう

2010年09月09日

[ 9月9日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

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

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

月別インデックス
Process Time: 0.066385s / load averages: 0.53, 0.49, 0.50
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker