とあるXOOPSサイトのサーバ引っ越しを機に、EUC-JPからUTF-8に文字コードを変更することにした。
近い将来 XOOPS Cube もデフォルトの文字コードがUTF-8に変更されるはずだし、現状でも環境は整っているので、今のうちに準備しておこうというわけである。

EUC-JPなXOOPSからUTF-8なXOOPSへの引っ越し。
というだけならば、さほど面倒なことはなく、巷に情報も溢れている。
特に同じサーバ内で文字コードを変更するだけなら、さしたる問題がないケースが多い。
しかしながら、今回は仕様の異なるサーバへの引っ越しのうえに、ひと筋縄でいかない非常にめんどくさい事情もろもろがあったので、ちょっと記しておきたい。

まずはデータベースのサイズ。
これがでかいのだ。
非圧縮で約330MBあり、tgz圧縮で約40MBある。
旧サーバは割り当てメモリが少なくまた非力なこともあって、一括バックアップをしようとしても、XOOPSのバックアップモジュールはもちろん、 phpMyAdminでもエラーが出る。
なので、シェルからコマンドラインで行うか、スクリプトで実行するしかない。

バックアップするだけならまだいいが、問題はリストア。
一括バックアップではファイルサイズが大きすぎてphpMyAdminでは書き戻しできないので、Bigdumpなどのツールを使うか、コマンドラインから行う必要がある。
それだけならちょっとの手間であるが、EUC→UTFに文字変換したした場合、そのなかに機種依存文字なんかがあると、リストアの途中でエラー終了してしまうのである。
(一般に掲示板なども公開しているサイトなので、ユーザによる書き込みには機種依存文字がけっこう多いのだ)
そのため、単に文字コードを変換するだけでではなく、SQLファイルをテキストエディタで編集する必要があるのだが、AMD最強マシンをもってしても 300MBものファイルを編集するのは重たすぎてめちゃくちゃたいへん。
以上のような理由でスカッと一括バックアップ&リストアは諦め、モジュール単位でテーブルをまとめてバックアップすることにする。
このほうがエラーが出た場合など原因となる箇所を突き止めやすいし、1箇所ダメだから全体がダメという自体にも陥らない。
人間横着しちゃいけないということか。

そもそも上述したように、旧サーバはマシン自体が非常に非力なうえに、チューニングが悪い。
バックアップやレストアしている間はWebページの表示ができなかったりする。
データベースだけでなくファイルのバックアップでも同様である。
なにかにつけエラーが出たりタイムアウトしたりで作業が中断する。
一括ではなく、ちまちまが似合っているのだ。

さて、これで問題が解決したかという序の口である。
最大の問題は文字コードである。
一般的な「EUC-JPなXOOPSからUTF-8なXOOPSへの引っ越しガイド」では、データベースの文字コードを変換し、DEFAULT CHARSET の設定をEUC-JPからUTF-8にすればよいというようなことが書いてある。
しかしそれは「お行儀のよい」サーバの話である。
もともと旧サーバは契約時にMySQL4系/PHP4系だったのが、途中でMySQL5系/PHP5系に移行しており、それに伴い MySQLの文字コードもUTFに変更されている。
しかし、UTFで統一されていればまだしも、こんな感じになっている。

mysql> show variables like “char%”;
+————————–+—————————-+
| Variable_name | Value |
+————————–+—————————-+
| character_set_client | binary |
| character_set_connection | binary |
| character_set_database | binary |
| character_set_filesystem | binary |
| character_set_results | binary |
| character_set_server | binary |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+————————–+—————————-+

対して新サーバはこんな感じ。

+————————–+—————————-+
| Variable_name | Value |
+————————–+—————————-+
| character_set_client | binary |
| character_set_connection | binary |
| character_set_database | binary |
| character_set_filesystem | binary |
| character_set_results | binary |
| character_set_server | binary |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+————————–+—————————-+

これが両方とも自サーバであればなんでもなるわけだが、両方ともレンタル・サーバであるから、MySQLの仕様を勝手に変更することはできない。
さらにややこしいことに、旧サーバの旧環境にインストールしたXOOPSのデータベースは、EUC-JPとlatin1が混在しているのである。
ひどいケースだと、同一テーブルでもフィールドによって文字コードが違っていたりする。
いろんなサイトのいろんな情報をもとに、コマンドラインからいろんな指定をして出力してみたり、さまざまな方法を試してみたが、どれもうまくいかない。
問題はバイナリの部分で、SQLのダンプファイルの文字コードを変換しても、バイナリで記録されている部分は、サイト表示で文字化けしてしまうのである。
試行錯誤の結果、シロートも眉をひそめるドシロートな方法(© hirasawa)で乗り切った。

