nDiki : ファイル名

Windows Perl WiKicker 日本語 UTF-8 エラー 画像 URI メール インストール パッケージ名 Apache URL ビルド HTML Perl モジュール CGI プログラム base64 WikiPage Subversion 命名規則 Java ソフトウェア バックアップ GNU アップロード CGI PageName バージョン番号 拡張子

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

私も大人であるから 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端末だと読めないものもあるので多少の不便はあるものの大きな問題は今のところなさそうだ。

しばらくやってみる。

• Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
• xyzzyを読み取り専用メディアから起動する (2004-07-28)
• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• メールによる社内コミュニケーションの問題 (2006-04-12)
• 「シートが硬かった」初めてのつくばエクスプレス乗車 (2006-09-21)

■ 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あたりでまずは簡単なスクリプトを用意するか。

• 私的10大ニュース2004 [ comp ] (2004-12-31)
• 今日のさえずり - スポーツの制裁金ってどこにいくのだ? (2008-06-11)
• ファイルシステム作成はノート PC でやっておいた (2006-01-17)
• Linux、rsync でバックアップ (1999-01-23)
• Windows で pdumpfs (2004-11-14)

■ 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 に変換する

• WiKicker における PageName 最長文字数 (2006-06-10)
• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)
• WiKicker 0.35 リリース - 添付機能の修正など (2006-06-20)
• amaroK で Linux 上の iTunes 音楽データを聞く (2006-01-22)
• WiKicker 0.26 と ActivePerl 5.8.6.811 ... (2005-05-11)

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

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 の事を考えると移行は難しいかも。

• WiKicker における PageName 最長文字数 (2006-06-10)
• WiKicker 実装 (2002-10-20)
• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• ケータイ用にプライベート Wiki を設置 (2008-01-07)
• Rubric でプライベート SBS を立てるも 0.140 では日本語に不具合 (2006-07-22)

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

重要な事を忘れていた。

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

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

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

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

[ MIME::Base64 ]

• 最後がピリオド(.)で終わるファイル名をつけられない (2005-04-19)
• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• WiKicker における PageName 最長文字数 (2006-06-10)
• WiKicker 0.35 リリース - 添付機能の修正など (2006-06-20)
• WiKicker 実装 (2002-10-20)

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

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

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

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

• [ Perl ] Devel::SmallProf (2004-02-12)
• WiKicker における PageName 最長文字数 (2006-06-10)
• WiKicker 実装 (2002-10-20)
• 最後がピリオド(.)で終わるファイル名をつけられない (2005-04-19)
• WiKicker の Win32 対応 (2005-04-04)

■ 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日追記)

• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• TrueCrypt で USB メモリに Windows と Linux ... (2006-12-14)
• ActivePerl で Ming (2005-02-23)
• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• Debian GNU/Linux sid 環境を新 HDD へ (2006-07-29)

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

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

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

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

• amaroK で Linux 上の iTunes 音楽データを聞く (2006-01-22)
• WiKicker における PageName 最長文字数 (2006-06-10)
• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• TrueCrypt で USB メモリに Windows と Linux ... (2006-12-14)
• 今日のさえずり - 上げ潮特大号 (2008-09-18)

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

• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• 最後がピリオド(.)で終わるファイル名をつけられない (2005-04-19)
• WiKicker 0.35 リリース - 添付機能の修正など (2006-06-20)
• WiKicker 実装 (2002-10-20)
• AWStats 6.0 (2004-05-21)

■ WiKicker 0.34 リリース - 添付機能のコードを追加

2006年6月8日以来、3日ぶりのリリース。

zakwa 氏からの要望により、WikiPage のコピー直後に編集画面に移れる edit now オプションを追加。

また大きな改良として「添付機能」を追加した。 まだ最初のコードなのでエラー処理等が甘いが、それなりに動いているのでコミット。 まだ権限設定がないので、公開サーバでは使用しない方が良い。

添付ファイルのダウンロードを WiKicker 本体の CGI プログラムから行わせるか、独立の CGI プログラムにするか迷ったが、結局別物にした。

• WiKicker の URI 体系の中に、末尾にダウンロードファイル名を持ってこれる形式を作成できなかった。

というのが大きな理由。

@ 設定方法

WiKicker のページにまだ設定方法を書いていないので、こちらへ。

@ attachment CGI プログラムを設置

例えば attachment というファイル名で以下のような Perl CGI プログラムを作り、Web サーバから実行できるように設定を行う。

 #!/usr/bin/perl
 use strict;
 use warniings;
 use WiKicker::WikiCGI::AttachmentController;
 WiKicker::WikiCGI::AttachmentController
   ->new(properties_file => '対応する wiki の設定ファイル名')->run;

@ Wiki のプロパティに設定を追加

次に Wiki の設定ファイルに以下を追加。

 param.NormalPage.attachment: enable
 param.NormalPage.attachment.uri: attachment

param.NormalPage.attachment.uri には上で作った CGI プログラムの URI (相対/絶対)を指定する。

これで各ページに attachment (添付)というリンクが表示され、添付機能が使えるようになる。

@ WikiPage での参照の仕方

 # リンクを作成
 [[attachment:ファイル名]]
 [[attachment:ページ名/ファイル名]] <- 別のページの添付ファイル

 # 画像をインライン表示
 [[image:attachment:ファイル名]]
 [[image:attachment:ページ名/ファイル名]]

• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• XAMPP で WiKicker を動かしてみた。PPM インストール OK。 (2007-02-09)
• WiKicker における PageName 最長文字数 (2006-06-10)
• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• [ Perl ] Log::Log4perlのはまりどころ (2004-03-02)