which-key.elとメニューの定義

Emacs 30からwhich-key-modeが追加されます。which-key-mode自体は何年も前からある(github.com/justbur/emacs-which-key)ようですが、それがEmacsに組み込まれたということのようです。私はこれまで使ったことはありませんでしたが、手元のEmacs 30.0.92に入っていたので使ってみました。

そもそもwhich-key-modeは何かというと、次に押すべきキーを教えてくれる、というと抽象的で分かりづらいでしょうか。一言で言うと、自動的にキーメニューを表示してくれる(グローバルマイナー)モードです。例えばC-xと入力して少し待つ(次に打つべきキーを迷っている)とC-xで始まるキー割り当ての一覧が表示されます。もちろんC-xだけでなく複数のキーストロークが必要な場面では自動的にメニューが出ます。

キーメニューというとHydraやTransientを思い出しますが、これらは基本的には明示的にメニューを定義した上で使うものだと思います。自分で使いやすいようにメニューを設計できますが、逆に言えばそのような手間をかけなければなりません。一方which-key-modeは現在のキーマップから自動的にメニューを作成してくれます。

which-key-modeは事前の定義が不要な分手軽で広範囲で使用できますが、表示されるのは無味乾燥なコマンド名の羅列……と言いたいところですが、そこにはちゃんと対策が用意されています。

次の関数を使うと特定のキー割り当てに対して表示される説明を好きなように変更(置き換え)できます。

which-key-add-keymap-based-replacements : 特定のKEYMAPの特定のKEY-SEQUENCEに対する説明を設定する
which-key-add-key-based-replacements : 特定のKEY-SEQUENCEに対する説明を設定する
which-key-add-major-mode-key-based-replacements : 特定のメジャーMODEの特定のKEY-SEQUENCEに対する説明を設定する

後者二つはwhich-key-replacement-alist等のwhich-key専用の変数に置き換えルールを記録しますが、興味深いのは一つ目の特定のKEYMAPに対する説明の置き換えです。which-key-add-keymap-based-replacementsの実装を見れば分かりますが、その情報は指定されたKEYMAPそれ自体に保存されます。説明(replacement)に文字列が指定された場合を追ってみると、最終的には (define-key keymap (kbd key) (cons replacement 元の割り当て)) が実行されていることが分かります。これはいったいどういうことでしょうか？

元々Emacsのキーマップというのはメニューを記述する役割を兼ねています。そのためキーマップにはメニュー項目用の文字列を埋め込めるようになっています。キーマップの書式(Format of Keymaps (GNU Emacs Lisp Reference Manual))にある item-name というがそれです。つまりwhich-key-add-keymap-based-replacementsがやっていることは実質的にはメニューを構築しているようなものです。そしてwhich-key-modeはそのメニューの項目用の文字列をコマンド名の代わりに表示してくれるというわけです。

ということはつまり、わざわざwhich-key-add-keymap-based-replacementsを使わずともキーマップに項目文字列を最初から設定しておけばwhich-key-modeのキーメニューをよりわかりやすく出来るということです。

キーマップを作成するには例えば次のようなコードがよく使われてきました(<Emacs29)。