01) phpMyAdminからモジュール単位でSQL形式でエクスポート
02) エクスポートされた文字列をテキストエディタにC&Pし、UTF-8で保存(*1)
03) 機種依存文字をエディタのマクロで置換(*2)
04) DEFAULT CHARSET でEUCやlatin1になっている部分をUTF8に置換
DEFAULT CHARSET=utf8
05) 新サーバのphpMyAdminでインポート
06) Web表示で文字化けする部分（バイナリ部分）はテーブル単位で、CSVデータ形式でエクスポート
07) エクスポートされた文字列をテキストエディタにC&Pし、UTF-8で保存(*2)
08) 新サーバのphpMyAdminで対応するテーブルをいったん空にする(*3)
09) 新サーバのphpMyAdminで対応するテーブル選択してからインポート
インポートするファイルの形式→LOAD DATA する CSV→テーブルデータを差し替えるファイル(チェック)

*1 ファイルに出力してから文字コードを変換するよりも、手っ取り早く、文字化けする可能性が低い

*2 「〜(波ダッシュ」や「−（全角マイナス）」は機種依存文字ではないが、文字コード変換時に全角チルダや全角ハイフンになったり文字化けしたりするのでこれも置換する。
いわゆる全角チルダ問題に関しては、まったくMSを呪い殺したくなります。
www.kab-studio.biz/Programing/JavaA2Z/Word/00000716.html

*3 やらなくてもいいが念のため。

以上がシロートも眉をひそめるドシロートな方法(© hirasawa)の実体である。
次回、ファイルの変更、設定その他について書く、かも。

出来損ないのブラウザのくせに、IE6は未だにトップシェアである。
もうじきIE7にリプレイスされそうだが、それでもまだしばらく生き残るだろう。
Win98とかIE7が使えない環境ならいざ知らず、なぜにXPでIE6を使い続けるのか理解できないが、それがプリインストールの強みなのだろう。
Windowsにおいては、きっとFirefoxやOperaなんてその存在すら知らない、というよりブラウザが「選べる」ものだということすら知らないユーザがマジョリティなのだろう。
自分に与えられた自由や権利に気づかないのが無知の恐ろしさであり、管理する側にとっては幸いなのだろう。
自由は恐怖であり、逃避・放棄すべきものなのだ。

などと真面目なフリをしてみたが、実はIE6でアルファチャンネル（透過）PNGが表示できないとは知らなかったよ、ごめんなさい、という話である。
FF3とIE7だけで検証しちゃいけませんね。
いくらできそこないでも、トップシェア様を無視しちゃいけません。
というわけで対処法（IE6やIE5.5で強引に透過PNGを表示させる方法）を検索したら、出るわ出るわ、いっぱいあるのね。

homepage.ntlworld.com/bobosola/pnghowto.htm
www.twinhelix.com/css/iepngfix/

上記が有名どこみたいで試してみたが、CSSで背景指定したPNGとHTMLで指定したPNGを重ねてきれいにIE6で表示できるのは、後者の PNGFix v2.0 Alpha だったので、ファッシネイション本家サイトに導入してみた。

XOOPSの場合は使っているテーマの組み込むのが手っ取り早い。
まずはこちらのファイルをダウンロード。
www.twinhelix.com/test/iepngfix.zip

展開してできる iepngfix.htc iepngfix_tilebg.js blank.gif の3ファイルを使用しているテーマのディレクトリへ。
もし blank.gif を同階層ではなくimagesディレクトリなどへ置く場合は、iepngfix.htc を編集して相対パスを記入しておく。

ex)
IEPNGFix.blankImg = ‘blank.gif’;
–>
IEPNGFix.blankImg = ‘images/blank.gif’;

あとはtheme.htmlのヘッダ部分に下記を追記。

<!--[if lt IE 7.]>
<style type="text/css">
img, div { behavior: url(<{$xoops_imageurl}>iepngfix.htc) }
</style>
<script type="text/javascript" src="<{$xoops_imageurl}>iepngfix_tilebg.js"></script>
<![endif]-->

相対パスではうまく動作しないみたいなので< {$xoops_imageurl}>でテーマディレクトリを指定。
IE7.x未満にだけ適用されるように、IEの独自拡張で[if lt IE 7.]と指定。
ほかのブラウザには影響ない。

これで出来損ないブラウザへの対応終了。
ありがたくドネーションをPayPalで支払ったのであった。

……とオチをつけて終わろうと思ったら、検証用に使っていたVM上のIE6で透過ではないPNGも表示されなくなった。
一瞬だけ表示されて消える怪現象。
調べてみると、WindowsでのPNGがらみの不具合は多いらしく、レジストリが壊れているせいだとか、いろいろあるが、修正できない。
結局、5年振りくらいにVMwareにWin98を再インストールしましたよ。

