Kazuhiko
kazuh****@fdiar*****
2009年 8月 20日 (木) 14:48:45 JST
かずひこです。
to_eucなんてのがそこら中にちりばめられていて、案外変更点が多くてげんなり
していたりします。
Fujioka wrote:
>> 先日、守岡さんにお会いしたときに相談したところ、EUC-JPやISO-8859-1で
>> validなバイトストリングはUTF-8としてvalidにはならないらしいので、リクエ
>> ストされたページ名がなかったら過去のencodingを探しにいく、という処理は問
>> 題なさそうです。
>>
> ちょっと表現が違う気がしたので補足です。
> これはEUC-JPやISO-8859-1にUS-ASCIIじゃない文字列が
> 入っているという前提ですよね。
> StringがEUC-JPというencodingの状態でも中身がUS-ASCIIのみだと
> valid_encoding?で通ってしまうのですが、中身がUS-ASCIIなので
> 変換は問題ないのですが、ちょっと気になりました。
>
> ということで、EUC-JPにUS-ASCIIのみの文字列が入っていた場合はvalidです。
> そして、force_encoding("UTF-8").valid_encoding? ==> true
> となってしまいます。ちょっと補足でした。
変換は問題ないというか、US-ASCIIのみの場合はEUC-JPだろうがISO-8859-1だろ
うがUTF-8だろうが、URIは変わらないので問題ありません。つまり、来たURIに
よるページ名をUTF-8だと思って探しにいったら、そのまますでにちゃんとある
よ、ということです。valid_encoding?を呼ぶのは、リクエストされたページが
見つからなかった時だけの処理になると思います。
>> なので、データの互換性の対策としては
>> * 見つからなかったら過去のencodingのページ名で取得を試みる
>> * やっぱりデータは一括で自動変換しちゃう（←tDiary式）
>> の二通りが可能だと思うのですが、どうしましょう？
>>
> 過去のencodingページにリンクを変更するように促すページを挟むとか。
> 過去のencodingはconfの中とかで決めうち？
すでにhiki.confに書いてある@charsetを見ればいいかなぁと考えています。
>> tDiaryと違って、Hikiではバックエンドがいろんな種類があるので、すべてを
>> ウェブからのリクエストをトリガーに自動変換するのはけっこう困難な気がしま
>> す。設定ファイル（CGIから保存されたhiki.conf）の変換くらいが妥当で、それ
>> 以上のデータ変換は、シェルからこうやればできます、みたいなHowToの提供
>> じゃだめ？と思っているところです。
>>
> そうか、バックエンドがいろいろあるんですね。
> 一部のバックエンドだけを対応とかじゃだめですかね。
> それ以外の人は手でやってくださいとか。
一部って、例えばどれをやってみたいですか？ DBにmigrateみたいなAPIを用意
して、たとえばsvnなら
svn mv (EUC-JPのページ名) (UTF-8のページ名)
を（ASCIIでない）全ページ分やってまわる、みたいな感じで、できそうなもの
からやってみればいいのかな。
CVSは... 生ファイルの*,vをリネームするという乱暴な手ならありますが、
ちょっと微妙かも。
gitとかhgとかは、そっち系の方、よろしくお願いします、になりそうです。
ちなみに、fdiary.net wikifarmでは、MySQLバックエンドですが、たぶん私しか
使っていないと思うので、サーバ側で変換しちゃうコースで行くと思います。
かずひこ