ごちゃごちゃやってるうちにWindowsが微妙におかしな挙動を示すようになってきた。
　つーかレジストリが致命的におかしくなってる雰囲気。HDDのエラーチェックもしてみたが、特に問題は出ていないようだ。レジストリとなるとさっぱり分からんぞ。
　ということで、CDからの修復インストールを試みたが、却って悪化した。うむ。仕方ないので入れ直しだな。

　うちのHDDは単一パーティションなので、再インストールの時にクイックフォーマットは使わない。
　で、そうするとWindowsのインストーラは、\Windows以下を削除して入れ直そうとする。はず。普通はそこに大事なデータは何も入ってないだろうから、気にすることはないよな。マイドキュメントの実体が移動したりするが、まあそれでも新PCに移行するのと同じ手間だな。

　つーことで入れ直す。めんどくせえ。

　そして、何とか環境が落ち着いてきたので、blog更新。
　ATOKが見付からないのは地味に困るなあ。やっぱり変換精度がどうも…。

　あと、SSH2の為にPuTTYごった煮版を使ってたけど、やっぱりTeraTermの方が馴染むなあ、と思って検索してみたら、今はオープンソースの後継版（原作者公認）があるようで。SSH2対応版TTSSHも同梱らしく。
　ということで、そっちに移行する。

　SSH2な秘密鍵はPuTTYで作ったのだが、拡張子がppkとかなってて、TeraTermでそのまま使えるかどうか怪しい。ファイルの中身をちょろっと見てみると、何かいかにも互換性が無さそうだった。ふむ。どうすんべ。
　何となくputtygen.exeを起動すると、「既存の秘密鍵の読込」とかいう項目があったので、まず読み込む。
　で、メニューバーを見ると「変換」→「OpenSSH形式へエクスポート」なる物が。これだな。生成しよう。オーケーオーケー、接続成功。
　つーか、TeraTerm側に付属の鍵生成ツールは激しく貧弱だし、puttygen.exeで生成してエクスポートする方が便利なんじゃ、と思った。というより普通はリモートシェルでUnix使えるだろうからssh-keygenで…、は駄目だな。リモートで秘密鍵とか（笑）。

　まあ、大体の環境は戻った。
　Webアプリに走る人の気持ちが少し分かった気もした。でもうちのAthlon64 3500+だと結構重いんだよな。C2Dな環境でiGoogleとか触ったら軽かったけど、それでもまだ重い。ネットワークのレイテンシはビジネス用途なら隠蔽可能だろうけど（ゲームですら隠蔽出来てるんだし）、単純にローカル処理が重い印象。
　とはいえ、時間の問題かもなあ。Webアプリで済むんなら、お高いWindowsである必要ってほとんど無くなるんだろうか。とは言っても、アプリの蓄積が半端じゃないよなあ。俺はゲームやりたいから当分逃げられないだろうし。

　そーいやWordPressの記事エディタって自動保存までしてくれるのな。書き掛けて速攻捨てたはずのエントリが下書きで残ってたりするんで何かと思ってたが。Ajax面白いな。ババーン。チャーチャラララーチャラララー。昔のコナミは良かったな畜生。七面だっけ、超あり得ない速度で落下する敵要塞っぽいの。自機周囲にいきなり湧いてぐるぐる回って止まって突っ込んでくる敵が好きでさー。四面のボスの攻撃が嫌いでさー。あとどこだったか忘れたけど、ボス絡みで突然死バグもあったよな。そろそろボケが長いな。
　まあ、自動保存してくれるなら何も気にならないんで、さらばAreaEditor。
　でもさー。textareaの仕様がそもそもタコなのはどうにかならんのかね。ESCでリセットとか余計なお世話だっつーの。

　直前のエントリで、素晴らしく文字コードの混在した糞XMLファイルを得るところまでは行った訳だが、ふと思ったのだ。
　こいつを無理矢理文字コード統一すりゃいいんじゃ？