(let ((km (make-sparse-keymap)))
  (define-key km (kbd "C-c h c") 'hello-cat)
  (define-key km (kbd "C-c h d") 'hello-dog)
  (define-key km (kbd "C-c h f") 'hello-flog)
  km)

これを次のようにするだけでwhich-key-modeのメニューをよりわかりやすくすることが出来ます。

(let ((km (make-sparse-keymap)))
  (define-key km (kbd "C-c h") (cons "Hello Animals" (make-sparse-keymap)))
  (define-key km (kbd "C-c h c") '("Cat" . hello-cat))
  (define-key km (kbd "C-c h d") '("Dog" . hello-dog))
  (define-key km (kbd "C-c h f") '("Flog" . hello-flog))
  km)

(注: 最近(>=Emacs29)ではdefine-keyはレガシー扱いとなりkeymap-setやdefine-keymapが追加されていますが、いずれにせよ項目文字列を指定する方法は用意されています)

マイナーモードならこんな感じでしょうか。

(define-minor-mode hello-animals-mode
  "Hello Animals"
  :keymap
  `((,(kbd "C-c h") . ("Hello Animals" . ,(make-sparse-keymap)))
    (,(kbd "C-c h c") . ("Cat" . hello-cat))
    (,(kbd "C-c h d") . ("Dog" . hello-dog))
    (,(kbd "C-c h f") . ("Flog" . hello-flog))))

実際に有効にして C-c h を押してみたところ、次のように表示されました。

複雑なキーマップを分かりやすくしたい、でもHydraやTransientを使うのは面倒という場合はこのような工夫をしてみてはどうでしょうか。

余談:

ちなみにキーマップをキーボードで操作できるメニューにしたいのであれば tmm-prompt を使うという方法もあります。

(defun hello-cat () (interactive) (message "Nya"))
(defun hello-dog () (interactive) (message "Wan"))
(defun hello-flog () (interactive) (message "Geko"))

(let ((km (make-sparse-keymap)))
  (define-key km (kbd "C-c") (cons "C-c" (make-sparse-keymap)))
  (define-key km (kbd "C-c h") (cons "Hello Animals" (make-sparse-keymap)))
  (define-key km (kbd "C-c h c") '("Cat" . hello-cat))
  (define-key km (kbd "C-c h d") '("Dog" . hello-dog))
  (define-key km (kbd "C-c h f") '("Flog" . hello-flog))
  (tmm-prompt km)) ;; (x-popup-menu t km))だとマウスで操作するメニューになる

HydraやTransientは良くも悪くも独特の世界観を作ってしまっているところが欠点ではありますよね。で、作り込んでみてもキー操作を覚えてしまえば見なくなるわけですし。それに一つのメニューの中に沢山のコマンドを表示してしまうと探すのが大変でむしろM-xでミニバッファから補完した方が探しやすいということにもなりかねません。Magitでたまにしか使わないコマンドのキーがメニューから見つけられないことが私は良くあります。いや、MagitはそもそもGitのコマンド体系自体が(以下略

2024-12-11 el-xmp, Emacs

Diredでファイルの右側に好きな情報を追加する

いやぁ、やっぱりSVGっていいですよね。先日から作っているel-xmpですが、レーティングの表示が単なる数字なのがつまらないのでSVGで描いてみました。ひょっとしたらUnicodeやアイコンフォントで作れるのかなとも思いましたが、よく分かりませんし出来たとしてもフォントへの依存は避けられないと思ったのでSVGでいいや。それで色々調整してこんな感じで生成できました。

何がいいって、こういう風にエディタの中に直接結果が挿入されるところですよね。私は80年代のBASICからプログラムを始めた人間ですが、あれもこんな風にコードを書いて実行したらその画面の中の好きな位置に結果が出力されるような環境でした(末尾では無く好きな位置にというのが結構重要だと思っています)。グラフィックスは別プレーンに描いてから無限ループで止めておかなければならなかったりもしましたが、時代が進むとテキストの後ろに合成表示されるようになったりもしました。私はEmacs Lispをいじっているとよくあの頃の感覚を思い出します。

それで気を良くして実際にdiredの中にレーティングを表示させてみたところ……

あれ、数字のままだ。何でだ？？？

……ああ、私はファイルの詳細情報を右側に表示するためにdired-details-rを使用していたのでした。こいつはオーバーレイ(またはファイル数が多いときはテキストプロパティ)を使用して詳細情報をファイル名の右側に表示します。そしてオーバーレイ(またはテキストプロパティ)のdisplayプロパティを使用してファイル名前後の文字を詳細情報込みの文字列に置き換えることで無理矢理詳細情報を好きな位置に表示させているのでした。

で、SVG画像もまたdisplayプロパティを必要とします。もちろん画像を含めて全てのテキストプロパティをコピーして右側に持ってきているのですが、displayプロパティの中のdisplayプロパティはEmacsの仕様では無視されるため、SVG画像としてでは無く元の数字文字列として表示されてしまうわけです。

なのでいったんdired-details-rを切れば表示されます。

この通り。

うーん、どうしよう。オーバーレイプロパティのbefore-stringやafter-stringを使えば回避できなくもないけれど、ファイル数が多いときにはテキストプロパティを使いたいので却下。

と、ここで思い出すのは前々回書いたDiredに好きなファイル情報を追加する話。

そこではファイル名の左側に情報を挿入しましたが、ファイルの右側にも情報を挿入できるのでしょうか。

そこでも触れましたが、Diredバッファ内のファイル名が書かれている範囲には dired-filename というテキストプロパティが設定されています。そのためファイル名の前後に何か余計なテキストが挿入されてもファイル名を見失うことはありません。なのでその点だけ見れば大丈夫なはずです。……本当にそうでしょうか？

ファイル名の右側に情報を追加してみる

前と同じサンプルを使って試してみましょう。

ファイルのスコアを書いた.file-score.csvファイル(前と同じ):

muscat.html,230
melon.html,140
grape.html,185
cherry.html,210
strawberry.html,153

これを読む関数(前と同じ):

(defun my-dired-sort-read-file-score (dir)
  (ignore-errors
    (with-temp-buffer
      (insert-file-contents (file-name-concat dir ".file-score.csv"))
      (goto-char (point-min))
      (cl-loop until (eobp)
               for (file score) = (split-string (buffer-substring (point) (line-end-position)) ",")
               collect (cons (expand-file-name file dir)
                             (string-to-number score))
               do (forward-line)))))

一つのディレクトリの中のファイルリストの範囲を特定する関数(前と同じ):

(defun my-dired-next-dir-files-region ()
  ;; ファイル名が無いところをスキップ
  (while (and (null (dired-move-to-filename))
              (= (forward-line) 0)))
  (unless (eobp)
    (let ((beg (line-beginning-position)))
      ;; ファイル名があるところをスキップ
      (while (and (dired-move-to-filename)
                  (= (forward-line) 0)))
      (cons beg (line-beginning-position)))))

で、肝心の追加するところは関数名は同じままで少し変更してみます。

(defun my-dired-add-file-score-to-region (beg end)
  ;; (↓when-let/if-let廃止するとか言ってるの超うざくね？　アホか)
  (when-let* ((file-score-alist
               (my-dired-sort-read-file-score (dired-current-directory))))
    (goto-char beg)
    (while (< (point) end)
      ;; 各行について (★この辺から変更)
      (when-let* ((file (dired-get-filename nil t)) ;; ファイル名の取得
                  (score (alist-get file file-score-alist nil nil #'string=))) ;; スコアの取得
        ;; 両者取得できたら
        ;; 行末へ(つまりファイル名の右へ)
        (end-of-line)
        ;; スコアを挿入
        (insert (format "  %4d" score)))
      ;; 次の行へ
      (forward-line))))

最後のコマンドの部分(前と同じ):

(defun my-dired-add-file-score ()
  (interactive nil dired-mode)
  (widen)
  (goto-char (point-min))
  (let ((inhibit-read-only t))
    (while-let ((files-region (my-dired-next-dir-files-region)))
      (let ((beg (car files-region))
            (end (copy-marker (cdr files-region))))
        (my-dired-add-file-score-to-region beg end)
        (goto-char end)
        (set-marker end nil)))))

実際に試してみる

サンプルファイルがあるディレクトリで M-x my-dired-add-file-score したところ、次のような見た目が得られました。

c:/home/user/tmp/my-dired:
drwxrwxrwx  1 user user 4096 24-12-09 21:44 .
drwxrwxrwx  1 user user 4096 24-12-11 17:38 ..
-rw-rw-rw-  1 user user   87 24-12-09 18:45 .file-score.csv
-rw-rw-rw-  1 user user    8 24-12-09 18:46 cherry.html   210
-rw-rw-rw-  1 user user    7 24-12-09 18:46 grape.html   185
-rw-rw-rw-  1 user user    7 24-12-09 18:46 melon.html   140
-rw-rw-rw-  1 user user    8 24-12-09 18:46 muscat.html   230
-rw-rw-rw-  1 user user   14 24-12-09 18:47 strawberry.html   153

数字の位置がずれているのはご愛敬。揃える処理を入れていないので。問題はDiredとしてちゃんと動作するのかどうか。

少し試したくらいだと問題ないように見えます。wでコピーできるファイル名は正しいものですし、ファイルを開いたりも出来ます。

問題点と原因

しかししばらくいじっているとおかしな所も見つけました。

~ (dired-flag-backup-files) や # (dired-flag-auto-save-files) によるマークができない(バックアップファイルや自動保存ファイルが検出されない)
色付け(fontify、font-lock)がおかしい
- バックアップファイルなどに色が付かない
- マークやフラグが付いた行はファイル名だけでなくその右側のスコア部分まで色が付く

調べてみるとやはり行の末尾がファイル名の末尾であることを前提にしたコードが存在していることが分かりました。まぁ、そういうのが嫌なのでdired-details-rはオーバーレイやテキストプロパティを使っていた訳なので、案の定と言ったところです。

マークができない原因は、マークする関数が各ファイル行においてend-of-lineで行末へ飛んでからpreceding-charでその前の文字を取得・チェックしている(~や#であるかどうかをチェックしている)からでした。付近のコメントも読んでみた限り、どうも高速化のためにあえてそのようにしているフシがあります。

色付けについては、font-lockの色付けルール(dired-font-lock-keywords)が全般的に行の末尾がファイル名の末尾であることを前提にして書かれてしまっていることが原因です。例えば一番分かりやすいのが正規表現 $ をファイル名の末尾として使ってしまっている所。 $ の前には拡張子とマッチする正規表現が先行します。なので、ファイル名の後に何か情報を追加すると(その追加した情報の末尾がたまたまマッチしない限り)マッチしなくなってしまいます。

dired-details-rの改善

これらの調査を踏まえた上で、右側に詳細情報を表示したときにSVG画像が反映されない問題は結局はdired-details-rの問題なので、そちらを修正することにしました。

まずは詳細情報の表示を(オーバーレイやテキストプロパティでは無く)テキストの挿入によって行うオプションを追加。これまでにも表示方式を指定するカスタマイズ変数はあったので、そこにテキスト挿入によって表示を行う指定値(text)を追加。そしてオーバーレイやテキストを更新する所では、設定値によって代わりにテキスト挿入や削除を行うように変更。

そして今回見つけたいくつかの弊害に対処。マークの問題は関数を丸丸置き換えるしか無さそう。色付けは問題があるfont-lock-keywordsルールを置き換える関数を作成し、dired-mode-hookで実行。どちらもかなり無理矢理。もちろんまだ見つけていない問題がどこかにあるかもしれませんが、それは見つけたらその都度直しましょう。

というわけで、これによって次のように詳細情報をファイル名の右に表示しつつSVGで描かれたレーティングの星マークも表示できました。

el-xmpの進捗

el-xmpの方はとりあえず、すぐにやりたいことは一通りやったので一段落といった所でしょうか。まだまだやれることはいくらでもありますがキリがないので。

そうそう、ISO base media file formatというのを解析してメタデータを抽出できるようにしたんですよ(規格書が日本円で3～4万円くらいしててドン引き)。QuickTimeから始まってMPEG4(mp4、m4a)とかJPEG2000なんかもだいたい同じ形式みたいです。基本的な構造はボックスと呼ばれるサイズとタイプのヘッダーから始まるデータブロックの羅列です。ボックスの中にボックスが入れ子になる事が良くあるのでツリーのような構造とも言えますが、それほど自己記述性は無くボックスタイプ毎に定義される内部形式(syntax)が分からなければ中に何が入っているかは分かりません(当然入れ子になっているボックスがあるのかも分かりません)。ボックスタイプは典型的な4文字コードに加えてUUIDでも表現できるようになっていて誰でも他人とぶつからないボックスタイプを追加できます。それでメタデータなのですが、案の定あちこちに散らばっている感じですね。そのファイルの素性毎にどこにあるのかまちまちです。もちろんあらゆる方式に対応することは出来ませんが、とりあえず手元にあるm4aファイルくらいは読めるようにしておきました。それと写真をPhotoshopでJPEG2000で保存し直したものなんかもXMPとEXIFが埋め込まれるので読めるようにしておきました。何なんですかねこれ？　自由にボックスタイプを追加できるからって好き勝手しすぎ。これはそう……まるで闇鍋じゃないか！

2024-12-06 el-xmp, Emacs

Dired内にファイルのメタデータを表示する

というわけで、el-xmpを使えばDiredの中にファイルのメタデータを表示できるようになりました。

もちろんソートやフィルタ、マークも可能です。

ようやくWindowsのエクスプローラでも出来るようなことがEmacsでもできるようになりました。良かった良かった。

とは言えサポートしているファイル形式がまだ限られているのでもう少し増やしたいところですね。

とりあえずID3に対応したので、MP3のアーティスト名やアルバム名なんかも表示できるようになりました。

2024-11-30 Emacs

Diredに好きなファイル情報を追加する

昨日の続き。

前回はファイルのスコアが書かれているCSVファイルを元にDired内のファイルをソートしてみましたが、これだけだとパッと見何の順番で並んでいるのかよく分かりませんよね。やはりファイルの一覧の中にスコアの数字そのものも表示されていないとピンときません。なので今回はDiredのファイル行の中に、ファイルに関連した任意の情報を追加する方法について考えてみようと思います。

勝手にファイル情報を追加しても大丈夫なのか

前回も書いたとおりDiredは単なるテキストバッファですから、勝手に書き替えてしまえば済む話です。本当に？　結論としては、たぶん、概ね問題ないと思います。

Diredはファイルに関する情報を変数の形では保持しておらず、全てバッファ内のテキストとして保持しています。なのでファイル名を始め全ての情報は何かコマンドを実行するたびにバッファ内のテキストから毎回抽出しなければなりません。デフォルトの -al オプションでファイルリストを作成すると、ファイル行には左から順にファイルの種類(d)、モードビット、ハードリンク数、所有者名、グループ名、サイズ、タイムスタンプ、そしてファイル名が並びます(シンボリックリンクの場合はその後に -> で始まる部分が追加されます)。この中で一番重要なのは当然一番右のファイル名ですが、その位置を正確に割り出すのは案外面倒な問題が伴います。そんな中で、ファイル名の左側に好きな情報を勝手に追加してしまっても大丈夫なのでしょうか。

大丈夫なのです。ファイル名の左にどんなテキストを追加してもDiredは正確にファイル名の位置を割り出すことが出来ます。

insert-directoryの秘密

その秘密はinsert-directoryという関数にあります。この関数はlsの出力をバッファに挿入する関数です(lsが無い環境ではls-lisp.elでエミュレートします)。lsと同じようにファイルパスとスイッチを引数に取ります。今回注目すべきは、スイッチとして --dired を指定したときの挙動です。GNUのlsには --dired (または-D)というオプションがあり、これが指定されているとlsは出力の最後にファイル名部分の範囲を先頭からの文字数で列挙してくれます。例えば次のように。

> ls -al --dired 
  total 684
  drwxr-xr-x 1 user user     0 11月 27 18:36 ./
  drwxr-xr-x 1 user user     0 11月 30 15:31 ../
  -rw-r--r-- 1 user user  1948  9月 25 16:55 compface.el
  -rw-r--r-- 1 user user   906 10月 26 18:46 compface.elc
  -rw-r--r-- 1 user user 12701  9月 25 16:55 exif.el
  -rw-r--r-- 1 user user  7640 10月 26 18:46 exif.elc
  -rw-r--r-- 1 user user 13135  9月 25 16:55 gravatar.el
  -rw-r--r-- 1 user user  9698 10月 26 18:46 gravatar.elc
  -rw-r--r-- 1 user user 14269  9月 25 16:55 image-converter.el
  -rw-r--r-- 1 user user 10276 10月 26 18:46 image-converter.elc
  -rw-r--r-- 1 user user 17854  9月 25 16:55 image-crop.el
  -rw-r--r-- 1 user user 13474 10月 26 18:46 image-crop.elc
  -rw-r--r-- 1 user user 84378 10月 16 04:24 image-dired.el
  -rw-r--r-- 1 user user 83477 10月 26 18:46 image-dired.elc
  -rw-r--r-- 1 user user 17044  9月 25 16:55 image-dired-dired.el
  -rw-r--r-- 1 user user 18328 10月 26 18:46 image-dired-dired.elc
  -rw-r--r-- 1 user user 29509  9月 25 16:55 image-dired-external.el
  -rw-r--r-- 1 user user 21633 10月 26 18:46 image-dired-external.elc
  -rw-r--r-- 1 user user 13209  9月 25 16:55 image-dired-tags.el
  -rw-r--r-- 1 user user  9952 10月 26 18:46 image-dired-tags.elc
  -rw-r--r-- 1 user user  8924  9月 25 16:55 image-dired-util.el
  -rw-r--r-- 1 user user  7195 10月 26 18:46 image-dired-util.elc
  -rw-r--r-- 1 user user 23171  9月 25 16:55 wallpaper.el
  -rw-r--r-- 1 user user 24016 10月 26 18:46 wallpaper.elc
//DIRED// 59 60 109 111 160 171 219 231 279 286 334 342 390 401 449 461 509 527 575 594 642 655 703 717 765 779 827 842 890 910 958 979 1027 1050 1098 1122 1170 1189 1237 1257 1305 1324 1372 1392 1440 1452 1500 1513
//DIRED-OPTIONS// --quoting-style=literal

末尾の //DIRED// で始まる行の後に並ぶ数字はファイル名部分の範囲を示しています。最初は59ですが、これは最初のファイル名の先頭が出力の先頭から数えて59文字目にあることを意味しています。次の60はファイル名の末尾の位置を同様に表します。つまり、一番最初の . を指しています。以下同様に続きます。

そして重要なのは、insert-directoryはこの情報を読み取ってバッファ内のファイル名が書かれている範囲にテキストプロパティ dired-filename=t を設定するということです。

なので行の中にあるファイル名を表す範囲を特定するにはテキストプロパティが設定されている範囲を探すだけで良く、その前にどんなテキストがあってもそのテキストプロパティが存在する限り(少なくともファイル名を特定するには)問題ありません。そのテキストプロパティが設定されている場所を探す関数がdired-move-to-filenameとdired-move-to-end-of-filenameです。その中を見れば行末までの間にある dired-filename という名前のテキストプロパティを探していることが分かります。(注:これらの関数を見るとテキストプロパティが検出できなかったときの処理も書かれていて、正規表現検索によってファイル位置の範囲を特定しようとしています。なので100%問題ないとは言い切れない部分がありますが、今回はその辺りは無視することにします)

実際に追加してみる

前回書いたコードの中から流用できるものを引っ張ってきましょう。

サンプルのCSV。

muscat.html,230
melon.html,140
grape.html,185
cherry.html,210
strawberry.html,153

これを読む関数。

(defun my-dired-sort-read-file-score (dir)
  (ignore-errors
    (with-temp-buffer
      (insert-file-contents (file-name-concat dir ".file-score.csv"))
      (goto-char (point-min))
      (cl-loop until (eobp)
               for (file score) = (split-string (buffer-substring (point) (line-end-position)) ",")
               collect (cons (expand-file-name file dir)
                             (string-to-number score))
               do (forward-line)))))

一つのディレクトリの中のファイルリストの範囲を特定する関数。

(defun my-dired-next-dir-files-region ()
  ;; ファイル名が無いところをスキップ
  (while (and (null (dired-move-to-filename))
              (= (forward-line) 0)))
  (unless (eobp)
    (let ((beg (line-beginning-position)))
      ;; ファイル名があるところをスキップ
      (while (and (dired-move-to-filename)
                  (= (forward-line) 0)))
      (cons beg (line-beginning-position)))))

それでファイルリストの中にスコアの数字を挿入する関数を作成します。

(defun my-dired-add-file-score-to-region (beg end)
  (when-let ((file-score-alist
              (my-dired-sort-read-file-score (dired-current-directory))))
    (goto-char beg)
    (while (< (point) end)
      ;; 各行について
      (when (dired-move-to-filename) ;; ファイル名の先頭へ移動
        ;; ファイル名とスコアを取得
        (let* ((file (dired-get-filename nil t))
               (score (alist-get file file-score-alist nil nil #'string=)))
          ;; 1文字左へ移動
          (backward-char)
          ;; スコアを挿入
          (insert (if score (format " %3d" score) "    "))))
      ;; 次の行へ
      (forward-line))))

バッファ内にある全ディレクトリに対してこれを適用する関数を作成します。前回作った my-dired-sort-by-file-score 関数とほとんど同じですが、今回は挿入すると末尾の位置がずれていくためマーカーを使用しています。そして my-dired-sort-region-by-file-score の代わりに今作った my-dired-add-file-score-to-region を呼び出すようにすればOKです。

(defun my-dired-add-file-score ()
  (interactive nil dired-mode)
  (widen)
  (goto-char (point-min))
  (let ((inhibit-read-only t))
    (while-let ((files-region (my-dired-next-dir-files-region)))
      (let ((beg (car files-region))
            (end (copy-marker (cdr files-region))))
        (my-dired-add-file-score-to-region beg end)
        (goto-char end)
        (set-marker end nil)))))

前回作ったソートコマンドと一緒に使ってみるとDiredバッファは次のような見た目になりました。

c:/home/user/tmp/my-dired:
drwxr-xr-x 1 user user  0 11月 30 23:14     .
drwxr-xr-x 1 user user  0 11月 30 23:13     ..
-rw-r--r-- 1 user user 87 11月 30 23:14     .file-score.csv
-rw-r--r-- 1 user user  7 11月 30 23:13 140 melon.html
-rw-r--r-- 1 user user 12 11月 30 23:14 153 strawberry.html
-rw-r--r-- 1 user user  7 11月 30 23:13 185 grape.html
-rw-r--r-- 1 user user  8 11月 30 23:13 210 cherry.html
-rw-r--r-- 1 user user  8 11月 30 23:13 230 muscat.html

スコアが表示され、その順番でファイルが並んでいることが分かります。

2024-11-29 el-xmp, Emacs

Diredでファイルを好きな順に並べる

Web検索すると s キーや C-u s でソート順を変更できるという情報が見つかりますがそういった話ではありません。悪しからず。

Diredではlsやls-lispが認識するオプションによってファイルをソートできますが、ソートのキーに出来るのはあくまでファイルシステムが認識できるもののみです。ファイルシステムの外にある何らかの情報に基づいてファイルをソートするにはどうしたら良いでしょうか。

テキストバッファレベルでのソート

基本的にDiredというのは(良くも悪くも)ファイル情報を並べただけのテキストバッファに過ぎないので、read-onlyを一時的に解除して好きなように並べ替えてしまえば良いのです。ただし、次のことに注意する必要があります。

C-x C-q (dired-toggle-read-only)はwdiredを起動してしまうので使えません。 M-x read-only-mode するか、Emacs Lispから (let ((inhibit-read-only t)) ...書き替え... ) しましょう。
ファイル部分には見えないテキストプロパティが設定されているのでそれが失われないようにしましょう。
ディレクトリの範囲はdired-subdir-alist変数とマーカーで管理されているので、それが壊れないようにしましょう。
Diredの一部の機能や拡張はファイル部分にオーバーレイを設定するので、それに配慮しましょう。いったん解除してから編集するか、または、それらが機能する前に割り込んで処理してしまうかです。

試しに M-x read-only-mode の後にファイルの範囲を正確にリージョンで囲って、 M-x sort-lines してみればソートされることが確認できると思います。

外部の情報を元にテキストバッファをソート

例えば何かファイルに対するスコアを列挙したファイル(.file-score.csv)があるとしましょう。

muscat.html,230
melon.html,140
grape.html,185
cherry.html,210
strawberry.html,153

これを読み込むには次のようなEmacs Lispの関数を作れば良いでしょう。

(defun my-dired-sort-read-file-score (dir)
  (ignore-errors
    (with-temp-buffer
      (insert-file-contents (file-name-concat dir ".file-score.csv"))
      (goto-char (point-min))
      (cl-loop until (eobp)
               for (file score) = (split-string (buffer-substring (point) (line-end-position)) ",")
               collect (cons (expand-file-name file dir)
                             (string-to-number score))
               do (forward-line)))))

試しに実行してみると次のようになります。

(my-dired-sort-read-file-score "/products/")

(("/products/muscat.html" . 230)
 ("/products/melon.html" . 140)
 ("/products/grape.html" . 185)
 ("/products/cherry.html" . 210)
 ("/products/strawberry.html" . 153))

これを元にDired上でファイルをソートするには、sort-subr関数を使用すると次のように書けます。

(defun my-dired-sort-region-by-file-score (beg end)
  (when-let ((file-score-alist
              (my-dired-sort-read-file-score (dired-current-directory))))
    (save-restriction
      (narrow-to-region beg end)
      (goto-char beg)
      (sort-subr
       nil            ; REVERSE
       #'forward-line ; NEXTRECFUN
       #'end-of-line  ; ENDRECFUN
       ;; STARTKEYFUN (注意:決してnilを返さないこと)
       (lambda ()
         (alist-get (dired-get-filename nil t) file-score-alist 0 nil #'string=))
       nil            ; ENDKEYFUN
       #'<            ; PREDICATE
       ))))

sort-subrはバッファ内のテキストをソートする汎用的な関数です(Sorting (GNU Emacs Lisp Reference Manual))。引数STARTKEYFUNには通常キーとなるテキストの先頭へ移動する関数を指定しますが、単にキーとなる値を返しても構いません。ここではファイル名に対応するスコアの数値を返しています。キーを数値にしたのでPREDICATEには #'< を指定していますが、デフォルトのままでも大丈夫かもしれません。

試しにテスト用のファイルを用意して、Diredバッファ内でファイルをリージョンで囲い、 M-: (my-dired-sort-region-by-file-score (region-beginning) (region-end)) などとしてみるとちゃんとソートされることが分かります。

一つのディレクトリのファイルリストの範囲

ここまでソートする範囲を手動で指定していましたが、ディレクトリの先頭のファイルと最後のファイルの位置を自動的に求めるにはどうしたら良いでしょうか。

ここで注意する必要があるのが、Diredは一つのバッファ内に複数のディレクトリを表示できるという点です(dired-insert-subdir等)。なのでその一つ一つのディレクトリ毎にファイルリストの範囲を求める必要があります。

最も単純なのはバッファ内の全行をスキャンしてファイルがある所とファイルが無いところを判別していくことです。

(defun my-dired-next-dir-files-region ()
  ;; ファイル名が無いところをスキップ
  (while (and (null (dired-move-to-filename))
              (= (forward-line) 0)))
  (unless (eobp)
    (let ((beg (line-beginning-position)))
      ;; ファイル名があるところをスキップ
      (while (and (dired-move-to-filename)
                  (= (forward-line) 0)))
      (cons beg (line-beginning-position)))))

行にファイル情報があるかどうかはdired-move-to-filenameが非nilを返すかどうかで判別できます。この方法はdired.el内で広く使われています。

そしてファイル情報が連続している範囲を見つけて返すのが上のコードになります。

全行をスキャンするのが嫌ならばdired-subdir-alistを利用することもできます。

(defun my-dired-next-dir-files-region ()
  ;; ファイル名が無いところをスキップ
  (while (and (null (dired-move-to-filename))
              (= (forward-line) 0)))
  (unless (eobp)
    (let ((beg (line-beginning-position)))
      ;; 次のディレクトリの先頭またはEOBへジャンプ
      (goto-char (dired-subdir-max))
      ;; ファイルがある所まで戻る
      (while (and (= (forward-line -1) 0)
                  (not (dired-move-to-filename))))
      ;; その次の行の先頭
      (forward-line)
      (cons beg (point)))))

dired-subdir-max関数は現在のポイントが指し示すディレクトリのバッファ内での末尾位置を返します。dired-subdir-alistには各ディレクトリの末尾の位置がマーカーとして保存されているので、全行をスキャンせずとも高速に割り出すことが出来ます。

ただ、その位置は正確に最後のファイルを指し示していないので、若干の後戻りスキャンが必要になります。

Diredバッファ内の全てのファイルをソートする

以上を組み合わせると次のようなコマンドを仕立てることが出来ます。

(defun my-dired-sort-by-file-score ()
  (interactive nil dired-mode)
  (widen)
  (goto-char (point-min))
  (let ((inhibit-read-only t))
    (while-let ((files-region (my-dired-next-dir-files-region)))
      (my-dired-sort-region-by-file-score (car files-region) (cdr files-region))
      (goto-char (cdr files-region)))))

どのタイミングでソートするか

手動でコマンドを実行したときだけソートされれば良いのであればこれで十分です。しかし何かのコマンドを実行したら常にソートされていて欲しい場合はどうしたら良いでしょうか。

当然Diredバッファが更新されるたびにどこかで自動的にソートする必要があります。

Diredのバッファ更新処理は大ざっぱに言って次のような流れを辿ります。

dired-noselect等
  → dired-revert
     → dired-readin (あるいはdired-insert-old-subdirs)
        → dired-readin-insert
            → dired-insert-directory
                → insert-directory
                    → file-name-handler(insert-directory) or
                       ls-lisp--insert-directory or
                       call-process(sh -c ls)
     → run-hook 'dired-after-readin-hook

最も無難なのがdired-after-readin-hookのタイミングです。このタイミングではバッファの更新が一通り終わって、上のコードで使用している全てのdired関数(dired-move-to-filenameやdired-subdir-max、dired-get-filename等)が正常に機能します。ただし、他の拡張もこのタイミングで様々な処理を行うことが多いため、競合には注意した方が良いでしょう。

他のタイミングとしては、一つのディレクトリを挿入するdired-insert-directoryやinsert-directoryの直後が考えられるでしょう。ただし、このタイミングでソートをするにはいくつか注意が必要です。

全てのdired関数が使用できない、あるいは正しく動作しないケースがある可能性がある。例えばdired-insert-directoryの直後ではdired-subdir-alistが構築されていないため、ディレクトリのファイルリストの範囲は全行スキャンしなければなりません。dired-move-to-filenameはおそらく大丈夫ですが、dired-get-filenameは問題がありそうです。
ファイル名のエスケープ処理に注意。バッファに挿入されるファイル名にはある種のエスケープ処理が施されています。なので、バッファからファイル名を取得するときにはエスケープを解除する処理が必要になります。dired-get-filenameはその辺りの処理をちゃんと行ってくれます。

ls-lispの中でソートするのは魅力的なアイデアでしょう。ls-lispはlsコマンドを使用せずEmacsの機能だけでlsをエミュレートするライブラリです。Windowsや最近ではAndroidでもデフォルトではls-lispが使われるようになっています。ls-lispは内部でdirectory-files-and-attributes関数を呼び出してファイルリストを取得しています。この関数は結果をLispのリストで返すため、うまく介入すればテキストに挿入される前にリストのレベルでソート処理を行えます。具体的にはls-lisp-handle-switches関数の直前はどうでしょうか。file-alistを独自にソートした上でswitchesにUオプションを追加してしまえばls-lispはそれ以上ソートを行いません。欠点はls-lispは使われない場合があるという点でしょう。UNIX環境でlsを使っている場合は当然として、trampなどでリモートディレクトリを参照している場合もls-lispが使われない可能性があります。

el-xmpでXMPプロパティに基づいてソート

というわけで、先日から作っているel-xmpでは、任意のXMPプロパティに基づいてdiredやimage-dired内でファイルやサムネイルをソートできるようになりました。

misohena/el-xmp: Emacs XMP (Extensible Metadata Platform) Library

xmp-setup.elを使用すれば ' S p でプロパティ名を指定してソート、 ' S - で解除できます。私は exif:DateTimeOriginal (撮影日)でソートしたいがためにこの機能を追加しました。

dired上でのソートは概ね上で説明したようなやり口で対処しています。

image-dired上では一つの画像がテキストプロパティが付いた1文字に対応するので、sort-subrを使用して1文字単位でソートしています。

あ、そうそう、結局キャッシュのためにSQLiteでデータベースを作成しました。ついでにサイドカーファイル無しでもプロパティを保存できるようにもしました(設定次第)。ただし、サイドカーファイルが無い分データベースのメンテナンスのために様々なコマンドを駆使する必要が出てきてしまっています。プロパティを付けた後にその対象ファイルを移動したり削除したりした場合、データベース内に記録されたプロパティは対象ファイルが存在しないいわば「はぐれ」状態になってしまいます。それを修正するためのコマンドを色々追加してあります。サイドカーファイルでもはぐれファイルになることはありますが比較的気がつきやすいですし対処もしやすいです。

2024-11-09 Emacs, org-mode, Windows

Windows Searchのデータベースを覗く(Windows11+SQLite+Emacs+org-modeで)

Windows SearchのデータベースはWindows11からSQLite3を使ったものに変更されているそうです。そんなことが色々検索をしていたときにふと目に入ったので実際にどうなっているのか調べてみました。

データベースは C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ にあります。Windows10だとここには Windows.edb というファイルを中心としたファイル群があるのですが、Windows11だと Windows.db 、 Windows-gather.db 、 Windows-usn.db というファイルがあります。

早速見て行きましょう……と言いたいところですが、私のメインPCいまだにWindows10なので、Windows11のノートPCからコピーしてきました。

sqlite3コマンドを使ってデータベースの中身を調べてみました。

テーブルの一覧

Windows.db

CatalogStorageManager
SystemIndex_1
SystemIndex_1_DATA_14   SystemIndex_1_OCC_14
SystemIndex_1_DATA_35   SystemIndex_1_OCC_35
SystemIndex_1_DATA_53   SystemIndex_1_OCC_53
SystemIndex_1_DATA_74   SystemIndex_1_OCC_74
SystemIndex_1_DATA_91   SystemIndex_1_OCC_91
SystemIndex_1_DATA_112  SystemIndex_1_OCC_112
SystemIndex_1_DATA_113  SystemIndex_1_OCC_113
SystemIndex_1_DATA_114  SystemIndex_1_OCC_114
SystemIndex_1_DATA_115  SystemIndex_1_OCC_115
SystemIndex_1_DATA_116  SystemIndex_1_OCC_116
SystemIndex_1_DATA_117  SystemIndex_1_OCC_117
SystemIndex_1_DATA_118  SystemIndex_1_OCC_118
SystemIndex_1_DATA_119  SystemIndex_1_OCC_119
SystemIndex_1_DATA_120  SystemIndex_1_OCC_120
SystemIndex_1_DATA_121  SystemIndex_1_OCC_121
SystemIndex_1_DATA_122  SystemIndex_1_OCC_122
SystemIndex_1_DATA_123  SystemIndex_1_OCC_123
SystemIndex_1_DATA_124  SystemIndex_1_OCC_124
SystemIndex_1_DATA_125  SystemIndex_1_OCC_125
SystemIndex_1_DATA_126  SystemIndex_1_OCC_126
SystemIndex_1_DATA_127  SystemIndex_1_OCC_127
SystemIndex_1_DATA_128  SystemIndex_1_OCC_128
SystemIndex_1_DATA_129  SystemIndex_1_OCC_129
SystemIndex_1_Properties
SystemIndex_1_PropertyStore
SystemIndex_1_PropertyStore_Metadata

Windows-gather.db

SystemIndex_Gthr
SystemIndex_GthrAppOwner
SystemIndex_GthrPth

Windows-usn.db

ChangeTracking

各テーブルの定義

どれが何だか分かっていませんが、とりあえず全部載せておきます。

Windows.db

CREATE TABLE CatalogStorageManager (
  CatalogName TEXT_TEXT(127) DEFAULT NULL,
  CatalogID   INTEGER        PRIMARY KEY,
  IsDeleted   LONG_INTEGER   DEFAULT 0,
    UNIQUE (CatalogName COLLATE "UNICODE_en-US" ASC, CatalogID ASC)
);

CREATE TABLE SystemIndex_1_Properties (
  IndexID    LONG_INTEGER DEFAULT NULL,
  PropertyID LONG_INTEGER DEFAULT NULL,
  Property   LONGBINARY_BLOB(2147483647) DEFAULT NULL,
    PRIMARY KEY (IndexID ASC, PropertyID ASC)
) WITHOUT ROWID;

CREATE TABLE SystemIndex_1_PropertyStore_Metadata (
  Id          INTEGER PRIMARY KEY,
  UniqueKey   TEXT    NOT NULL UNIQUE,
  Name        TEXT    NOT NULL,
  PropertyId  INTEGER NOT NULL,
  VariantType INTEGER NOT NULL,
  StorageType INTEGER NOT NULL,
  MaxSize     INTEGER,
  Flags       INTEGER NOT NULL
);

CREATE TABLE SystemIndex_1_PropertyStore (
  WorkId   INTEGER NOT NULL,
  ColumnId INTEGER NOT NULL,
  Value    BLOB NOT NULL,
    PRIMARY KEY (WorkId, ColumnId)
) WITHOUT ROWID;

CREATE TABLE SystemIndex_1 (
  IndexID          INTEGER PRIMARY KEY,
  IndexDescription LONGBINARY_BLOB(5104) DEFAULT NULL
);

CREATE TABLE SystemIndex_1_DATA_14 (
  Partition UNSIGNEDLONG_INTEGER DEFAULT NULL,
  szKey    LONGBINARY_BLOB(1664)  DEFAULT NULL,
  PID      UNSIGNEDSHORT_INTEGER  DEFAULT NULL,
  WidStart UNSIGNEDLONG_INTEGER   DEFAULT NULL,
  Data     LONGBINARY_BLOB(32686) DEFAULT NULL,
    PRIMARY KEY (Partition ASC, szKey ASC, PID ASC, WidStart ASC)
) WITHOUT ROWID;

CREATE TABLE SystemIndex_1_OCC_14 (OccID UNSIGNEDLONG_INTEGER DEFAULT NULL,
  OccPage LONGBINARY_BLOB(32650) DEFAULT NULL,
    PRIMARY KEY (OccID ASC)
) WITHOUT ROWID;


CREATE TABLE SystemIndex_1_DATA_35 (
  Partition UNSIGNEDLONG_INTEGER DEFAULT NULL,
  szKey LONGBINARY_BLOB(1664) DEFAULT NULL,
  PID UNSIGNEDSHORT_INTEGER DEFAULT NULL,
  WidStart UNSIGNEDLONG_INTEGER DEFAULT NULL,
  Data LONGBINARY_BLOB(32686) DEFAULT NULL,
    PRIMARY KEY (Partition ASC, szKey ASC, PID ASC, WidStart ASC)) WITHOUT ROWID;
CREATE TABLE SystemIndex_1_OCC_35 (
  OccID UNSIGNEDLONG_INTEGER DEFAULT NULL,
  OccPage LONGBINARY_BLOB(32650) DEFAULT NULL,
    PRIMARY KEY (OccID ASC)) WITHOUT ROWID;
/* 以下 35の部分が53,74,91,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129 と同様に続く */

Windows-gather.db

CREATE TABLE SystemIndex_GthrAppOwner (OwnerId UNSIGNEDLONG_INTEGER NOT NULL,
  UserSid         TEXT_TEXT(64)       NOT NULL,
  AppUserModelId  LONGTEXT_TEXT(130)  NOT NULL,
    PRIMARY KEY (OwnerId ASC)) WITHOUT ROWID;

CREATE TABLE SystemIndex_Gthr (ScopeID UNSIGNEDLONG_INTEGER NOT NULL,
  FileName                  LONGTEXT_TEXT(512) DEFAULT NULL,
  DocumentID                UNSIGNEDLONG_INTEGER NOT NULL,
  SDID                      UNSIGNEDLONG_INTEGER DEFAULT NULL,
  UserData                  LONGBINARY_BLOB(26214400) DEFAULT NULL,
  AppOwnerId                UNSIGNEDLONG_INTEGER DEFAULT NULL,
  LastModified              BINARY_BLOB(8) DEFAULT NULL,
  RequiredSIDs              BINARY_MULTI_BLOB(68) DEFAULT NULL,
  DeletedCount              LONG_INTEGER DEFAULT NULL,
  TransactionFlags          LONG_INTEGER DEFAULT NULL,
  TransactionExtendedFlags  LONG_INTEGER DEFAULT NULL,
  CrawlNumberCrawled        LONG_INTEGER DEFAULT NULL,
  StartAddressIdentifier    UNSIGNEDSHORT_INTEGER DEFAULT NULL,
  Priority                  UNSIGNEDBYTE_INTEGER DEFAULT NULL,
  RunTime                   UNSIGNEDLONG_INTEGER DEFAULT NULL,
  FailureUpdateAttempts     UNSIGNEDBYTE_INTEGER DEFAULT NULL,
  ClientID                  UNSIGNEDLONG_INTEGER DEFAULT NULL,
  LastRequestedRunTime      UNSIGNEDLONG_INTEGER DEFAULT NULL,
  StorageProviderId         LONGTEXT_TEXT(130) DEFAULT NULL,
  CalculatedPropertyFlags   UNSIGNEDLONG_INTEGER DEFAULT NULL,
    PRIMARY KEY (ScopeID ASC, FileName COLLATE "UNICODE_en-US_LINGUISTIC_IGNORECASE" ASC)) WITHOUT ROWID;

CREATE TABLE SystemIndex_GthrPth (Scope UNSIGNEDLONG_INTEGER DEFAULT NULL,
  Parent UNSIGNEDLONG_INTEGER DEFAULT NULL,
  Name LONGTEXT_TEXT(1000) DEFAULT NULL,
    PRIMARY KEY (Scope ASC)) WITHOUT ROWID;

Windows-usn.db

CREATE TABLE ChangeTracking (Client UNSIGNEDSHORT_INTEGER NOT NULL,
  Batch UNSIGNEDBYTE_INTEGER NOT NULL,
  Path LONGTEXT_TEXT(1000) DEFAULT NULL,
  CaseMap LONGTEXT_TEXT(1000) DEFAULT NULL,
  CurrentEntry BINARY_BLOB(56) DEFAULT NULL,
  MoveSource LONGTEXT_TEXT(1000) DEFAULT NULL,
  OldEntry BINARY_BLOB(56) DEFAULT NULL,
  MoveDestination LONGTEXT_TEXT(1000) DEFAULT NULL,
  RangeInformation LONGBINARY_BLOB(2147483647) DEFAULT NULL,
    PRIMARY KEY (Client ASC, Batch ASC, Path ASC)) WITHOUT ROWID;

プロパティ(メタデータ)に関する部分

全部くまなく解析するつもりも無いので、とりあえずパッと見一番分かりやすいファイルのプロパティに関する部分を見てみます。

SystemIndex_1_PropertyStore_Metadata

テーブル SystemIndex_1_PropertyStore_Metadata の定義は次のようになっています。

CREATE TABLE SystemIndex_1_PropertyStore_Metadata (
  Id          INTEGER PRIMARY KEY,
  UniqueKey   TEXT    NOT NULL UNIQUE,
  Name        TEXT    NOT NULL,
  PropertyId  INTEGER NOT NULL,
  VariantType INTEGER NOT NULL,
  StorageType INTEGER NOT NULL,
  MaxSize     INTEGER,
  Flags       INTEGER NOT NULL
);

実際の中身を見てみると次のようになっています。

select * from SystemIndex_1_PropertyStore_Metadata limit 40

Id	UniqueKey	Name	PropertyId	VariantType	StorageType	MaxSize	Flags
1	4703-System_Null	System.Null	4703	1	13	512	22
2	4583-System_Photo_GainControlText	System.Photo.GainControlText	4583	31	11	512	55
3	4224-System_Contact_BusinessHomePage	System.Contact.BusinessHomePage	4224	31	11	512	55
4	4435-System_IsIncomplete	System.IsIncomplete	4435	11	8		54
5	4449-System_ItemSubType	System.ItemSubType	4449	31	11	512	55
6	4412-System_History_SelectionCount	System.History.SelectionCount	4412	19	4		22
7	4413-System_History_TargetUrlHostName	System.History.TargetUrlHostName	4413	31	11	512	55
8	4622-System_SDID	System.SDID	4622	19	4		22
9	4359-System_DRM_IsProtected	System.DRM.IsProtected	4359	11	8		54
10	4345-System_Contact_SpouseName	System.Contact.SpouseName	4345	31	11	256	55
11	4358-System_DRM_IsDisabled	System.DRM.IsDisabled	4358	11	8		54
12	4361-System_DateAcquired	System.DateAcquired	4361	64	12	8	54
13	4434-System_IsFolder	System.IsFolder	4434	11	8		54
14	4513-System_Message_BccAddress	System.Message.BccAddress	4513	65	13	5120	119
15	4472-System_MIMEType	System.MIMEType	4472	31	11	512	55
16	4430-System_IsDeleted	System.IsDeleted	4430	11	8		54
17	4397-System_FilePlaceholderStatus	System.FilePlaceholderStatus	4397	19	4		22
18	4660-System_StorageProviderFileIdentifier	System.StorageProviderFileIdentifier	4660	31	11	512	54
19	4514-System_Message_BccName	System.Message.BccName	4514	65	13	5120	119
20	4661-System_StorageProviderFileVersion	System.StorageProviderFileVersion	4661	31	11	512	54
21	27F-System_Search_Rank	System.Search.Rank	27	3	3		10
22	4515-System_Message_CcAddress	System.Message.CcAddress	4515	65	13	5120	119
23	4407-System_GPS_LatitudeRef	System.GPS.LatitudeRef	4407	31	11	512	54
24	4370-System_Document_Contributor	System.Document.Contributor	4370	65	13	10240	119
25	28-System_Search_HitCount	System.Search.HitCount	28	3	3		6
26	4630F-System_Search_GatherTime	System.Search.GatherTime	4630	64	12	8	58
27	4516-System_Message_CcName	System.Message.CcName	4516	65	13	5120	119
28	4256-System_Contact_HomeAddress1Street	System.Contact.HomeAddress1Street	4256	31	11	2048	55
29	4624-System_Search_AccessCount	System.Search.AccessCount	4624	19	4		22
30	4440-System_ItemFolderPathDisplay	System.ItemFolderPathDisplay	4440	31	11	65536	51
31	4253-System_Contact_HomeAddress1Locality	System.Contact.HomeAddress1Locality	4253	31	11	2048	55
32	4241-System_Contact_EmailAddress2	System.Contact.EmailAddress2	4241	31	11	256	55
33	4447-System_ItemPathDisplay	System.ItemPathDisplay	4447	31	11	65536	51
34	4255-System_Contact_HomeAddress1Region	System.Contact.HomeAddress1Region	4255	31	11	2048	55
35	4632-System_Search_LastIndexedTotalTime	System.Search.LastIndexedTotalTime	4632	5	7		22
36	4252-System_Contact_HomeAddress1Country	System.Contact.HomeAddress1Country	4252	31	11	2048	55
37	4254-System_Contact_HomeAddress1PostalCode	System.Contact.HomeAddress1PostalCode	4254	31	11	2048	55
38	4174-System_Communication_AccountName	System.Communication.AccountName	4174	31	11	512	55
39	33-System_ItemUrl	System.ItemUrl	33	31	11	65536	51
40	4436-System_IsRead	System.IsRead	4436	11	8		54

select count(*) from SystemIndex_1_PropertyStore_Metadata

全部で605行ありました。(Windows Searchは拡張可能な仕組みなので環境によって異なると思います)

これらはプロパティの種類に関する情報でしょう。プロパティのID、名前、型といった情報が見て取れます。

Nameに書かれている文字列には見覚えがあります。Windows Search SQLで検索したときにはこのプロパティ名を列名として指定しました(Windows Search SQL 構文の概要 - Win32 apps | Microsoft Learn)。

VariantTypeはWindows開発ではおなじみのやつですね。Windows SDKのWTypes.hから抜粋。

enum VARENUM
    {   VT_EMPTY    = 0,
    VT_NULL = 1,
    VT_I2   = 2,
    VT_I4   = 3,
    VT_R4   = 4,
    VT_R8   = 5,
    VT_CY   = 6,
    VT_DATE = 7,
    VT_BSTR = 8,
    VT_DISPATCH = 9,
    VT_ERROR    = 10,
    VT_BOOL = 11,
    VT_VARIANT  = 12,
    VT_UNKNOWN  = 13,
    VT_DECIMAL  = 14,
    VT_I1   = 16,
    VT_UI1  = 17,
    VT_UI2  = 18,
    VT_UI4  = 19,
    VT_I8   = 20,
    VT_UI8  = 21,
    VT_INT  = 22,
    VT_UINT = 23,
    VT_VOID = 24,
    VT_HRESULT  = 25,
    VT_PTR  = 26,
    VT_SAFEARRAY    = 27,
    VT_CARRAY   = 28,
    VT_USERDEFINED  = 29,
    VT_LPSTR    = 30,
    VT_LPWSTR   = 31,
    VT_RECORD   = 36,
    VT_INT_PTR  = 37,
    VT_UINT_PTR = 38,
    VT_FILETIME = 64,
    VT_BLOB = 65,
    VT_STREAM   = 66,
    VT_STORAGE  = 67,
    VT_STREAMED_OBJECT  = 68,
    VT_STORED_OBJECT    = 69,
    VT_BLOB_OBJECT  = 70,
    VT_CF   = 71,
    VT_CLSID    = 72,
    VT_VERSIONED_STREAM = 73,
    VT_BSTR_BLOB    = 0xfff,
    VT_VECTOR   = 0x1000,
    VT_ARRAY    = 0x2000,
    VT_BYREF    = 0x4000,
    VT_RESERVED = 0x8000,
    VT_ILLEGAL  = 0xffff,
    VT_ILLEGALMASKED    = 0xfff,
    VT_TYPEMASK = 0xfff
    } ;

こいつをEmacs Lispから引けるようにしておくと便利でしょう。

(defvar my-vt-alist
  '((0 . EMPTY) (1 . NULL) (2 . I2) (3 . I4) (4 . R4) (5 . R8) (6 . CY)
    (7 . DATE) (8 . BSTR) (9 . DISPATCH) (10 . ERROR) (11 . BOOL)
    (12 . VARIANT) (13 . UNKNOWN) (14 . DECIMAL) (16 . I1) (17 . UI1)
    (18 . UI2) (19 . UI4) (20 . I8) (21 . UI8) (22 . INT) (23 . UINT)
    (24 . VOID) (25 . HRESULT) (26 . PTR) (27 . SAFEARRAY) (28 . CARRAY)
    (29 . USERDEFINED) (30 . LPSTR) (31 . LPWSTR) (36 . RECORD) (37 . INT_PTR)
    (38 . UINT_PTR) (64 . FILETIME) (65 . BLOB) (66 . STREAM) (67 . STORAGE)
    (68 . STREAMED_OBJECT) (69 . STORED_OBJECT) (70 . BLOB_OBJECT) (71 . CF)
    (72 . CLSID) (73 . VERSIONED_STREAM) (#xfff . BSTR_BLOB) (#x1000 . VECTOR)
    (#x2000 . ARRAY) (#x4000 . BYREF) (#x8000 . RESERVED) ))

(defun my-vt-name (vt-id)
  (alist-get vt-id my-vt-alist))
;; TEST: (my-vt-name 31) => LPWSTR

これをorg-modeの表にcolumn formulaとして設定すれば次のような表も簡単に生成できます。

| Id | Name                                  | VariantType | (VT Name)| StorageType | MaxSize | Flags |
|----+---------------------------------------+-------------+----------+-------------+---------+-------|
| 25 | 'System.Search.HitCount'              |           3 | I4       |           3 |    NULL |     6 |
| 26 | 'System.Search.GatherTime'            |          64 | FILETIME |          12 |       8 |    58 |
| 27 | 'System.Message.CcName'               |          65 | BLOB     |          13 |    5120 |   119 |
| 28 | 'System.Contact.HomeAddress1Street'   |          31 | LPWSTR   |          11 |    2048 |    55 |
| 29 | 'System.Search.AccessCount'           |          19 | UI4      |           4 |    NULL |    22 |
| 30 | 'System.ItemFolderPathDisplay'        |          31 | LPWSTR   |          11 |   65536 |    51 |
| 31 | 'System.Contact.HomeAddress1Locality' |          31 | LPWSTR   |          11 |    2048 |    55 |
#+TBLFM: $4='(my-vt-name $3);L

さらにEmacs 29で加わった組み込みSQLite機能を使ってプロパティの Id から型情報を割り出せるようにしておきましょう。

(defvar my-wds-property-alist
  (let ((db (sqlite-open "Windows.db")))
    (unwind-protect
        (sqlite-select db "select * from SystemIndex_1_PropertyStore_Metadata")
      (sqlite-close db))))

(defun my-wds-property-name (id) (nth 2 (assq id my-wds-property-alist)))
(defun my-wds-property-vt (id) (nth 4 (assq id my-wds-property-alist)))
(defun my-wds-property-vt-name (id) (my-vt-name (my-wds-property-vt id)))
;; TEST: (cons (my-wds-property-name 30) (my-wds-property-vt-name 30)) => ("System.ItemFolderPathDisplay" . LPWSTR)

後はMaxSizeは良いとして、StorageTypeやFlagsは私ではすぐには思い当たらないです。

SystemIndex_1_PropertyStore

肝心要の実際のプロパティ値はどこにあるのかというと SystemIndex_1_PropertyStore というテーブルにあります。

定義は次の通り。

CREATE TABLE SystemIndex_1_PropertyStore (
  WorkId   INTEGER NOT NULL,
  ColumnId INTEGER NOT NULL,
  Value    BLOB NOT NULL,
    PRIMARY KEY (WorkId, ColumnId)
) WITHOUT ROWID;

実際の中身ですが、こちらはBLOBが入っているせいで文字化けしたので .dump した結果から抜粋しました。

WorkId	ColumnId	Value
1	13	1
1	17	6
1	26	X'2925c18d31b6d901'
1	29	0
1	30	'C:\ProgramData\Microsoft\Windows'
1	33	'C:\ProgramData\Microsoft\Windows\スタートメニュー'
1	35	0.0
1	39	'file:C:/ProgramData/Microsoft/Windows/Start Menu'
1	188	X'00ea2bc7d261d801'
1	295	0
1	306	0
1	308	X'00ea2bc7d261d801'
1	342	X'66006f006c00640065007200'
1	349	X'5600f5bf02b2cf41'
1	376	'file'
1	414	'Windows'
1	420	'ファイルフォルダー'
1	432	'スタートメニュー'
1	438	8209
1	441	X'3868c8f55df9d801'
1	444	X'00ea2bc7d261d801'
1	445	X'00b352c6d261d801'
1	448	X'3868c8f55df9d801'
1	449	X'e3efa68d31b6d901'
1	462	'スタートメニュー'
1	463	'フォルダー'
1	464	'Windows (C:\ProgramData\Microsoft)'
1	466	'スタートメニュー'
1	470	'スタートメニュー'
1	564	'スタートメニュー (C:\ProgramData\Microsoft\Windows)'
1	567	'Directory'
1	581	'Start Menu'
1	585	'Start Menu'
1	587	1887437183
1	596	X'28126512'
1	597	X'ba0a9bc7980a1de2357c65c73ae167b6'
2	13	1
2	17	6
2	26	X'b7a34f8331b6d901'
2	29	0
2	30	'C:\'
2	33	'C:\ユーザー'
2	35	0.109375
2	39	'file:C:/Users'

以降もこの調子で1行に1つのプロパティが大量に並んでいます。

WorkId というのがオブジェクトの識別番号のようです。

ColumnId は先ほど見たテーブル SystemIndex_1_PropertyStore_Metadata の Id 列に対応しています。どうも旧形式のデータベースでは一つの行が一つのファイルで、プロパティは一つ一つの列だったのだとか。SQLiteに移行したときに設計を変えたようです。プロパティは存在しないものが多いのでプロパティを列にするとnullだらけになってしまいます。それでもインタフェースとしてはそちらの方が直感的ですよね。

Value はプロパティの値です。テーブルの定義上ではBLOB型(Value BLOB NOT NULL)となっているのですが、実際に格納されている型は様々なようで、 SystemIndex_1_PropertyStore_Metadata の VariantType 列に書かれている形式で格納されているみたいです。

これも先ほどやったようにorg-modeの表でプロパティ名と型名を補ってみると次のようになります。

| WorkId | ColumnId | (PropertyName)                     | (VTName) | Value                                                |
|--------+----------+------------------------------------+----------+------------------------------------------------------|
|      1 |       13 | System.IsFolder                    | BOOL     | 1                                                    |
|      1 |       17 | System.FilePlaceholderStatus       | UI4      | 6                                                    |
|      1 |       26 | System.Search.GatherTime           | FILETIME | X'2925c18d31b6d901'                                  |
|      1 |       29 | System.Search.AccessCount          | UI4      | 0                                                    |
|      1 |       30 | System.ItemFolderPathDisplay       | LPWSTR   | 'C:\ProgramData\Microsoft\Windows'                   |
|      1 |       33 | System.ItemPathDisplay             | LPWSTR   | 'C:\ProgramData\Microsoft\Windows\スタート メニュー' |
|      1 |       35 | System.Search.LastIndexedTotalTime | R8       | 0.0                                                  |
|      1 |       39 | System.ItemUrl                     | LPWSTR   | 'file:C:/ProgramData/Microsoft/Windows/Start Menu'   |
|      1 |      188 | System.DateImported                | FILETIME | X'00ea2bc7d261d801'                                  |
|      1 |      295 | System.IsAttachment                | BOOL     | 0                                                    |
|      1 |      306 | System.IsEncrypted                 | BOOL     | 0                                                    |
|      1 |      308 | System.ItemDate                    | FILETIME | X'00ea2bc7d261d801'                                  |
|      1 |      342 | System.Kind                        | BLOB     | X'66006f006c00640065007200'                          |
|      1 |      349 | System.ThumbnailCacheId            | UI8      | X'5600f5bf02b2cf41'                                  |
|      1 |      376 | System.Search.Store                | LPWSTR   | 'file'                                               |
|      1 |      414 | System.ItemFolderNameDisplay       | LPWSTR   | 'Windows'                                            |
|      1 |      420 | System.ItemTypeText                | LPWSTR   | 'ファイル フォルダー'                                |
|      1 |      432 | System.ItemNameDisplay             | LPWSTR   | 'スタート メニュー'                                  |
#+TBLFM: $3='(my-wds-property-name $2);L::$4='(my-wds-property-vt-name $2);L

System.ItemUrl が完全なパスを表しています。 System.ItemPathDisplay は Display と付いているように一部のファイル名がローカライズされてしまうので使いづらいんですよね。以前EmacsからWindows Searchするものを作ったときに困った記憶があります。

WorkId=1はスタートメニューフォルダを表しているようですが、あまりピンとこないので何か写真のプロパティを取得してみましょう。

まずはファイルを検索。といってもこのデータベースはノートPCのものなのでインデックスの範囲は極力絞ってありますし、その範囲に写真は入っていません。とりあえずテスト画像を作ってPicturesフォルダに入れて認識させ、再度データベースをメインPCにコピー。そして次のSQLで検索。

select * from SystemIndex_1_PropertyStore where ColumnId=39 and Value LIKE 'file:C:/Users/USERNAME/Pictures/%.jpg';

WorkId	ColumnId	Value
3338	39	file:C:/Users/USERNAME/Pictures/PXL_20241025_040712150.jpg

新しい写真の WorkId は 3338 になったようです。これをキーに全プロパティを取得してみましょう。

select * from SystemIndex_1_PropertyStore where WorkId=3338;

……と、実際やってみましたが、これもBLOBが文字化けしてしまったのでダンプしたデータから抜粋します(ついでにプロパティ名と型名も補っておきます)。

WorkId	ColumnId	(PropertyName)	(VTName)	Value
3338	13	System.IsFolder	BOOL	0
3338	15	System.MIMEType	LPWSTR	'image/jpeg'
3338	17	System.FilePlaceholderStatus	UI4	6
3338	23	System.GPS.LatitudeRef	LPWSTR	'N'
3338	26	System.Search.GatherTime	FILETIME	X'b183b6f95232db01'
3338	29	System.Search.AccessCount	UI4	0
3338	30	System.ItemFolderPathDisplay	LPWSTR	'C:\ユーザー\USERNAME\ピクチャ'
3338	33	System.ItemPathDisplay	LPWSTR	'C:\ユーザー\USERNAME\ピクチャ\PXL_20241025_040712150.jpg'
3338	35	System.Search.LastIndexedTotalTime	R8	0.0
3338	39	System.ItemUrl	LPWSTR	'file:C:/Users/USERNAME/Pictures/PXL_20241025_040712150.jpg'
3338	47	System.ItemParticipants	BLOB	X'5400610072006f000000480061006e0061006b006f00'
3338	60	System.Photo.FlashText	LPWSTR	'フラッシュなし (強制)'
3338	75	System.Photo.ExposureTime	R8	0.00665899999999999998
3338	85	System.Photo.FNumber	R8	2.20000000000000017
3338	93	System.FileOwner	LPWSTR	'MYCOMPUTER\USERNAME'
3338	110	System.Image.HorizontalSize	UI4	4080
3338	114	System.Photo.MeteringModeText	LPWSTR	'中央重点測光'
3338	116	System.Image.VerticalSize	UI4	3072
3338	122	System.Image.HorizontalResolution	R8	96.0
3338	126	System.Image.VerticalResolution	R8	96.0
3338	130	System.Image.BitDepth	UI4	24
3338	143	System.Photo.WhiteBalance	UI4	0
3338	153	System.Image.Dimensions	LPWSTR	'‪4080 x 3072‬'
3338	172	System.GPS.Date	FILETIME	X'0020d86ad526db01'
3338	185	System.GPS.LongitudeRef	LPWSTR	'E'
3338	188	System.DateImported	FILETIME	X'00a2f2dd5032db01'
3338	204	System.Media.ClassPrimaryID	LPWSTR	'{6FB2E74A-B8CB-40BB-93F3-FAC5F00FA203}'
3338	270	System.Media.DlnaProfileID	BLOB	X'4a005000450047005f004c0052004700'
3338	279	System.NotUserContent	BOOL	0
3338	287	System.Photo.FocalLengthInFilm	UI2	16
3338	290	System.Photo.OrientationText	LPWSTR	'標準'
3338	294	System.ItemAuthors	BLOB	X'5400610072006f000000480061006e0061006b006f00'
3338	295	System.IsAttachment	BOOL	0
3338	306	System.IsEncrypted	BOOL	0
3338	308	System.ItemDate	FILETIME	X'60bb495e9326db01'
3338	313	System.Photo.CameraManufacturer	LPWSTR	'Google'
3338	316	System.Photo.CameraModel	LPWSTR	'Pixel 7'
3338	322	System.Photo.Orientation	UI2	1
3338	342	System.Kind	BLOB	X'7000690063007400750072006500'
3338	349	System.ThumbnailCacheId	UI8	X'e7698c11b08a5156'
3338	356	System.Photo.ShutterSpeed	R8	7.23000000000000042
3338	360	System.VolumeId	CLSID	X'89cae2bf542043d99ecc540d185f11f5'
3338	361	System.Photo.Aperture	R8	2.2799999999999998
3338	366	System.Photo.ExposureBias	R8	0.0
3338	370	System.GPS.LatitudeDecimal	R8	35.6262194166666645
3338	374	System.Photo.SubjectDistance	R8	4294967295.0
3338	376	System.Search.Store	LPWSTR	'file'
3338	377	System.Photo.MeteringMode	UI2	2
3338	384	System.Photo.Flash	UI1	16
3338	386	System.Photo.FocalLength	R8	2.35000000000000008
3338	387	System.Photo.ExposureProgram	UI4	2
3338	396	System.Photo.ISOSpeed	UI2	470
3338	407	System.ContentType	LPWSTR	'image/jpeg'
3338	414	System.ItemFolderNameDisplay	LPWSTR	'ピクチャ'
3338	424	System.Title	LPWSTR	'Senburi near Icchodaira'
3338	429	System.Author	BLOB	X'5400610072006f000000480061006e0061006b006f00'
3338	430	System.Keywords	BLOB	X'530065006e0062007500720069000000540061006b0061006f00'
3338	432	System.ItemNameDisplay	LPWSTR	'PXL_20241025_040712150.jpg'
3338	434	System.FileExtension	LPWSTR	'.jpg'
3338	436	System.Size	UI8	X'bfdb4d0000000000'
3338	438	System.FileAttributes	UI4	32
3338	441	System.DateModified	FILETIME	X'00e4a1b35232db01'
3338	444	System.Document.DateCreated	FILETIME	X'00a2f2dd5032db01'
3338	445	System.DateCreated	FILETIME	X'ce669cdd5032db01'
3338	448	System.Document.DateSaved	FILETIME	X'00e4a1b35232db01'
3338	449	System.DateAccessed	FILETIME	X'919582f95232db01'
3338	459	System.Photo.ProgramModeText	LPWSTR	'標準のプログラム'
3338	461	System.ApplicationName	LPWSTR	'HDR+ 1.0.641377693zd'
3338	462	System.ItemName	LPWSTR	'PXL_20241025_040712150.jpg'
3338	463	System.KindText	LPWSTR	'ピクチャ'
3338	464	System.ItemFolderPathDisplayNarrow	LPWSTR	'ピクチャ (C:\ユーザー\USERNAME)'
3338	466	System.ItemNameDisplayWithoutExtension	LPWSTR	'PXL_20241025_040712150'
3338	469	System.GPS.LongitudeDecimal	R8	139.230677777777771
3338	477	System.GPS.Latitude	BLOB	X'000000000080414000000000008042400cb81e85eb314140'
3338	478	System.Photo.MaxAperture	R8	2.2799999999999998
3338	482	System.GPS.Longitude	BLOB	X'00000000006061400000000000002a40f91f85eb51384940'
3338	483	System.Photo.TagViewAggregate	BLOB	X'530065006e0062007500720069000000540061006b0061006f00'
3338	491	System.Photo.ExposureProgramText	LPWSTR	'標準'
3338	493	System.Photo.SaturationText	LPWSTR	'標準'
3338	520	System.Photo.WhiteBalanceText	LPWSTR	'自動'
3338	557	System.ComputerName	LPWSTR	'MYCOMPUTER'
3338	564	System.ItemPathDisplayNarrow	LPWSTR	'PXL_20241025_040712150 (C:\ユーザー\USERNAME\ピクチャ)'
3338	567	System.ItemType	LPWSTR	'.jpg'
3338	572	System.Photo.SharpnessText	LPWSTR	'標準'
3338	579	System.Photo.DateTaken	FILETIME	X'60bb495e9326db01'
3338	580	System.Photo.ContrastText	LPWSTR	'標準'
3338	581	System.FileName	LPWSTR	'PXL_20241025_040712150.jpg'
3338	584	System.Photo.DigitalZoom	R8	0.0
3338	585	System.ParsingName	LPWSTR	'PXL_20241025_040712150.jpg'
3338	587	System.SFGAOFlags	UI4	1077936503
3338	596	InvertedOnlyPids	BLOB	X'28126512'
3338	597	InvertedOnlyMD5	BLOB	X'0ace870441760f5a3225b96131c5f0ba'

様々なメタデータが格納されていることが分かります。

例えば System.Title を見ると 'Senburi near Icchodaira' となっています。この写真は先日高尾山でセンブリの花を撮ったものだったので、あらかじめexiftoolでテスト的にタイトルを付けておいたのでした。データベースの中でどうなっているのか知りたかったので。x-default(英語)、英語、日本語と三つの言語でタイトルを付けておいたのですが、x-default(英語)のみが収集されたみたいです。

System.Author を見るとBLOB型で X'5400610072006f000000480061006e0061006b006f00' となっています。BLOBと言っていますがどう見てもWSTR(UTF-16LE)ですよね。次のようなEmacs Lispを使えばデコード出来ます。

(defun my-decode-wstr (hexstr)
  (decode-coding-string
   (apply 'unibyte-string
          (cl-loop for i below (length hexstr) by 2
                   collect (string-to-number (substring hexstr i (+ i 2)) 16)))
   'utf-16le))

実際にデコードすると次のようになります。

(my-decode-wstr "5400610072006f000000480061006e0061006b006f00")

"Taro\0Hanako"

あらかじめexiftoolで作者(dc:creator)をTaroとHanakoの二名にしておいたのですが、NUL文字区切りで記録されていました。なるほどだからBLOBにしているのかもしれませんね。(追記:SQLiteは文字列にNUL文字を含めることができるそうです。一部の文字列関数が最初のNUL文字までしか認識しないといった制限はあるみたいですが。なので必ずしもNULが入っているからといってBLOBにする必要は無かったかもしれません。参考:NUL Characters In Strings - sqlite.org)

System.Keywords も同様にデコードしてみましょう。

(my-decode-wstr "530065006e0062007500720069000000540061006b0061006f00")

"Senburi\0Takao"

こちらもSenburiとTakaoの二つをdc:subjectに設定しておいたのですが、このようにNUL文字区切りで記録されていました。

GPS情報なんかも格納されているので是非場所を割り出してみてください。何かプレゼントでも隠しておけたら面白かったのですが(笑)　って、Decimalバージョンもあるのね。

というわけで、最低限プロパティの部分がどのように格納されているかは分かったと思います。

org-mode文書にSQLiteのクエリと実行結果を埋め込む方法

ちなみに今回の記事はorg-modeのSQLiteソースコードブロックを使用して書きました。詳しい書き方については次のページをご覧下さい。

SQLite Source Code Blocks in Org Mode

上の方では実際に次のように書いていました。

#+begin_src sqlite :db Windows.db :header :exports both :eval no-export
select * from SystemIndex_1_PropertyStore_Metadata limit 40
#+end_src

#+RESULTS:
| Id | UniqueKey         | Name         | PropertyId | VariantType | StorageType | MaxSize | Flags |
|  1 | 4703-System_Null  | System.Null  |       4703 |           1 |          13 |     512 |    22 |
...略...

:header を付けると見出しが付きます(デフォルトでは付きません)。

デフォルトはコードのみのエクスポートだったので、 :exports both を指定しました。

エクスポート時に勝手に評価しないように :eval no-export を指定しました。

Emacs Lispからsqliteにアクセスする

また上の方でも少し使いましたが、Emacs 29から組み込みのsqlite関数が入っています。

Database (GNU Emacs Lisp Reference Manual)

使用例:

(let ((db (sqlite-open "~/test-sqlite.db")))
  (unwind-protect
      (progn
        ;; ファイル情報テーブルを作る
        (sqlite-execute
         db
         "create table if not exists files (
          id integer primary key,
          path text not null unique,
          mod_time real not null,
          size integer not null)")

        ;; カレントディレクトリにある全ファイルのフルパス、更新日時、サイズを挿入する
        ;; (本当は一文でやった方が速いみたい values (?,?,?),(?,?,?)...)
        (cl-loop for (file . attrs) in (directory-files-and-attributes "." t)
                 do (sqlite-execute
                     db
                     "insert or replace into files (path,mod_time,size) values (?,?,?)"
                     (list file
                           (float-time (file-attribute-modification-time attrs))
                           (file-attribute-size attrs))))

        ;; 更新日時降順に ((パス 更新日時)...) を取得する
        (sqlite-execute
         db
         "select path,datetime(mod_time,'unixepoch','localtime') from files where mod_time >= ? order by mod_time desc"
         ;; 過去30日分取得
         (list (- (float-time) (* 30 24 60 60)))))
    ;; エラーが出てもちゃんと閉じるよ(しなくてもGCのタイミングで閉じるけど)
    (sqlite-close db)))

……というわけで色々やってみましたが、終わってみるとこれはEmacsのSQLite関連機能を学ぶためのちょうど良いチュートリアルでした。

2024-11-06 el-xmp, Emacs

XMPメタデータエディタ、ファイル形式、EXIF、データベース

前々回、前回に引き続き、el-xmpの話。

xmp-editor.elを追加してプロパティを一括で編集できるようになりました。

Diredからなら xmp-dired-do-edit-properties コマンド(' e p)、その他のファイル名が検出できるところからなら xmp-edit-file-properties コマンドで次のような編集バッファを表示できます。

image-diredには image-dired-dired-edit-comment-and-tags というコマンドがあってこれと似たようなことができますが「コメント」と「タグ」のみの編集となっています。こちらは好きなだけ編集項目を増やせるのが良い所です(ユーザーが独自のプロパティを定義することも可能です)。そもそも対象は画像ファイルに限定されません。サムネイルは画像ファイルの時だけimage-diredの仕組みを利用して表示しています。

デフォルトではカスタマイズ変数で指定されているプロパティのみが表示されますが、プレフィックス引数(C-u 0 ' e p)を使うかまたは末尾が-allとなっているコマンド(' e a)を使えばel-xmpが認識できる全てのプロパティを表示させることもできます。

上のスクリーンショットは認識できる全プロパティが表示されていますが、そこには元々EXIFで記録されているカメラの情報も入っています。

今回xmp-tiff.elとxmp-exif.elを追加したことによってEXIFを読み取ることも可能になりました。JPEGスキャナはAPP1セグメントのうちEXIFとXMPパケットの両方を読み取ります。読み取ったEXIFはXMPに変換されて同一ファイル内にあるXMPパケットとマージされ、元々一つのXMPパケットだったかのように扱われます。EXIFの読み取りについてはEmacs内にすでにexif.elがありますが以前調べたように多少問題があることが分かっていた(特にエンディアンバグはまだ残っているようです)ので独自に実装しました。

ついでにTIFF画像にも対応し、こちらもJPEGと同様EXIFとXMPパケットの両方を読み取ってマージします。いくつかのカメラのRAW画像形式はTIFFベースだったので全く同じコードで対応できました。とりあえずソニーのARW、キヤノンのCR2(CR3はISO BMFFベースらしいです)、ニコンのNEFが読み込めたので、それらの拡張子ではTIFFスキャナが使われるようにしました。

PDFはファイルの中に複数のXMPパケットが混在していることが多いので汎用的なパケットスキャンではかなり高い確率で間違ったXMPパケットを読み取ってしまいます。そこでxmp-pdf.elを追加してPDFもちゃんとスキャンするように頑張ってみたのですが圧縮や暗号に対応できず読めないファイルが多く残る結果となってしまいました。その代わりpdfinfoコマンドによるXMPの抽出に対応したので、必要であればインストールしてください。pdf-toolsを入れていれば多分入っているんじゃないかと思います。無理にEmacs Lispで実装するよりもこっちの方が良いでしょう。

EXIFが読めるようになったので撮影日時が取得できるようになりました。Emacs Lispのコードレベルでは (xmp-pvalue-as-text (xmp-get-file-property "example.jpg" (xmp-xml-ename xmp-exif: "DateTimeOriginal"))) で取得できます。

ちなみにEXIFが持つ基本的な日時には DateTime 、 DateTimeOriginal 、 DateTimeDigitized があり、 DateTime は更新日時(xmp:ModifyDateにマップされる)、 DateTimeOriginal は元々の撮影日時、 DateTimeDigitized はデジタル化(要するにフィルムであればスキャンした日時。デジカメであれば撮影日時と同じ)となっているようです。以前のEXIF Metadata規格では DateTimeDigitized が xmp:CreateDate にマップされていたようですが、現在は exif:DateTimeDigitized にマップされています。「作成日」というのはやや曖昧な概念と言えるでしょう。

撮影日時が読めるのであればファイルを撮影日時順にソートしたくなります。しかしDiredを開くたびに全ファイルからメタデータを読み取っていては時間がかかりすぎますから、断然キャッシュが重要になってきます。現在はEmacs起動中のみ有効なキャッシュ機構がありますが、Emacsを終了させたら消えてしまいます。やはり永続的なキャッシュ機構が必要です。

また、メタデータを編集した際の保存先も現在はサイドカーファイルのみですが、 ~/.emacs.d/ の中に隠しておく選択肢もやはり欲しい所です。ディレクトリやファイルの種類によって保存先を変えられるのが理想でしょう。

となるとやはり何らかのデータベースのような仕組みが必要になります。

image-diredのように一つのファイル( ~/.emacs.d/image-dired/.image-dired_db )に全ファイル分のメタデータをテキストで保存するのは嫌でしょう。一つ編集するたびに全部書き直さなければなりません。対象ファイルが増えたら増えた分だけ全ての場所で重くなっていきます。

サムネイルと同じようにメタデータも ファイル毎 に ~/.emacs.d/ 内に保存してしまうと言う手もあるでしょう。しかしいくら一つ一つのメタデータファイルを単純化してもディレクトリを開くときに多数のファイルにアクセスするのは効率が悪いです。

ディレクトリ毎 にメタデータファイルを作成して ~/.emacs.d/ の下に保存しておくというのは比較的バランスが取れた方法かもしれません。ファイル名はディレクトリのフルパスを何らかの規則でエンコードしたものにすれば良いでしょう。

後はちゃんとしたデータベースを使うことですね。今のEmacsにはSQLiteが組み込まれているので(コンパイルオプション次第ですがWindows版公式ビルドでちゃんと使えます)、それを使うのも良さそうです。Android OSが似たようなことをすでにしていますね。あれは端末の中にあるメディアファイルのメタデータをスキャンしてSQLiteのデータベースに保持していつでも素早く情報を取得できるようにしています。それと同じような感じにすれば良さそうです。とは言えデータベースの設計は悩み所が多そうな気がします。何を保存するか、何で検索できるようにするか。例えばdc:subject内の一つ一つの主題で高速に検索できるようになっているべきか、等。一つのプロパティが単純な一つのText型ならまだ良いのですが、Array(Seq,Seq,Alt)やStruct等の構造を持っているととたんに面倒になります。単純にデータの保存先と割り切るなら最悪S式をそのまま突っ込んでしまえば良いのでしょうけど……。まぁ、自分の必要性に応じてできるだけ簡単な方法を使いましょう。

2024-10-21 el-xmp, Emacs

XMPメタデータをimage-dired内で使う

前回に引き続き、el-xmpの話。

xmp-image-dired.elを追加し、image-dired内で画像ファイルのメタデータを操作できるようにしました。具体的には次のことが可能です。

マークしたファイルまたは現在のポイントが指すファイルに対するプロパティの設定
現在のポイントが指すファイルからのプロパティの取得
サムネイルのプロパティ値に基づくフィルタ(一時的な非表示)

現在対応しているプロパティは次の通りです。

xmp:Rating
xmp:Label
dc:subject
dc:title
dc:description
dc:creators

image-diredにはタグやコメントを付ける機能が既にありますが、それでは物足りないという人のためのものです(標準機能のタグやコメントは.emacs.d内に独自形式で保存されるので他のアプリと連携できないという問題もあります)。

参考までに設定例としてxmp-setup.elを追加したので、それを使えば簡単にこれらの機能をdiredとimage-diredの両方から利用できるようになります(フィルタはimage-diredのみ。diredではマーク操作が可能)。次のキーが使えるようになります。

プロパティ設定
- ' s r : Set Rating
- ' s l : Set Label
- ' s s : Set Subjects
- ' a s : Add Subjects
- ' r s : Remove Subjects
- ' s t : Set Title
- ' s d : Set Description
- ' s c : Set Creators
プロパティ取得
- ' g a : Get All properties
- ' g r : Get Rating
- ' g l : Get Label
- ' g s : Get Subjects
- ' g t : Get Title
- ' g d : Get Description
- ' g c : Get Creators
マーク(diredのみ)
- ' m r : Mark by Rating
- ' m l : Mark by Label
- ' m s : Mark by Subjects
- ' m t : Mark by Title
- ' m d : Mark by Description
- ' m c : Mark by Creator
フィルタ(image-diredのみ)
- ' f r : Filter by Rating
- ' f l : Filter by Label
- ' f s : Filter by Subjects
- ' f - : Clear Filter

例えば ' s r でレーティングを設定して、 ' f r で特定のレーティングのみを表示する、といった使い方ができます。 ' f - でフィルタを解除します。HydraやらTransientやらで使いやすくした方が良いと思いますが、とりあえず設定例ということで。

ここで言うLabel(xmp:Labelプロパティ)は、ファイルに対して一つだけ設定できる短い文字列です。定義については https://developer.adobe.com/xmp/docs/XMPNamespaces/xmp/ を参照してください。Adobe Lightroom等ではカラーラベルを設定するとこのプロパティにRedやBlueといった色名が設定されるらしいです。

Subject(dc:subject)は、ファイルの主題を表すキーワード等のリストです。定義については https://developer.adobe.com/xmp/docs/XMPNamespaces/dc/ や https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/subject/ を参照してください。実質的にはある種のタグとして使用してしまって良いのではないかと思います。主題なので、ファイルが何を表現しているのかといった観点から付けた方が良いのだと思います。何か作業の状態等を付けるのは憚られる感じかと思います。

フィルタ表示機能は元々image-diredが対応していないものを無理矢理実現しているので、Emacsのバージョンアップに伴って機能しなくなる可能性があります。気がついたら直すつもりです。

図1: image-dired内でマークしたファイルにdc:subjectプロパティを設定している所

2024-10-19 el-xmp, Emacs

EmacsからファイルのXMPメタデータを取得・設定する

XMP(Extensible Metadata Platform)というメタデータを記述するための仕様があります。

https://developer.adobe.com/xmp/docs/

https://developer.adobe.com/xmp/docs/XMPSpecifications/

メタデータというと例えばタイトル、作成者、作成日、内容説明、ラベルといったものが代表的ですが、それに限らずあらゆる関連情報を表現することが出来る拡張可能な枠組みがXMPです。

例えば XMPSpecificationPart1.pdf というPDFファイル(バイナリ)の最後の方には次のようなXMLテキストが含まれています。

...バイナリ略...
<?xpacket begin="(略)" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.0-c316 44.253921, Sun Oct 01 2006 17:14:39">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:dc="http://purl.org/dc/elements/1.1/">
         <dc:format>application/pdf</dc:format>
         <dc:title>
            <rdf:Alt>
               <rdf:li xml:lang="x-default">XMP Specification Part 1: Data Model, Serialization, and Core Properties</rdf:li>
            </rdf:Alt>
         </dc:title>
         <dc:creator>
            <rdf:Seq>
               <rdf:li>Adobe Systems Incorporated</rdf:li>
            </rdf:Seq>
         </dc:creator>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:xap="http://ns.adobe.com/xap/1.0/">
         <xap:CreateDate>2012-03-21T08:55:04Z</xap:CreateDate>
         <xap:CreatorTool>FrameMaker 8.0</xap:CreatorTool>
         <xap:ModifyDate>2012-03-21T08:57:17-07:00</xap:ModifyDate>
         <xap:MetadataDate>2012-03-21T08:57:17-07:00</xap:MetadataDate>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:pdf="http://ns.adobe.com/pdf/1.3/">
         <pdf:Producer>Acrobat Distiller 8.1.0 (Windows)</pdf:Producer>
         <pdf:Copyright>Copyright 2012, Adobe Systems Incorporated. All rights reserved.</pdf:Copyright>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:pdfx="http://ns.adobe.com/pdfx/1.3/">
         <pdfx:Copyright>Copyright 2012, Adobe Systems Incorporated. All rights reserved.</pdfx:Copyright>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:xapMM="http://ns.adobe.com/xap/1.0/mm/">
         <xapMM:DocumentID>uuid:3806c052-1c0d-4599-b3ff-38c0441bbb3a</xapMM:DocumentID>
         <xapMM:InstanceID>uuid:abc82103-c360-4b74-8812-ff4c81eceaea</xapMM:InstanceID>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>
...空白文字略...
<?xpacket end="w"?>
...バイナリ略...

これによって、このPDFのタイトルが「XMP Specification Part 1: Data Model, Serialization, and Core Properties」、作成者が「Adobe Systems Incorporated」、作成日時が「2012-03-21T08:55:04Z」であることを示しているわけです。

XMPはJPEGファイルの中にも埋め込まれていることがあり、様々な撮影情報が記録されていることがあります。

写真のメタデータと言えばExifが代表的ですが、私の使っているカメラではカメラ内で設定したレーティング(写真の評価)だけがXMPとして記録されるようになっていました(それ以外の撮影情報は全てExifで記録されていました)。

また、写真編集ソフトや各種ビューアもこのXMPを利用するものが多いです。沢山ある写真を評価したり分類したりしたときに、その情報をサイドカーファイルと呼ばれるXMLファイル(IMG0001.JPG.xmpのようなファイル名)に保存するようになっているソフトが多くあります。darktableにいたっては現像のための全てのパラメータをサイドカーファイルに保存します。サイドカーファイルは少々煩わしい存在ですが、メタデータをネットワークストレージを介して共有したり他のソフトと交換したりするのには最適でしょう。

というわけで、EmacsからもこのXMPで書かれたメタデータを読み書きするためのライブラリを作成しました。

misohena/el-xmp: Emacs XMP (Extensible Metadata Platform) Library

今のところ基本的な情報を読み書きするためのコマンドやDired上でメタデータを元にマークするコマンドくらいしかありません。

サイドカーファイル(拡張子が.xmpのXMLテキスト)からの読み取りはもちろん、JPEG内のAPP1セグメント内にあるXMPパケットも読み取れるようになっています。その他の場合は汎用的なパケットスキャン(<?xpacket を探す)が使われますが、確実に読み取れるとは限りません。

保存は全てサイドカーファイルに対して行われます。一応パケット内に書き戻すことも可能なのですが、危ないのでデフォルトでは無効になっています。

Diredでマークするときなど、数千ファイルくらいあると読み取りにかなりの時間がかかります。一応Emacsのセッション中だけ有効なキャッシュ機構があるので、二回目以降は速くなるはずです。

永続的なファイルメタデータキャッシュ機構もそのうち作りたいと考えています。

図1: Diredでレーティングを元にjpgファイルをマークしてimage-diredで表示させた例

2024-09-23 Emacs

Emacs LispでXMLを解析する方法(名前空間あり)

libxml-parse-xml-region

「emacs lisp parse xml」などでWeb検索すると真っ先に出てくるのはEmacs Lispのマニュアルでしょう。

Parsing HTML/XML (GNU Emacs Lisp Reference Manual)

そこではlibxml-parse-xml-regionという関数で解析が出来るというようなことが書かれています。早速試してみましょう。

まずは次のXMLファイルを用意します。これは今適当にでっち上げたXMLで特に意味はありません。これをexample.xmlというファイル名で保存します。

<?xml version="1.0" encoding="UTF-8"?>
<my-nanikano-data
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
  <my-file-list>
    <file name="a0001.wav">
      <text><p xmlns="http://www.w3.org/1999/xhtml">これはテストですてすとてすと<strong>0001</strong>です。</p></text>
      <rdf:Description rdf:about="" xmp:Rating="5" xmlns:xmp="http://ns.adobe.com/xap/1.0/">
        <dc:creator>太郎</dc:creator>
      </rdf:Description>
    </file>
    <file name="b0001.wav">
      <text><p xmlns="http://www.w3.org/1999/xhtml">こんにちは<strong>0002</strong>です！</p></text>
      <rdf:Description rdf:about="">
        <dc:creator>花子</dc:creator>
      </rdf:Description>
    </file>
  </my-file-list>
</my-nanikano-data>

そしてlibxml-parse-xml-regionを使って解析してみます。

(with-temp-buffer
  (insert-file-contents "example.xml")
  (libxml-parse-xml-region))

結果は次のようになりました。

(my-nanikano-data nil
                  (my-file-list nil
                                (file ((name . "a0001.wav"))
                                      (text nil
                                            (p nil
                                               "これはテストですてすとてすと"
                                               (strong nil "0001")
                                               "です。"))
                                      (Description
                                       ((about . "") (Rating . "5"))
                                       (creator nil "太郎")))
                                (file ((name . "b0001.wav"))
                                      (text nil
                                            (p nil "こんにちは"
                                               (strong nil "0002")
                                               "です！"))
                                      (Description ((about . ""))
                                                   (creator nil "花子")))))

名前空間が消えてしまっています。これはいけません。これをベースに内容を修正して書き戻したらmy-nanikano-dataを読み込むアプリが正しく動かなくなってしまいます(まぁ、そんなものはありませんが)。

「emacs libxml namespace」でWeb検索するとこの問題に対するバグ報告と思わしきものがヒットしますが、libxml2のバグでEmacsのバグじゃ無いよ、ということでクローズされているみたいです(#59537 - `libxml-parse-xml-region` strips out the namespace information, and namespace prefix in the DOM representation - GNU bug report logs)。そんなわけないでしょう(笑)。libxml2はノードの解析結果をxmlNode構造体で返すようですが、libxml-parse-xml-regionの実装はその中のnsを一切触っていませんからね。

まぁ、バグを見つける→バグ報告を見つける→よく分からない理由で却下されている、という流れはEmacsでは良くあることです。Emacsは「あるがまま」の状態で提供されているわけで、自分で直して使えない人にはお勧めできません。

とは言えここはC言語で書かれている部分なので修正のハードルは高いですね。Emacs Lispレベルで何とかならないでしょうか？

xml-parse-file (オプション無し)

探してみるとxml-parse-fileというものが見つかりました(xml.el内)。早速使ってみましょう。

(xml-parse-file "example.xml")

((my-nanikano-data
  ((xmlns:rdf . "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
   (xmlns:dc . "http://purl.org/dc/elements/1.1/"))
  "\n  "
  (my-file-list nil "\n    "
                (file ((name . "a0001.wav")) "\n      "
                      (text nil
                            (p
                             ((xmlns . "http://www.w3.org/1999/xhtml"))
                             "これはテストですてすとてすと"
                             (strong nil "0001") "です。"))
                      "\n      "
                      (rdf:Description
                       ((rdf:about . "") (xmp:Rating . "5")
                        (xmlns:xmp . "http://ns.adobe.com/xap/1.0/"))
                       "\n        " (dc:creator nil "太郎") "\n      ")
                      "\n    ")
                "\n    "
                (file ((name . "b0001.wav")) "\n      "
                      (text nil
                            (p
                             ((xmlns . "http://www.w3.org/1999/xhtml"))
                             "こんにちは" (strong nil "0002") "です！"))
                      "\n      "
                      (rdf:Description ((rdf:about . "")) "\n        "
                                       (dc:creator nil "花子")
                                       "\n      ")
                      "\n    ")
                "\n  ")
  "\n"))

パッと見良さそうに見えます。名前空間の宣言や接頭辞の情報が失われず残っています。空白文字が全部残っているのは気になりますが、まぁ、何とでもなります。

問題は要素名や属性名が接頭辞を含む一つのシンボルで表現されていることです。その接頭辞がどの名前空間名(URI)を表しているか(あるいは省略されている場合にデフォルト名前空間が何か)は自分で調べなければならないでしょう。接頭辞が慣用的に決まっていてそれしか対応する必要が無いならこれでも良いのでしょうが、私はちょっと気になります。

xml-parse-file (parse-ns引数を使用)

改めてxml-parse-fileの関数ドキュメントを見ると、parse-ns引数を非nilにするとQNAMES(修飾名)を展開できると書かれています。早速やってみましょう。

(xml-parse-file "example.xml" nil t)

((("" . "my-nanikano-data")
  ((("http://www.w3.org/2000/xmlns/" . "rdf")
    . "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
   (("http://www.w3.org/2000/xmlns/" . "dc")
    . "http://purl.org/dc/elements/1.1/"))
  "\n  "
  (("" . "my-file-list") nil "\n    "
   (("" . "file") ((("" . "name") . "a0001.wav")) "\n      "
    (("" . "text") nil
     (("http://www.w3.org/1999/xhtml" . "p")
      ((("http://www.w3.org/2000/xmlns/" . "")
        . "http://www.w3.org/1999/xhtml"))
      "これはテストですてすとてすと"
      (("http://www.w3.org/1999/xhtml" . "strong") nil "0001")
      "です。"))
    "\n      "
    (("http://www.w3.org/1999/02/22-rdf-syntax-ns#" . "Description")
     ((("http://www.w3.org/1999/02/22-rdf-syntax-ns#" . "about") . "")
      (("" . "Rating") . "5")
      (("http://www.w3.org/2000/xmlns/" . "xmp")
       . "http://ns.adobe.com/xap/1.0/"))
     "\n        "
     (("http://purl.org/dc/elements/1.1/" . "creator") nil "太郎")
     "\n      ")
    "\n    ")
   "\n    "
   (("" . "file") ((("" . "name") . "b0001.wav")) "\n      "
    (("" . "text") nil
     (("http://www.w3.org/1999/xhtml" . "p")
      ((("http://www.w3.org/2000/xmlns/" . "")
        . "http://www.w3.org/1999/xhtml"))
      "こんにちは"
      (("http://www.w3.org/1999/xhtml" . "strong") nil "0002")
      "です！"))
    "\n      "
    (("http://www.w3.org/1999/02/22-rdf-syntax-ns#" . "Description")
     ((("http://www.w3.org/1999/02/22-rdf-syntax-ns#" . "about") . ""))
     "\n        "
     (("http://purl.org/dc/elements/1.1/" . "creator") nil "花子")
     "\n      ")
    "\n    ")
   "\n  ")
  "\n"))

おお、これまで要素名や属性名が入っていた部分がconsセルになっています。 (名前空間名 . ローカル名) という形式になっており、これはXML名前空間仕様における展開名(expanded name)と同じです。これなら接頭辞がどの名前空間名に対応するかを自分で調べなくても良さそうですね。

……と思ったのですが、よく見るとおかしな所があります。

それは (("" . "Rating") . "5") と書かれている部分。これは (("http://ns.adobe.com/xap/1.0/" . "Rating") . "5") でないといけないはずです。

少し追試をしてみましょう。試しに次のようなXMLを作ってみました。

<?xml version="1.0" encoding="UTF-8"?>
<rdf:Description
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:xmp="http://ns.adobe.com/xap/1.0/"
    rdf:about=""
    xmp:Rating="3"
    xmp:CreateDate="2024-09-23">
  <xmp:Thumbnails>
    <rdf:Alt>
      <rdf:li rdf:parseType="Resource">
        ....
      </rdf:li>
    </rdf:Alt>
  </xmp:Thumbnails>
</rdf:Description>

これを同様に解析してみます。

(xml-parse-file "example-2.xml" nil t)

結果は次の通り。

((("http://www.w3.org/1999/02/22-rdf-syntax-ns#" . "Description")
  ((("http://www.w3.org/2000/xmlns/" . "rdf")
    . "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
   (("http://www.w3.org/2000/xmlns/" . "xmp")
    . "http://ns.adobe.com/xap/1.0/")
   (("" . "about") . "") (("" . "Rating") . "3")
   (("" . "CreateDate") . "2024-09-23"))
  "\n  "
  (("http://ns.adobe.com/xap/1.0/" . "Thumbnails") nil "\n    "
   (("http://www.w3.org/1999/02/22-rdf-syntax-ns#" . "Alt") nil
    "\n      "
    (("http://www.w3.org/1999/02/22-rdf-syntax-ns#" . "li")
     ((("http://www.w3.org/1999/02/22-rdf-syntax-ns#" . "parseType")
       . "Resource"))
     "\n        ....\n      ")
    "\n    ")
   "\n  ")
  "\n"))

属性名である rdf:about や xmp:Rating 、 xmp:CreateDate の名前空間名が "" になってしまっています。しかし前にある要素名 rdf:Description や、その後にある要素名(xmp:Thumbnails)や属性名(rdf:parseType)には正しい名前空間名が展開されています。つまり名前空間を宣言した要素に指定されている属性名だけが正しく展開されていないように見えます。

そこでxml.el内にあるxml-parse-fileの実装を読んだところ、原因はxml-parse-tag-1関数内にあることが分かりました。 ;; opening tag と書いてあるあたり、開始タグの解析を行っているあたりです。xml-nsという変数が接頭辞と名前空間名との対応表(alist)になっているようですが、その更新と使用の順序に問題があります。全属性の解析と属性名の展開、名前空間宣言(xmlns:??=)の反映、要素名の展開の順に行われているため、属性名を展開する段階ではまだその要素で行われている名前空間宣言が反映されていません。従って、名前空間宣言をした要素にある属性名は正しく展開されないというわけです。せっかく便利な機能があるのにこれでは使えません。

nxml-parse-file

他にもEmacs内にXMLを解析している部分は無いかと探したところ、nxml-parse-fileという関数を見つけました(nxml-parse.el内)。

早速使ってましょう。

(nxml-parse-file "example.xml")

("my-nanikano-data"
 (((:http://www.w3.org/2000/xmlns/ . "rdf")
   . "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
  ((:http://www.w3.org/2000/xmlns/ . "dc")
   . "http://purl.org/dc/elements/1.1/"))
 "\n  "
 ("my-file-list" nil "\n    "
  ("file" (("name" . "a0001.wav")) "\n      "
   ("text" nil
    ((:http://www.w3.org/1999/xhtml . "p")
     (((:http://www.w3.org/2000/xmlns/ . "xmlns")
       . "http://www.w3.org/1999/xhtml"))
     "これはテストですてすとてすと"
     ((:http://www.w3.org/1999/xhtml . "strong") nil "0001") "です。"))
   "\n      "
   ((:http://www.w3.org/1999/02/22-rdf-syntax-ns\# . "Description")
    (((:http://www.w3.org/1999/02/22-rdf-syntax-ns\# . "about") . "")
     ((:http://ns.adobe.com/xap/1.0/ . "Rating") . "5")
     ((:http://www.w3.org/2000/xmlns/ . "xmp")
      . "http://ns.adobe.com/xap/1.0/"))
    "\n        "
    ((:http://purl.org/dc/elements/1.1/ . "creator") nil "太郎")
    "\n      ")
   "\n    ")
  "\n    "
  ("file" (("name" . "b0001.wav")) "\n      "
   ("text" nil
    ((:http://www.w3.org/1999/xhtml . "p")
     (((:http://www.w3.org/2000/xmlns/ . "xmlns")
       . "http://www.w3.org/1999/xhtml"))
     "こんにちは"
     ((:http://www.w3.org/1999/xhtml . "strong") nil "0002") "です！"))
   "\n      "
   ((:http://www.w3.org/1999/02/22-rdf-syntax-ns\# . "Description")
    (((:http://www.w3.org/1999/02/22-rdf-syntax-ns\# . "about") . ""))
    "\n        "
    ((:http://purl.org/dc/elements/1.1/ . "creator") nil "花子")
    "\n      ")
   "\n    ")
  "\n  ")
 "\n")

問題は特に見当たらないと思います。

特徴:

(要素名や属性名の中で)名前空間名(URI等)を表現するのにキーワードを使う(:http://www.w3.org/2000/xmlns/ 等)。
要素名や属性名はconsセル (<名前空間名キーワード> . <ローカル名文字列>) で表現される。ただし、名前空間無しの場合はローカル名単体の文字列となる。
デフォルト名前空間の宣言(xmlns=<名前空間名>)の解析結果は ((:http://www.w3.org/2000/xmlns/ . "xmlns") . "<名前空間名>") の形で表現される。 xmlns の部分は :http://www.w3.org/2000/xmlns/ と展開されているのだからローカル名部分は空文字列にでもなりそうなものだが、なぜか "xmlns" が入っている。これだと xmlns: という接頭辞の名前空間を宣言する(xmlns:xmlns=<名前空間名>)のと同じ形になってしまうので、注意が必要。

要素名の展開表現とdom.elの問題

xml-parse-file(parse-nsが非nilの場合)やnxml-parse-fileを使った場合、要素名がconsセルで表現されるようになるわけですが、そうするとdom.elが使えなくなるという問題が発生します。dom.elの各関数には処理対象のノードを指定する引数(nodeやdom)があるわけですが、それらはなぜか引数がノードのリストである可能性を考慮しています。引数nodeがノードのリストであった場合、そのリスト内の最初のノードを処理対象にするコードが各関数に入っています。引数nodeがノードのリストかどうかをチェックするコードは (consp (car node)) という形になっています。nxml-parse-file等を使用して生成されたノードは要素名部分、つまりリストの最初の要素がconsセルになりますから、このチェックにひっかかってしまいます。そしてノードのリストと勘違いされて、その先頭要素が取り出され、構造が破壊されてしまいます。

この問題に対する対策ですが、dom.elは大したことはやっていませんし少々使いづらい所もあるので、自分で独自のノード操作関数を作成するのが一番だと思います。要素の内部表現はいずれで解析した場合でも、 (<要素名> . (<属性alist> . <子供リスト>)) の形になっています。要素名や属性名(属性alistのキー部分)の部分が文字列だったりconsセル (<名前空間名> . <ローカル名>) だったりするだけです。やっていることは単純なので簡単に作れるでしょう。el-easydrawなんかでも最初のうちはdom.elやsvg.elを使用していましたが、今は使わなくなってしまいました。

別の方法としては、解析した後に名前部分を補正してしまう手があります。つまり、ツリーを巡回して名前部分を一つのシンボルなり文字列なりに結合してしまうわけです(:http://www.w3.org/1999/02/22-rdf-syntax-ns\#::Description のように)。そうすればdom.elは引き続き使えます。

まとめ

名前空間をちゃんと扱いたいならnxml-parse-fileが一番良さそうです。この場合、解析結果そのままだとdom.elが使えないので何らかの対処が必要になります。

接頭辞が決め打ちでも構わないような用途なら(parse-ns引数を使わない)xml-parse-fileも使えそうです。parse-ns引数は不具合があるので止めましょう。

名前空間を使わない、もしくは消えても構わないような用途ならlibxml-parse-xml-regionが使えます。

Emacsの中をくまなく探したわけでもありませんし紹介した関数の中もくまなく調べたわけでもありませんので、何か気がついていない問題やより良い方法があるかもしれません。

Recent Posts