カテゴリー: 技術メモ

　rails上で自分のドメイン名をつかってナンヤカンヤしたい時というのがあって。

ENV[‘HOSTNAME’]

　これは論外っぽい。

[default] ENV
[default] :{“HOSTNAME”=>”xxxx.mogya.com”,

仮想ドメインの設定を無視してホスト名を返してくれます。HOST_NAMEという値ですから、当たり前か。

request.env:[‘SERVER_NAME’]

request.env:{“SERVER_NAME”=>”maidmail.jp”,

　ねらい通り、ドメイン名を返してくれます。ただ、このヘッダも、あとrequest.env[‘HTTP_HOST’]も、ちょっとしたことで簡単に偽装されてしまうので、迂闊につかえません。

request.domain

[default] request.domain:maidmail.jp

　こっちを見ると、request.env:[‘SERVER_NAME’]が偽装されてしまうような場面でも、正しいドメイン名がとれました。
ソースを見ると、HTTP_X_FORWARDED_HOSTというヘッダを使うみたいです。

# File vendor/rails/actionpack/lib/action_controller/request.rb

318:     def domain(tld_length = 1)
319:       return nil unless named_host?(host)
320:
321:       host.split('.').last(1 + tld_length).join('.')
322:     end
280:     def host
281:       raw_host_with_port.sub(/:\d+$/, '')
282:     end
271:     def raw_host_with_port
272:       if forwarded = env["HTTP_X_FORWARDED_HOST"]
273:         forwarded.split(/,\s?/).last
274:       else
275:         env['HTTP_HOST'] || env['SERVER_NAME'] || "#{env['SERVER_ADDR']}:#{env['SERVER_PORT']}"
276:       end
277:     end

HTTP_X_FORWARDED_HOSTがとれなかった場合に限り、env[‘HTTP_HOST’]やenv[‘SERVER_NAME’]を見てくれるので、HTTP_X_FORWARDED_HOST非対応のサーバでも、request.domainを見ておけば悪いようにはしない実装になっているみたいです。

HTTP_X_FORWARDED_HOSTのうまい説明が見つけきれなかったのですが、これってどういう環境変数なのかなぁ？どれくらい信用のおける値なのでしょう？

先日公開したmextractr_webapi.rbが、gem経由でインストールできるようになりました。

こんな具合にして使うことが出来ます。

[daisuke@snares ~]$ sudo gem install mextractr_webapi
Bulk updating Gem source index for: http://gems.rubyforge.org
Successfully installed mextractr_webapi-0.0.1
1 gem installed
[daisuke@snares /var/maidmail]$ script/server
>> require "mextractr_webapi"
>> mextractr = MextractrWebApi.new(API_KEY)
>> res = mextractr.parse("11/29（土）　京都で紅葉を楽しむオフ会を開催します。秋深い京都を撮り歩きましょう。 ")
>> pp res
{"id"=>"20081202_0001",
"where"=>
[{"georss:point"=>nil, "valueString"=>"京都"},
{"georss:point"=>nil, "valueString"=>"京都"}],
"what"=>[{"valueString"=>"オフ会"}],
"when"=>[{"valueString"=>"11/29（土）", "startTime"=>"2008-11-29"}],
"updated"=>"2008-12-02T12:16:50+09:00"
"content"=>
"11/29（土）　京都で紅葉を楽しむオフ会を開催します。秋深い京都を撮り歩きましょう。 ",
"response"=>
"\n\n  \n  2008-12-02T12:16:50+09:00\n  \n    Mextractr\n  \n  20081202_0001\n  \n    \n    20081202_0001\n    \n    \n      Mextractr WebAPI\n    \n    2008-12-02T12:16:50+09:00\n    11/29（土）　京都で紅葉を楽しむオフ会を開催します。秋深い京都を撮り歩きましょう。 \n    \n    \n    \n    \n  \n\n",
}

enjoy!

　メイドめーるでは日本語のメールを送信するために、
ヽ( ・∀・)ノくまくまー(07-31[長年日記])で書いていただいている、Iso2022jpMailerを使っています。
クラスを継承するだけでつかえるとてもいいアイデアだったのですが、たった一つ問題が。

「～」が文字化けするのです。普通のアプリケーションだったら、まあ横棒でいいか、とか言えるし、実際メイドめーるも今日までそうやってごまかしてきたのですけど。萌え萌えなメイドさんがメールをくれるアプリケーションにおいて「～」がつかえないと言うことは、「おはようございます～」がつかえないことになってしまいます。
「おはようございますー」と「おはようございます～」は断じて違うのです！

とまあそんなわけで、技術的に追求した結果、一応「～」が出せるようになりましたのでご報告です。

やり方としては、Iso2022jpMailer の

@mail.body = NKF::nkf('-j', @mail.body)

の部分を

@mail.body = NKF::nkf('-Wxm0 --oc=ISO-2022-JP-1', @mail.body)

に置き換えます。
ついでに、タイトルとかに「～」がはいることもあるだろうから、

text = NKF.nkf('-j -m0', text)

も、

text = NKF.nkf('-Wxm0 --oc=ISO-2022-JP-1', text)

にしちゃいました。

技術的な話

正直に言うと、なんでこれで化けないのか、最終的な理由は理解できていません。
ただ、あれこれやっているうちに、化ける時と化けない時があって、比較するとこうなっていることが分りました。

上がうまくいく場合で、下が駄目な場合です。日本語メールなのでJISコードでエンコードしてあります。
OKな時は1B 24 42で始まっていて、駄目な時は1B 24 48で始まる…、つまり、JIS X 0208-1983でエンコードしてあればOKで、JIS X 0212-1990だと駄目なことが分ります。
NKFのコマンド詳細を見ながら、irbでいろいろやってみると。

>> NKF::nkf('-jWxm0', "～").each_byte{|b| print b.to_s(16)+","};print "\n"
1b,24,28,44,22,37,1b,28,42,
=> nil
>>NKF::nkf('-Wxm0 --oc=ISO-2022-JP', "～").each_byte{|b| print b.to_s(16)+","};print "\n"
1b,24,28,44,22,37,1b,28,42,
=> nil
>> NKF::nkf('-Wxm0 --oc=ISO-2022-JP-1', "～").each_byte{|b| print b.to_s(16)+","};print "\n"
1b,24,42,21,41,1b,28,42,
=> nil
>> NKF::nkf('-Wxm0 --oc=ISO-2022-JP-3', "～").each_byte{|b| print b.to_s(16)+","};print "\n"
1b,24,28,50,28,37,1b,28,42,
=> nil

–oc=ISO-2022-JP-1の時だけ、ねらい通りの変換をしてくれるようです。ということで、Iso2022jpMailerにも、同じ引数を渡してあげると、「～」が出るようになった次第。
「ISO-2022-JP-1」って、JIS X 0212に対応させるための引数で。むしろ逆のような気がするし、なんでISO-2022-JP-3で駄目なのかも謎です。