萬由無事覚書

不知物故萬由無事覚書仕候也。

ロケール固有情報の形式

ロケール固有情報って、どういう形式があるんだろう?

規格

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_ADDRESSLC_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

関連規格

既存の実装

VCSとの関連性

Gitなどの実装が参考になる。実際上は、以下の様な実装を見るほうが簡単そうだ。

また、独自に差分符号化を実装する場合でも、皮を被せることでさまざまなVCSに見せることもできるかもしれない。

Windows環境でRSpecなどの出力に色を付けるには

これから

ansiconをインストールする。

インストールは次のようにする。

  • アーカイブを展開
  • 32bit OSならx86フォルダ、64bit OSならx64フォルダの中身を任意の場所にコピー。

レジストリを使用してでも簡単に使いたい場合

  • cmd.exeを実行し、コピーしたフォルダにcdする。
  • その後、次のコマンドを実行。
    ansicon -i

実行後、cmd.exeが実行されるたびに自動的にansiconが実行されるようになる (cmd.exeのAutoRunレジストリエントリにansiconを設定してくれる)。

この状態で、普通にコマンドを実行すれば、出力に色がつく。例えば

C:\dir> rspec --color

ansiconをアンインストールしたい場合は次のようにする。

ansicon -u

これでレジストリから設定が消える。あとはインストールしたフォルダを消去する。

どうあってもレジストリを使いたくない場合

レジストリを使いたくない場合は次のようにする。

  • ansiconのインストールフォルダを環境変数PATHに追加し、検索パスを通す。
  • その後、例えば次のように実行。これで色がつく。
    C:\dir> ansicon rspec --color

アンインストールに気をつける部分はなく、フォルダごと消去で問題ない。

これまで

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年以上触ってなかったとは。