Firefox3.5に備えて非対応アドオンを緊急避難的に使えるようにする方法（Firefoxのアドオンとか弄る時に必要なメモ install.rdfでできること）

　このエントリはえふすくの勝手なFirefoxアドオン改造をえふすくなりに解説してみたものです。
　マネしてFirefoxおよびその他のデータを破壊してしまったらごめんなさいとしか言いようがありません。

パッケージの内部構造について

　前回 は単にxpiパッケージを展開→再パッケージ化しただけだったが、実際の改造はもちろん中身を弄るので、簡単でよくありそうなものから。
　とりあえず前回展開したLink Gopherの中身について解説するとまずはこんな構成になっている（解説はあくまでえふすく流）

\解凍したフォルダ
│　install.rdf （アドオン固有の情報を記したメタデータファイル。インストール時に参照される）
│　license.txt （ライセンス記述用のテキストファイル。ここではGPLv3の全文が入ってた）
│　chrome.manifest （アドオンの本体とインストーラを結びつけるためのパス変換ファイル）
└─\chrome（アドオンの本体）
　└─\content（アドオン本体の中でアドオンの機能を司る部分）
　　extract-links.js （Javascriptファイル。アドオンの処理を司る）
　　link-gopher.xul （xulファイル。ユーザインターフェイスを司る）

　実際にはもっと種類があるのだが、Link Gopherは数あるアドオンの中でも単機能のせいかかなりシンプルな構造になっている。

install.rdfの書き換えでできること①　対応バージョンの書き換え

　そろそろFirefox3.5の正式版が出るということで、公開後1カ月くらいは未対応アドオンの様子を見ることになるわけだが、Link Gopher も例によって対応は3.0.*までとなっている。普通にインストールしても拒否されてしまう。
　こういう場合Nightly Tester Tools などを使って、強引にアドオンをインストールor有効にしてしまうのが本来なら一番手っ取り早い。しかし、対応してくれるまでの繋ぎとして考えるとNightly Tester Toolsはどんなアドオンでもバージョンを無視してしまうため、有効にするつもりがなかったものやもともと対応してなかったものを把握しづらかったりするので、3.0に移行したあたりからこの方法を使っている。

　install.rdfはRDFファイルゆえテキストエディタで編集することができる。

　Firefoxアドオンを弄る時のエディタ
　基本的にFirefoxはUNICODE（UTF-8）で編集できることとRDFはXMLなのでHTMLかXMLを編集しやすいカラーリングができることが条件。
　・サクラエディタ
　・TeraPad
　・Mery （旧mEditor）
　・EmEditor Free

　あたりで、お好みをどうぞ。
　えふすく的には

　ソースをカラーのまま印刷のできる：EmEditor Free
　もともとテキストでもメイン、HTMLモードでRDFを編集するときのカラーリングが絶妙：サクラエディタ。
　今回のケースのようなちょっと軽く修正したいときはTeraPad。
　改造元のソースに可読性向上のため最初に行うXML自動整形が強力なMery。

　直接開きに行くのも関連付けが面倒なので先にエディタを開いて、install.rdfをドラッグ＆ドロップしてしまった方が早い。
　すると現状ではこんなソース。

<?xml version="1.0"?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
　xmlns:em="http://www.mozilla.org/2004/em-rdf#">

　<Description about="urn:mozilla:install-manifest">
　<em:id>linkgopher@oooninja.com</em:id>
　<em:version>1.2</em:version>
　<em:type>2</em:type>

　<!-- Target Application this extension can install into,
　with minimum and maximum supported versions. -->
　<em:targetApplication>
　<Description>
　<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
　<em:minVersion>2.0</em:minVersion>
　<em:maxVersion>3.0.*</em:maxVersion>
　</Description>
　</em:targetApplication>

　<!-- Front End MetaData -->
　<em:name>Link Gopher</em:name>
　<em:description>Extracts and collates links from web pages</em:description>
　<em:creator>Andrew Ziem</em:creator>
　<em:homepageURL>https://addons.mozilla.org</em:homepageURL>
　</Description>　
</RDF>

　このem:targetApplication タグ内がアドオンの対応アプリケーションとバージョンを示していてさらに解説すると……

　<em:targetApplication>（対応アプリケーション情報ノード）
　<Description>
　<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
（アプリケーションのID【ec8030f7-c20a-464f-9b0e-13a3a9e97384 はFirefoxのこと】）
　<em:minVersion>2.0</em:minVersion>（アドオンの対応最小バージョン）
　<em:maxVersion>3.0.* </em:maxVersion>（アドオンの対応最大バージョン）
　</Description>
　</em:targetApplication>

【わかってないこと】バージョン番号の大小関係
　開発中のFirefoxには番号だけでないバージョン表記が存在する。
　まずはもちろんα、β版を示す「a」「b」の表記。RC版の「rc」の表記。それぞれのプレビュー版を意味する「pre」という表記。
　実際問題としてたとえば「3.5b4pre」は3.5beta4でインストールできるのかとかそういう微妙な記述ルールが今知りたいところ

　と思ったよりは簡単な仕組みになっている。今回は3.5に対応させたいのでem:maxVersionの値を3.5.* にして保存すればいい。ファイル的に何も変わっていないので、後は前回 同様の再パッケージングを行って、できたxpiファイルをFirefoxにインストールすればバージョンチェックをすり抜けることができる。
　もちろん、バージョンに上限があるのは動作検証が行われていないか非対応であるということなので、インストールできたところで前バージョンのように動作してくれるとは限らない。
　そしてこの作業、アドオン1つ1つに行うため慣れるまで手間がかかる。作る側はともかく、使うだけの側からすれば本当に必要なアドオンがアップデートで使えなくなってしまったときの緊急避難的手段くらいにしかならないと思う。

　install.rdfを弄ると他にも色々面白いことができるけど、それはまた次の機会に。

【追記　2009/08/01】
　一連の作業をドラッグ＆ドロップで完了できる「Update XPI」というアプリがあるそうです。
　※　古いバージョン用のFirefoxアドオン（xpi）を3.5対応版に変換できるソフトウェア「Update XPI」
　ただ3.5に間に合わせたいだけの人はこちらをどうぞ【自分では試してないけど】

■Tweet■■