Office Oh!NO の部分的改定作業の引鉄となったのは、Movable Type v4.10→v4.21 アップグレードの失敗だ。
原因を特定するのに、かなりてこずったが、結局、Ver.3 の頃の Movable Type の文字コードセットの“イイカゲンさ”が全ての元凶だと言える。
そして、バックアップ機能も備えていない Ver.3 の頃の Movable Type を使いつづける事に不安を感じて、MySQL を直接弄れる phpMyAdmin を導入しておいた事が、つくづく『よかったぁ』と感じられる出来事だった。
Ver.3 の頃の Movable Type の文字コードは MySQL の入れ物（データベース）に出し入れする時に、特に指定できるようにはなっていない。そして、驚くべき事に、私の場合には、勝手に latin1_swedish になっていた。
Movable Type でブログをはじめてから phpMyAdmin 導入直後まで、私には文字コードに関する知識は無かったので、ブログのデータを直接見ようとして“文字化け”しているのを不思議には思わず『まぁ、こういうものなのかなぁ』と思っていた。
ある時、phpMyAdmin での文字化けは、文字コードの設定に原因があるってのをネットで知って、自分のを調べてみたら・・・・・・・という経緯で、自分のがスウェーデン語だったと知ったわけだ。
しかし、それでも、Movable Type v4.10 へのアップグレードまでは何の問題も無かった。。。。だが、v4.21 へのアップグレードでそれが問題化したのだ。（v 3.xx と v4.xx とでは、Movable Type が MySQL の中に作るデータベースの構造はまるっきり違うものになっているが・・・）
具体的に私の場合は『フィールド“template_name”に設定したサイズ（byte）より大きな値が入っているから、データのコンバートはこれ以上進められない』ってな感じ（意訳）の英語メッセージが出で、途中で終了しちゃったのだ。
途中で終了しちゃったので、もう、以前に戻せない。。。。（号泣）
にっちもさっちの行かなくなって、『絶対、アップグレード完了しなきゃ』って、フィールドのサイズを強制的に大きくしてみた。。。。。だが、Movable Type は各フィールドのサイズを“厳密”に規定しているみたいで、phpMyAdmin で強制的に変更してみても、戻されちゃう。
・・・・途方にくれて、ふと気づいたのが、文字コードのこと。
文字コードの照合順序にスウェーデン語なんて順番になっているからだよ！って事で、utf8_unicode に変更してみたら、、、、、なんと、アップグレード完了しちゃったのだ。もう一箇所“template_name”もダメ出しされたので、それも変更して・・・・。
で、意気揚揚と“再構築”してみたら、、、、唖然！！・・・・愕然！！
めちゃくちゃ、文字化け・・・・・。
まぁ、当然といえば当然で、MySQL に格納されているコードをそのまま、別の文字コードとして読み出したんだから。
というわけで、今までの“忌まわしい”文字コードを含んだデータベースは綺麗さっぱり削除して、一から構築する事にしたわけだ。幸い、今年の初めに Movable Type v3.36 → v4.10 の時のバックアップを取ってあったから、そこまでは復活させられる・・・。
心機一転、今度は、MySQL でデータベースを作る段階から、phpMyAdmin で文字コード関連は全て utf8_unicode にして、新規に作成した。だから、眺めていると、、、
－－－気持ちいい－－－
結局、MySQLでは、Ver.3 の頃の Movable Type の文字コードセットの“イイカゲンさ”のおかげで phpMyAdmin の存在を知り、それを使えるようになったのは、悔しいけど自分のスキルアップに貢献した。。。。。
と、まぁ、世間に良くある『失敗こそが勉強になる』を地でいったようなお話でした。もっとも、パソコンに関しては、失敗の方が、圧倒的に多いのだが、、、、