　つーことで、Perl5.8の出番である。ネイティブでUCS対応であり、Encode.pmも割と安定している様子でもある。
　ただ、EUCとUTF-8の区別は元々難しそうな気もする。短い文字列では特に。Encode.pmが手抜きコードでないことを祈る。まあ、日本人も関わりまくってるだろうから平気かなあ。どうだろうなあ。
　ともあれ、書いてみる。Encode.pm側で文字コードを決めきれない時はエラー終了するようにしておこう。

use strict;
use utf8;
use Encode;
use Encode::Guess qw( euc-jp );
use FileHandle;

my $target = 'wordpress.2008-01-02.xml';

my $in = new FileHandle $target;
binmode $in;
my $out = new FileHandle ">out.xml";
binmode $out;

while ( defined ( $_ = <$in> ) ) {
	my $decoder = Encode::Guess->guess( $_ );
	ref $decoder or die "Can't guess at line $.";
	print $out encode( 'shift_jis', $decoder->decode( $_ ) );
}

close $in;
close $out;

　こんなもんか。超俺専用のその場書き捨てコードだな。でもまーファイルネームのとこだけ書き換えればみんなで使い回せるね！（使わない）

　つーか思いっきり行単位で処理してるけど大丈夫かなあ（笑）。
　まあ、万が一漏れがあったら、バックアップから手作業で直すか。もうマジめんどくせーし（笑）。
　何気に出力をShift_JISにしているが、UTF-8に直接出すと波形ダッシュ問題に引っ掛かる可能性が出てくる為である。本当はbinmodeで$outのencodingをどうこうなんじゃないかとか思ったが調べるのめんどいので。

　で、Encode::Guessをutf-8とeuc-jpだけに限定したお陰か、全て迷わず判別してくれたようだ。信じていいのかは知らないが。
　つーことで、仕上げにローカルのテキストエディタでXMLファイルを丸ごとUTF-8に変換してから、真っ新のWordPress日本語版（MEでなく本家側にいつの間にかあった）の環境を鯖上に構築し、インポートしてみる。成功。おおおおお。

　その後、ちょこちょこ弄ったけど問題無さそうなので、公開してみる。
　何か問題が出ていたら突っ込みをお願いしたく。

　なお、海外のテーマが壊れる問題は無くなったし、ダッシュボードがまともに表示されない問題も解決した。めでたし。

　あけましておめでとうございます。今年もよろしくお願いします。

　新年を機に、今度こそWordPress ME 2.0を脱却すべくUTF-8に移行しようとしたわけですが。
　本家版2.3を別ディレクトリに用意して、DBをUTF-8に移行して、とかやって、またしても失敗した訳で。

　で、もう何か根本的に違う方法でいいからどうにかしちまおうぜ、と思って、エクスポートしてインポートするという手法がありそうだなと思った訳さ。
　んで探したら、XMLでエクスポート可能らしいじゃん。そりゃいい。WXR形式とか呼ぶらしいがどうでもいいな。とにかくやってみようぜえ。
　えーと。2.1以降で標準装備か。2.0だとWordPress-to-WordPress Importプラグインって奴が必要らしい。オーケーオーケー。早速入れるぜ。
　動かないぜ。

　えーとー。

　MEだとバージョンチェックが狂うっぽいのかな。substr( get_bloginfo(’version’), 0, 3 )のとこを、0じゃなくて2に書き換えればいいらしい。二ヶ所とも。MEだとバージョン文字列の頭に二文字ゴミでもあるのかな。知らんけど。ああ、もしかしたらこの’ME2.0.x’ってそのままバージョンなのかな。なるほど分かりやすい。
　つーことで、書き換えたら使えるようになった。

　で、エクスポートしてから、試しに新環境を立ち上げてインポートしてみたら、記事本文が全く読み込まれない。うぜえ。
　XMLファイルの中身を見てみる。
　本文だけEUCです。タイトルとかその他全部UTF-8です。
　マジうぜえ。

　適当に検索した感じ、どうやらこのバグは把握されてるけど放置状態のようだ。EUC環境の人はDBを直接バックアップしてね、という状況のようで。はあ。
　MT形式に吐き出すプラグインとかもあるらしいが、うーむ。何か情報が欠けそうでなあ。
　まあ、またしばらく考えてみるか…。