ロケール固有情報の形式
ロケール固有情報って、どういう形式があるんだろう?
規格
- ISO/IEC TR 14652:2004形式
-
glibcなんかで使われている。glibcのgitリポジトリで見られる (該当部分は/localedata/localesあたり)。
「拡張ロケール環境変数」で書いたように、国際標準としては廃止されている。
- LDML形式
-
XMLを用いた形式。
CLDRことCommon Locale Data Repositoryで使われている。このCLDRは、ロケール固有情報を蓄積・提供するプロジェクトだ。詳しくは以下参照。
こいつはとても便利そうだ。「devsumi 2012 で「いまどきのi18nのはなし」を聞いて、CLDR を紹介しようと思う」に、利用のヒントがたくさん書かれてる。
ロケール固有情報って、現地に住んでないとわからないことも多いと思う。そういうのがきちんとまとまってて、提供されてるってのはすごい!
現時点での最善慣行
- CLDR使ってXSLTで変換してDBにしてアプリで利用。
- 国際化対応のWebアプリなんかでは、重宝しそうだ。
拡張ロケール環境変数
LC_NAME
とかLC_ADDRESS
、LC_IDENTIFICATION
などのことをちょっと調べてみた。
LC_IDENTIFICATION
などの拡張されたロケール関係環境変数は、ISO/IEC TR 14652:2004 「文化依存要素の定義書式」が基になっているらしい。glibc 2.2あたりで追加されたらしいね。
ところが、これは、2008年に廃止されている。情報処理学会の情報規格調査会が出してる報告書を参照のこと。
規格書本体 (PDF形式) にある日本からのコメントには、「POSIX環境以外で使えんの?」「デフォルト値を決めると、それが世界標準とみなされかねないのは嫌」「表現力不足じゃね?」とかあったりする。このあたりの経緯は、いろいろありそうでよくわからんね。
なんでこんなものを調べたんだ?
出力されるメッセージは日本語がいい (英語はニガテだ)。当然、その他のロケール依存処理もちゃんと日本/日本語にしたい。
でも、そうするとmanまで日本語で表示されてしまう。
言うまでもなく、日本語のmanはとても便利だ (英語ニガテだと特にね)。しかし時として内容が古かったりする場合がある。なので、最初からオリジナルのmanを表示させておくと都合がいい。
export LANG=ja_JP.UTF-8
export LC_MESSAGES=ja_JP.UTF-8
⋮
alias jman="LANG=ja_JP.UTF-8 LC_MESSAGES=ja_JP.UTF-8 man"
alias man="LANG=C LC_MESSAGES=C man"
のようにしている。つまりmanの実行時だけ強制的にCロケールにするわけだね。
で、どんなLC_*
な環境変数があったかなー? と思ってlocale(1)を実行すると、こんなのが出てきた。
⋮
LC_CTYPE="ja_JP.UTF-8"
⋮
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
⋮
?
LC_IDENTIFICATION
とかって、SUSとかで定義されてたっけ? ってのが動機だ。
そして残った疑問がもう1つ。これって、実際のアプリケーションで使われてる環境変数なんだろうか? なんかドキュメント見ても全く書いてないんだけど……。
つまりは廃止されてる標準だから、使うなってことかな?
差分符号化について
いわゆるバイナリdiffってやつだね。気になったので簡単にサーベイしてみる。性能やらなんやらはがっつり比較検討していない。
概要を知るには
規格
成文化された規格は次の通り。
- RFC 3284 - The VCDIFF Generic Differencing and Compression Data Format
関連規格
- RFC 3229 - Delta Encoding in HTTP
既存の実装
- libxdiff - PHPなどで使われている感じ
- bsdiff/bspatch - 圧縮率高めっぽい
- bdelta - deltupの一部
- xdelta - VCDIFFを実装、rsyncから発生
- open-vcdiff - もうひとつのVCDIFF実装。Google Chromeで使われているHTTPレスポンスの圧縮技法、SDCHを実現するために使われている
VCSとの関連性
Gitなどの実装が参考になる。実際上は、以下の様な実装を見るほうが簡単そうだ。
また、独自に差分符号化を実装する場合でも、皮を被せることでさまざまなVCSに見せることもできるかもしれない。
Windows環境でRSpecなどの出力に色を付けるには
これから
ansiconをインストールする。
インストールは次のようにする。
レジストリを使用してでも簡単に使いたい場合
- cmd.exeを実行し、コピーしたフォルダにcdする。
- その後、次のコマンドを実行。
ansicon -i
実行後、cmd.exeが実行されるたびに自動的にansiconが実行されるようになる (cmd.exeのAutoRunレジストリエントリにansiconを設定してくれる)。
この状態で、普通にコマンドを実行すれば、出力に色がつく。例えば
C:\dir> rspec --color
ansiconをアンインストールしたい場合は次のようにする。
ansicon -u
これでレジストリから設定が消える。あとはインストールしたフォルダを消去する。
どうあってもレジストリを使いたくない場合
レジストリを使いたくない場合は次のようにする。
アンインストールに気をつける部分はなく、フォルダごと消去で問題ない。
これまで
win32consoleを使っていた。
なぜ?
色。テストの時は大事ですよね。視覚的に失敗がわかるのはありがたい。
でも、Windows環境下でRSpecを実行したら、色が妙なことになってた。調べてみると、「gem install win32console
すべし!」といろいろなサイトに書いてあったんだが……
今のRSpecではwin32consoleを読み込んでいない。
そのため、--color
オプションを付けてANSIカラーコードを出力しても、Windows環境では妙な文字が出力されるだけになる。
現在、RSpecやCucumberなど色出力を使うアプリケーションは、win32consoleを使わずansiconを利用する方向らしい (参照)。
名称変更: sqlite3-ruby → sqlite3
これから
SQLite 3系をRubyから使いたい場合、下記のようにする。
gem install sqlite3
これまで
これまでは下記のようだった。
gem install sqlite3-ruby
なぜ?
Rubyでプログラムを作っていたら、RDBを使いたくなった。
大規模運用とかは考えていないので、とりあえずSQLiteを使うことにする。
そこで何も考えずにsqlite3-rubyをインストールしたら、メッセージが出た。
「sqlite3-rubyはsqlite3という名前になったよ。こんどからはsqlite3のほうをインストールしてね。」
調べてみたら、Ver.1.3.3 (2011-01-16) からそうなったらしい……。1年以上触ってなかったとは。