#そして再び停電。Colemanのガスランタンが本来の目的(キャンプ用)よりも停電対策として大活躍しているという。
#らむ太は、ガスランタンは「ていでんのときにつかうもの」だと思い込んでいる。
##ありゃ、とおるくんのところも被害受けました?
#夕飯にPanda Cuisineをテイクアウトしたんだけど、店の人が「今日はクレジットカードのオンラインが動いてないんだ」ってぼやいて手動で処理してました。
#寝てたので気が付きませんでした(笑)。起きたころには電気は復活してました。ただ、CLEAR WiMAX がたびたび止まってました。
#ガスランタンの照度なら、灯り的には不便ないですよねぇ。子供の頃停電と言えばろうそくだったなぁ。
#東京ではさすがに停電の経験はないけど、両親の田舎(福井)では、台風だの落雷だのでちょいちょい停電があった
#雨降りすぎて火災かぁ。日本では、猫が変電所で感電して停電ってのがありました。
##蛇とかカラスも時々聞くなぁ
#Gauche を使って Windows 環境で日本語のファイル名を付けたファイルを作りたいとき、ファイル名の文字列はあらかじめ cp932 に変換しないといけないみたいですが、これは意図した挙動なんでしょうか。
#む、いや、そこはあんまり考えてないです。Gaucheの内部エンコーディングのままWCHARに変換してWindows APIを呼び出してるんですが、Windows APIってunicodeK化されてませんでしたっけ。
#s/unicodeK化/unicode化/
#されてるはずと思うんですが…
#む、ファイルまわりはPOSIX互換インタフェース (_openとか) を呼んでたかな。もしかしてこいつはコードページの影響を受けるとか。
#意図としては全部unicodeで扱えるようにするつもりです。コードページに依存してエンコーディング変換なんて大変なので。
#バイナリを見てみると CreateFile を呼んでるところが CreateFileA の方になってるけど、 WCHAR は CreateFileW の方を使うんじゃなかったかな?
#試してないので見当違いかもしれないけど。
#CreateFile を使ってるのは truncate のところだけみたいなので、ファイルのオープンには Windows API を直接呼んではいない感じ
#ああ、じゃあ_open()を呼ぶとレガシーインタフェースの方を使ってしまって、それはコードページによって変換されちゃうようになってるってことすね、やっぱり。
#全部Windows APIを直接叩くようにした方がいいな。
#動画サイトから情報を回収するスクリプトを書いてて動画のタイトルを名前にしたファイルを作ろうとして、 CP932 には無い文字が〓になっちゃうのが困ったなと思って。
#大抵は顔文字の部分とかなのでそれほど害は無いんですが。
#互換性が問題になる部分なので、早く直した方がいいですね。
#Windows 以外での事情はどうなんでしょう。
#Gauche の内部コードからシステムのロケールに従って変換する形になるんでしょうか。
#ふーむ、そこをGauche層で吸収すべきか、それともC等で書くのと同様にプログラマの責任で、Gaucheは渡されたバイト列をそのままシステムに流しますよ、とすべきかなあ。現在は後者ですが、深く考えていたわけではありません。
#変換できない文字の扱いをどうするかということもあるので、 Gauche 側で勝手にやっちゃうのもイマイチ綺麗な解決とは言えないかもしれませんね。
#ですね。変換時点でエラーになると柔軟性がないし、かといって下駄とかにマッピングしちゃったら情報が落ちちゃうし。
#デフォルトでは現状のままとして、ファイル関係のapiに:pathname-encodingみたいなキーワード引数をつけて外部表現を指定することもできる、としておくと便利かな。その値として"*locale"とか渡すと現在のlocaleに従って変換してくれるとか。
#現在のロケール以外を指定したいケースってあります?
#ファイルシステムとロケールが食い違う場合とかもあるのかな?
#ロケールはいつでも変更できるので、食い違う事例は十分あるんじゃないかな…
##OSXのファイルシステムは内部で正規化とかしてたっけ。ファイルシステムによってはエンコーディングの制約があるかも。
#へぇ。 そりゃまた泥臭い状況ですね。
#OS X は「レポート.txt」が「レホ゜ート.txt」みたいになっちゃったりしますね。そういえば、Mac で作った繁体字のファイル名がはいった zip ファイルをもらったことがあるんですけど、Linux で unzip したらなんか解読できない文字になっちゃいました。