nDiki : ファイル名

■ [ WiKicker ] 続L10N改善と、ページ名リスト処理の高速化

L10Nの改善の方はひき続き。 これで ja系以外の Accept-Language リクエストヘッダがきた場合は、日本語が混ざらないはず。

それからまた NaneyOrgWiki のレスポンスが悪くなりがちだったので、高速化のためのコード見直し。 現在 WikiPage 数 1151 で、ページ名リストにからんだ処理が遅くなってきているようなので重点的にチェック。

• HierarchicalWikiPage への参照解決の高速化 -> suffix マッチに rindex を使っていたところを substr を使うように修正。
• 1ページ1ファイルで保存しているDBからページ名リストを取得する部分の高速化 -> ディレクトリ上のファイル一覧を取得し各ファイル名をページ名に毎回デコードしていたのだが、これをやめて index ファイルを作っておくように変更。

■ Subversion で大文字・小文字のみ違うファイル名へ変更

Windows ユーザが拡張子を全て大文字にしたファイル名のファイル (hoge.PNG) を登録していた。Windows 上の挙動のチェックがてら Linux 側で

 svn move hoge.PNG hoge.png
 svn commit

してみた。

もちろん Linux 上では問題なし。

Windows 側で TortoiseSVN を使って更新をかけたらエラー。 hoge.PNG のみ先に単体でアップデートすることで作業コピーからの削除まではできるが、.svn の中のファイルのコピーだかで失敗する。

結局作業コピーを削除してチェックアウトしなおし。

■ なめらかアルバム

sappari.org で公開されているなめらかアルバムを試してみた。

• DSC-U40で撮った写真

すでにWebで使用している画像のあるディレクトリに ImageViewer.swfを放り込んで、1行1JPEGファイル名を書いた photo.txt を置くだけ。 ほとんどディスク容量もくわないので便利。

上記のサンプルは画像を 160x120 にしてあるので、静止した時に大きく表示される画質的にはちとつらい。元サイズ以上に大きくならないようなオプションがあるといいな。

■ Windows で pdumpfs

妻の ThinkPad X31 のバックアップ。 /dev/sda1 を NTFS にしておいた HDX-UE160 をプスっと挿して pdumpfs。

日本語ファイル名とかも問題なく。素晴しい。

■ 日本語ファイル名どんとこい

私も大人であるから Word や Excel や PowerPoint のファイルのやりとりがあれば Windows BOX で読み書きしている(参考: Richard Stallman 氏に習う Word 添付ファイルの断り方)。

そしてメールに添付されてくるそれらのファイルは多くの場合、日本語ファイル名だったりする。 Linux 上の Mew 上で適当にASCII文字を使ったファイル名をつけて保存、Samba 経由で Windows BOX で閲覧するというのがいつもの流れだ。 しかし適当に名前をつけているので、すぐどれがどのファイルだがわからなくなる。

Samba で共有しているディレクトリ以下ぐらいは、日本語ファイル名のファイルを作ってもいいことにするかなぁ。

ということで環境設定。

@ LANG

これを機会に一気に UTF-8 化を促進するか。

LANG を ja_JP.eucJP からja_JP.UTF-8 に。 もともと locales では ja_JP.UTF-8 も生成済みだったので特に作業無し。

ターミナルソフトも去年 mlterm に乗り換えているので問題無し。

