nDiki : base64

WiKicker 実装

URI まわりと、DB まわりの実装すすめる。UTF-8 PageName をファイル名にマッピングするのに base64 を使おうと思ったら、符号化される文字に '/' が含まれているのか。 '.' に置き換えた変形 base64 にすればいいかな。

[ WiKicker ] キャッシュまわりにバグ

Memcached まわりをいじったので、キャッシュ具合をテストしていたら変な現象が。 WikiPage が表示されるべきところに、検索結果が表示されている。 あれ?

ページの内容が表示されるところに検索結果が

WiKicker では WikiPage のレンダリング結果も検索結果もキャッシュしているが、それぞれ別のキャッシュキーになるようにしている (WiKickerのバージョンを $V とすると、'$V:h:ページ名' と '$V:s:検索語')ので混ざるはずがないんだけれどな。 キャッシュしているデータの形式も違うし。

最初は Memcached まわりのアップデートで不具合がでたのかと思ったが、戻しても変わらない。ということは、ずっと以前からこの問題が発生していたのか。 やば。 設定でニックネームを設定している(cookie に保存している)と、その Web ブラウザに対してはキャッシュ機能が働かないようになっているので発見が遅れてしまった。

で結局コードをチェックしてみたら「WikiPage 表示と検索結果表示の View クラスを同じにしていたため、検索結果のレンダリングが WikiPage レンダリング結果と同じ領域にキャッシュされる」という風になってしまっていた。 ということで誰かがページ名で検索するとそれがキャッシュされてしまい、ページを読もうとしてもキャッシュ破棄されるまで検索結果が表示されてしまうというひどい状況になっていたと。

修正。

キャッシュキーのバグ

Memcached の出力をチェックしていたら、たまにエラーが起きていることを確認。 Memcached のプロトコルをチェックしたら、キーには制御文字と空白は使えないとある。 Cache::Memcached を見たらキーはそのまま through するだけ。 ということでページ名に空白が含まれている場合などの時には、まずい事になっていたようだ。 こちらは、キーを自前でエンコーディング(ページデータベースファイル名の作成に使っている base64 の亜種)するように修正。

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

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 ]

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

今日のさえずり: お年玉付き年賀はがきの当選番号チェックしました。全滅でした!

2011年01月28日

• 11:39 Evernote for Android の prelease 版使っていたんだけれど public 版も 2.5.1 になっていたので、出勤中にアンインストールしてマーケットから入れ直した。 #Evernote
• 11:40 Evernote for Android の同期のやりなおしでまだサムネイルガンガンダウンロードしている。Skype for Android も起動しっぱなしだったし電池の減りばハンンパない。
• 14:59 ローカル用に短縮 URL サービスが欲しいんだけれど Perl 実装でインストールが簡単でごっつい RDBMS 使わないやつでいいのないかな。
• 16:04 MIME::Base64::encode_base64url が入ったのって MIME-Base64-3.11 (2010年10月24日)からか。最近のバージョンじゃないと入ってないな。encode_base64 の結果ちょっと置換しているだけだけど。 #Perl
• 19:25 必ず上限まで使ってるからパケ・ホーダイ フラットに変更かな。3月15日提供開始だけれど、月末/月初で切り替えた方がいいのかな。 #Xperia
• 20:33 prove RED です! @as_tone
• 20:56 prove GREEN です! @as_tone
• 21:48 RT @tomooyoda: 来月の要求開発アライアンス定例会　バリューソース神崎さんと、モデリングとソースコード解析を組み合わせた画期的な現状分析手法についてお話しします。 http://kokucheese.com/event/index/7486/

2011年01月29日

• 11:30 公園行ってくる。
• 13:40 ミシン付属の DVD 観てる。淡々と操作説明が続くので記憶に残らない。
• 14:03 なに? 最近のミシンって針穴糸通し装置もついてるの。
• 14:13 ありがとうございます! お年玉付き年賀はがきの当選番号チェックしました。全滅でした!
• 14:28 次の有給休暇の日に花粉症の薬もらいに病院に行こう。今年は多いのに出遅れ気味。
• 15:56 ノート PC バックアップ中。Mew から Gmail に過去メールを移動してがっつりファイルが減ったから、バックアップ時間が多少減るかな。
• 17:34 今晩24:00から「当たり前田の加賀まさし」 #NHK #sada #namasada
• 17:51 ドミノ・ピザの「生活応援キャンペーン!! Aセット」注文。

iA Writer の Web プレビューを Google ドキュメントに貼り付けて共有する(画像付きで)

iA Writer の Web プレビューを Google ドキュメントに貼り付けて共有する方法で一緒に貼り付けられる画像はインターネット公開されているものだけなのがちょっと不便だった。iA Writer の Web プレビューのクリップボードコピーには画像データが直接含まれないため。

でいろいろ試したところ iA Writer 側で データ URL として画像を貼り付ければ、コピー & ペーストで Google ドキュメントに貼り付けられることが分かった。

画像データを base64 コマンドなどで base64 で符号化し、 Markdown ファイル上で

 ![](data:image/png;base64,画像データ)

とすれば OK(image/png はメディアタイプに合わせる)。 iA Writer で Web プレビューで表示される。

とても長い URL なので文章中に直接含めておくのは不便。実際には img.png.txt など別のファイルに書いておいて

iA Writer の content block 機能を使って

 /img.png.txt

のような形で include して実用するのが良さそうだ。ロケーションの中にファイルを置くことで検索にひっかかって不便な場合は、別のフォルダに置いて

../img/img.png.txt

のように相対指定かな。

[ ノート・日記はテキストファイルに ] [ Markdown で書いているノートを Google ドライブで共有する ]