Firefox3では、入力フォーム周りのレイアウトが崩れやすいようだ。
上位のテーブルなどで幅を固定していても、input の size や textarea の cols を指定しておかないと、テーブル幅を無視してどどーんと入力エリアが突き抜けたりする。
XOOPSでは入力フォームを多用するので、テンプレートでいちいち上記を指定してやんないと、テーマによってはぐちゃぐちゃになります。

まずテーマ・スウィッチャ以前に。

XPressモジュールでは、XOOPSとWordPressを行ったり来たりできるようになっている。
XOOPSモードでは「メタ情報」に「WordPressモードへ切替」というメニューがあり、これをクリックするとWordPressモードへ切り替わる。
翻ってWordPressモードでは、サイドバーに「Change to XOOPS Mode」というようなメニューを設けてあるので、そこをクリックするとXOOPSモードへ切り替わる。
ところで「モードってなによ」であるが、ユーザにとってはルック&フィールの問題でしかありません。
まあ、見た目と操作方法の違いであって、文章の中身は変わりません。

WordPressには標準のHTMLエディタとしてTinyMCE（ビジュアルエディタ）が搭載されているほか、プラグインとしてFCKeditorなどがある。
(ほかに、WYSIWYGではない、テキストエディタに毛が生えた程度のHTMLエディタも搭載されている)
FCKeditorはXOOPS本体でも使っているので、 WordPress(XPressMEモジュール)でもFCKeditorのプラグインを使ってみた。
しかし、なぜか二重の改行が入るという怪奇現象が起きる。
はじめは、PとBRの問題かと思ったが、編集中にFCKeditorでソースを見ると、ちゃんとBRになっている。
しかし、プレビューでは、BRが二重に入ってしまっている。

この問題とは長い間格闘したが、結局はFirefoxとの相性問題というか、バグではあることがわかった。
ふだんIEを使っていればすぐに気づきそうなものだが、あいにくふだんのデスクトップはFedoraである。
さて、ブラウザごとの同確認結果が次の通り。

●InternetExplorer7
標準エディタとFCKeditorの両方が正しく動く。

●InternetExplorer6
標準エディタは動作しないので、単なるテキストエディタに代替される。
FCKeditorは正しく動く。

●Firefox2.0
標準エディタは正しく動作するが、FCKeditorは正しく動作しない
(と思ったら、使ってるうちにShift+Enterで改行できなくなった、なぜだ)

——————————–
2008/07/04追記
Shift+Enterで改行できないのは、単にAtokの「推測確定 」にキーアサインされていたからであった。
Atok側の設定をControl+Enterにしたらば、ちゃんとShift+Enterで改行できるようになりました。
——————————–

●Win版Safari
標準エディタは動作しないので、単なるテキストエディタに代替される。
FCKeditorも正しく動作しない。

FCKeditorはデフォルトで、EnterキーでPタグを、Shift+EnterでBRタグを出力するが、fckconfig.jsというファイルを編集すれば変更できる。

FCKConfig.EnterMode = ‘br’ ; // p | div | br

FCKConfig.ShiftEnterMode = ‘p’ ; // p | div | br

標準搭載のビジュアルエディタ（TinyMCE）も、EnterキーでPタグを、Shift+EnterでBRタグを出力するが、いったいどこかで切り換えられるのだろうか。

なお、FCKEditorプラグインを有効化した場合は管理ページの[ユーザー]設定で[記事投稿時にビジュアルリッチエディタを使用する]の
チェックを外しておかないと不具合が起こることがある。

XOOPSの設置やメンテナンスをサポートしている某サイトや某サイトや某サイトでWeblogモジュールをインストールしているが、WordPressはけっこう「クセ（仕様とも言う）」もしくは「バグ（仕様とも言う）」のようなものあり、実際に自分で使ってみないことには細かな点はどうもよくわからない。
というわけで、試験導入したモジュールを公開して運用してみることにした。
要は動作検証用サイトであるからして、しょっちゅうデザインが変わったり、動作しなくなったり、放置されたり、予告なく廃止されたりするかもしれない。
また、moderoomは本来、平沢進/P-MODEL関連の情報を扱うサイトだが、ここはなんでもありで、関係ないことも書く。
いや、関係ない話のほうが多くなる気がする。
穴埋め（記事の数がないと検証できない）や備忘録のためにBBSなど既存のコンテンツのリサイクルする予定なので、新着記事は更新の時系列とは必ずしも一致しません。
では、よろしくお願いいたします。