@ Emacs

 (set-default-coding-systems 'utf-8-unix)

default-file-name-coding-system も utf-8-unix になる。

@ Samba

3.0 系。

 dos charset = CP932
 unix charset = UTF-8 (default)

既に設定済み。

@ ファイラ

さすがに Bash 上で日本語ファイル名を打つのも面倒なので、何かファイルマネージャがあった方がいいな。 できれば Emacs っぽいキーバインディングで。 …… dired でいっか。

@ とりあえず

移行した。 pLaTeX のエラーメッセージとか、UTF-8端末だと読めないものもあるので多少の不便はあるものの大きな問題は今のところなさそうだ。

しばらくやってみる。

■ DAR で差分/増分バックアップ

普段使っているノート PC は pdumpfs でバックアップをとっている。 任意のスナップショットから簡単にファイルを復元できるので、バックアップ用HDDを別に用意できる場合はこれが便利。

@ 問題1

会社で使っている Windows デスクトップは、rsync でWindowsファイルサーバへ同期。 1世代しかバックアップが無い。 少なくとも数世代前のファイルが復元できるようにしておきたい。

@ 問題2

某 Linux サーバはバックアップ無し! マズイ。 現状、たまに手動で tarball にして保存しているぐらい。

@ DAR

DAR というバックアップコマンドの紹介を見て興味をひかれた。 シンプルながらも使い勝手の良さそう。 Linux でも Windows でも動くというのも嬉しい。

@ DAR を使ってみる

Linux 上で試してみる。

@ テスト用ディレクトリを作成

/tmp の下にテスト用ディレクトリ dar を作成。 その下に home ディレクトリと var ディレクトリを作成する。

 mkdir -p /tmp/dar/home/naney
 mkdir -p /tmp/dar/var/lib/dar
 echo 'abc' > /tmp/dar/home/naney/file1.txt

/tmp/dar/home 以下バックアップ対象として /tmp/dar/var/lib/dar 以下にバックアップファイルを作成してみることにする。

@ フルバックアップ

最初はフルバックアップ:

 dar -c /tmp/dar/var/lib/dar/home-full \
     -y9 \
     -R /tmp/dar \
     home

/tmp/dar/home をフルバックアップした home-full.1.1.dar が /tmp/dar/var/lib/dar にできる。

@ 差分バックアップ(1回目)

ファイルを1つ追加。

 echo 'def' > /tmp/dar/home/naney/file2.txt

ここで差分バックアップをとる:

 dar -c /tmp/dar/var/lib/dar/home-diff-1 \
     -A /tmp/dar/var/lib/dar/home-full \
     -y9 \
     -R /tmp/dar \
     home

home-full.1.dar に対する差分バックアップファイル home-diff-1.1.dar ができる。

@ 差分バックアップ(2回目)および増分バックアップ

もう1つファイルを追加。それから最初にあったファイルを削除してみる。

 echo 'ghi' > /tmp/dar/home/naney/file3.txt
 rm /tmp/dar/home/naney/file1.txt

ここで差分バックアップ(2回目):

 dar -c /tmp/dar/var/lib/dar/home-diff-2 \
     -A /tmp/dar/var/lib/dar/home-full \
     -y9 \
     -R /tmp/dar \
     home

home-full.1.dar に対する差分バックアップファイル home-diff-1.2.dar ができる。

またインクリメンタルバックアップもとってみる

 dar -c /tmp/dar/var/lib/dar/home-inc-2 \
     -A /tmp/dar/var/lib/dar/home-diff-1 \
     -y9 \
     -R /tmp/dar \
     home

差分バックアップファイル home-diff-1.1.dar に対する差分バックアップファイル home-diff-2.1.dar ができる。

@ フルバックアップからの復元

 dar -x /tmp/dar/var/lib/dar/home-full

を実行。

 home/naney/file1.txt

が復元される。

@ フルバックアップ+差分1回目からの復元

 dar -x /tmp/dar/var/lib/dar/home-full
 dar -x /tmp/dar/var/lib/dar/home-diff-1

を実行。

 home/naney/file1.txt
 home/naney/file2.txt

が復元される。

@ フルバックアップ+差分2回目からの復元

 dar -x /tmp/dar/var/lib/dar/home-full
 dar -x /tmp/dar/var/lib/dar/home-diff-2

を実行。

 home/naney/file2.txt
 home/naney/file3.txt

が復元される。

@ フルバックアップ+増分1回目(=差分1回目)+増分2回目からの復元

 dar -x /tmp/dar/var/lib/dar/home-full
 dar -x /tmp/dar/var/lib/dar/home-diff-1
 dar -x /tmp/dar/var/lib/dar/home-inc-2

を実行。

 home/naney/file2.txt
 home/naney/file3.txt

が復元される。

@ 運用するには

• dar を使ったバックアップスクリプトの作成(ファイル名生成の処理など)
• cron による定期バックアップの設定
• バックアップファイルをリモートサーバへ転送する手段の用意
• 古いバックアップファイルの削除(ローカル、サーバ)処理の用意

などが必要か。 エラー処理まで含めると結構面倒くさいな。 Perlあたりでまずは簡単なスクリプトを用意するか。

■ Windows 上での Apache 2.0.53 では PATH_INFO が シフト JIS に

WiKicker の Windows 上での動作確認の続き。 WiKicker のPPM パッケージを作成して ActivePerl 5.8.6.811 上にインストール。 依存するモジュールで、ActivePerl に入っていないものは以下の通り。

• Algorithm::Diff
• Jcode
• Log::Log4perl
• Time::Zone (TimeDate)

既に手元で PPM パッケージ化済みなので、これもインストールしておく。

後は RCS をパスの通っているディレクトリに入れてタイムゾーンを設定。

 TZ=JST-9

で CGI プログラムとして実行。 お、表示できた。 書き込みはと。

エラー。

予想していたけれど、sendmail に依存していたところ。 sendmail が見つからない場合はメールの送信をスキップするように修正。

これでうまく動くかなと思ったら、日本語名のページを作るとうまく表示できない問題を発見。

@ PATH_INFO がシフト JIS で渡される

WiKicker では UTF-8 文字列をURIエスケープして WikiPage のURLを生成している。 このURIにアクセスされると WiKicker は、PATH_INFO から WikiName を取り出す。 この文字列がシフト JIS になってしまっている。

Windows がファイル名に使用する charset にあわせて、Apache が変換してしまっているようだ。 調べてみると他の WikiEngine でも同様の問題にあっているという記事が見つかった。

将来の 2.0 系でパッチが取り込まれて修正されるとか、そうでないとか。

現状どうするかなぁ。 WiKicker 側でシフト JIS から UTF-8 に戻すというのもできない事はないけれど、あまりやりたくはないな。 いったんシフト JIS を介しているという時点で、シフト JIS に無い文字の扱いに関する問題をかかえてしまっているし(Apache が)。

対策案:

• Apache 1.x 系を使う (まだ未確認だが、こちらだと勝手に変換されないらしい)
• WiKicker に PATH_INFO を使わないオプションをつける(URI Query Component は勝手に変換されない)
• WiKicker 側でシフト JIS から UTF-8 に変換する

■ 最後がピリオド(.)で終わるファイル名をつけられない

Windows で「最後がピリオド(.)で終わるファイル名」を新規作成する。 最後のピリオド(ドット)が無くなる。

……。

8.3形式の名残なのか? Explorer 上で作成しても、プログラム(Perlスクリプト)から作成しても駄目。

環境は Windows XP Home Edition SP2 + NTFS。 Windows 2000 + NTFS でも同様。

@ WiKicker

これは WiKicker のテストをしていて気がついた。 WiKicker では「PageName の base64 を生成し 『/』 を 『.』 で置き換えたもの」をファイル名にしている。 例えば UTF-8 で「タ」は

 44K/

となるので、ファイル名は 「44K.」となる。 で最後の文字が消えてしまうので、デコードするとおかしくなると。

これを機会に Windows 環境でのエンコーディングは RFC3548 「4. Base 64 Encoding with URL and Filename Safe Alphabet」を使うように変更するか。

本当は全てこれに変更したいのだけれど、すでに動いている WikiForum の事を考えると移行は難しいかも。

■ base64 亜種でのファイル名生成と、Windows

重要な事を忘れていた。

 perl -MMIME::Base64 -e "print encode_base64('abc')"
 perl -MMIME::Base64 -e "print encode_base64('abI')"

先日のピリオド問題発覚以前に、Windows には大文字小文字を区別しないという問題があるんだった……。

今回のファイル名生成規則の見直しにあわせて、今までの WiKicker のデータベースをどう簡単にコンバートするかということをずっと考えていたのだが、そういうレベルではないな。

Windows 版と UNIX 系版は、ファイル名生成規則は別物でいっか。

---

[ MIME::Base64 ]

■ Punycode はファイル名用エンコーディングには向かない

WiKicker の Win32 用ファイル名エンコーディングとして使えないかなと考えていた、 Punycode を試してみる。 実装としては IDNA::Punycode Perl モジュールを使用。

• 空白は空白のまま
• / は / のまま
• アルファベットは大文字小文字を維持したまま

という点で PageName をファイル名にエンコードするのには向いていないことがわかった。 「エンコード後の文字列が短い」「コードが小さい」等の特長があるらしいので、期待していたのでちょっと残念。