編集画面で記事を一覧表示させてみると、すべて文字化け。テンプレートも化けているようで、新規の記事も作れない。読み込んだ元のsqlファイルをエディターで開くと、頭のあたりにSET NAMES ujisという指定がある。MTで使っているのはutf8なので、内部変換でトラブルを起こしているようだ。MySQL4.0で作ったDBの文字コードもutf8を指定していた筈なのだが。phpMyAdminの照合順序もutf_general_ciになっているのは問題ない。しかし、サーバの文字コードがujisになっている。これはMySQLにログイン、自分のDBにコネクトしてから次のコマンドを実行して分かった。
mysql> show variables like 'char%';
そこでset names utf8;を実行。あらためて文字コードを確認。
mysql> show variables like 'char%';
+--------------------------+----------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | ujis |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | ujis |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/share/mysql/charsets/ |
+--------------------------+----------------------------------+
8 rows in set (0.01 sec)
やはりサーバとDBのコードは変わらなかった。さらに、この変更も今の接続限りのもので、ログアウト・ログインしてみるとujisのままなのだ。いろいろ調べてみるとmy.cnfの設定を変えればいいらしい。しかし、それは自分でMySQLをインストールした場合の話で、レンタルサーバの場合、my.cnfにアクセスする権限はないようだ。
試しにDBをujisで作り直してsqlファイルを読み込んでみると、データが7MBくらいに少なくなった上に記事の相当部分が欠落してしまう。やはりutf8のDBにutf8に変換されたsqlファイルを読み込むしか手がないか。この時点ですでに5日ほど経過しており、最悪ブログ記事を失うのではないかと冷や汗が流れた。
微妙であるのは、ブログに公開中の記事は少しも文字化けがなく、どんなカテゴリーでも最初の記事から表示できるのだ。これをフルコピーすれば、少なくともテキスト・データだけは回復できる。しかし、それにしても800以上の記事があるのだ。どれほど時間がかかることか。いや、何よりPCでDBを扱うという行為において、そんなアナログとも思える手段は論外というべきだ。
とりあえず、使えるsqlエディターを入れ直そうと探してoracleのsqlエディターosqleditを入れてみたところ、これが大当たり。ファイルメニューから「文字コードを指定して読み直す」項目の中からutf8を選択したところ、何と一発変換。これにはのけぞるほど感激してしまった。細かいことをいえばujisで読み込んだ時の日本語表示が文字化けしてしまったが、一部だけなので、これは別ウィンドウでutf変換済みの文章と比較して校正。改めてFFFTPでアップロード。Poderosaでコマンドを打ち直してDBに読み込むと、無事に以前のままの記事が復活。万歳！
