「Web」カテゴリーアーカイブ

XOOPSのUTFなお引っ越し

とある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を呪い殺したくなります。
http://www.kab-studio.biz/Programing/JavaA2Z/Word/00000716.html

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

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

ごめんね、Firefox

メモリ・リークらしき現象に悩まされていると書いたが、どうやら真犯人は別なところにいたらしい。
グラフィック・ボードを取り替えたら、ウソのように怪奇現象は収まってしまったのだ。

ハードウェア的に故障したのか、ソフトウェアの不具合かはわからないが、Fedora8では問題なく、Fedora10にしてから問題が発生したということは、後者の可能性が高いのではないか。
もちろん、OS入れ替えのタイミングでたまたまハードに不具合が発生した可能性も否定できないが、ほかの環境で検証することなく、古いボードは物入れへ仕舞われてしまった。
いや、仕舞ったのは自分だけど。

Fedora(というかLinux全般?)のドライバ開発は nVIDIA GeForce ばかりに力が入っていて、ATi Radeon のドライバは性能が低かったり、不具合があったりすると評判が悪かった。
しかしながら、事務職である自分にはどうも GeForce は敷居が高いというか、ゲーマー御用達のイメージがあって、これまでは Radeon を使っていたのだ。
いや、 Radeon だってゲーマーが使ってるとは思うけど、自分が使っていたのは X300SE 128MB というロウ・エンド向けだし、使い始めたのは PCI Express になってからで、ほかに選択肢がなくなったからだ。
AGPやPCIの時代はMatroxのMillennium を使っていたし、ISAの時代は…S3 ViRGE とかだったかなぁ……覚えてないや。
確かに、Fedora8でも Radeon では Compiz なんかはフリーズしまくりだったので切っていたが、普通にGnomeで1600×1200表示するぶんには問題なかった。

であるのだが、こうしょちゅうXが落ちるようになったのでは、致し方ない。
とうとう nVIDIA の軍門に下ることになった。
といっても、原因がRadeonドライバと決まったわけではないので投資は最低限。
これまたロウ・エンド向け、いわゆるエントリー・モデルの 9500GT DDR2 512MB というやつ、しかもバルクだが、ゲームなんかまったくやらないので、これで充分である。
いや、ゲームなんかまったくやらないのであればオンボード・チップでよいではないかと言う向きもあるだろうが、1600×1200でワークスペース4面、しかもVMを使ったりするには、オンボードでは頼りないし、そもそも使ってるマザーボードにグラフィック・チップは載っていない。

結果として、不具合は解消されたのだが、ふだんの表示性能は、体感できるほど変わらないのが悲しい。
自分の作業的には前のボードのスペックで充分だったということか。
まあ、それでも4面のワークスペースを行き来するのは軽くなったし、Compiz も問題なく動くようになった。
いや、Compiz が動かなくても、仕事上は関係ないのだけど、まあ、気分の問題だ。

さて。
というわけで Firefox が真犯人ではなかったようなのだが、Flock に比べて Firefox が重たく、メモリ・リークと見られる現象が起きるのもまた確かなようなので、現在も Flock を使い続けている(余計な機能も多いのだが)。
ただ、Firefox もホームディレクトリ上の設定ファイルやプラグイン、アドオンの類をいったん全て消去したら、かなり動作は軽くなった。
ほんとはメジャー・ヴァージョン・アップの際にはいったんそれらを消去して、バックアップから復元すべきらしいのだが、めんどくさいので1.xあたりからずっとそのままにしていたのがいけなかったらしい。
というわけで、Firefox よ、疑って悪かった。

リーク・リーク♪ メモリ・リーク♪

リーク、といってもP-MODELは関係ない。
このところ、メモリ・リークらしき現象に悩まされている。
PCを操作中に急激に動作が重たくなり、しばらくするとフリーズしてしまうのだ。

Fedora10にしてから起こった現象であるが、Fedora10関連のBBSで同様の現象は報告されていないし、Fedora10全般に起きる現象なら今ごろ大騒ぎになってるはずなので、たぶん個別の環境に起因する問題なのであろう。
システム・ログを見てもその痕跡がないので、システム内部でどういう現象が起きているか、その原因がなんなのか、よくわからない。
ハードウェア的な問題かと Memtest86 でメモリを、DFT (Drive Fitness Test) でハードディスクをチェックしてみたが、エラーはなし。

いろんなアプリケーションを停止したりして調べてみたのだが、どうも単独犯ではなく、複数犯のようで、こいつが悪い! という原因の特定ができない。
いちばん怪しいのが Atok X3 for Linux で、次が Firefox3 であり、どちらも以前のヴァージョンでメモリ・リークの前科がある。
Sylpheed (メイル・クライアント) で文字入力中にフリーズしたこともあるので、ほんとは Atok をまず止めるべきなのかもしれないが、別なIMにすると仕事にならないので、これを止めるのは最後にしたい。

Firefox3 にしても、本体に問題があるのか、プラグインに問題があるのかわからないので、プラグインやアドオンの類をすべて無効にしてみた。
Flashのプラグインも過去にメモリ・リークの報告がある。
http://www.bub-site.com/archives/2005/09/000386.html

Adobe製品は伝統的にメモリ管理がなっておらず、野放図にメモリを喰いまくる習性があるので、Adobe Reader や Adobe AIR なんかもかなり怪しい。
あとは、Compiz (デスクトップの表示効果拡張) とかバックアップ・ソフト FlyBack (rsyncのGUIフロントエンド) とか KFTPGrabber とか、挙動が怪しいものはいろいろあるが、そういうのは切ってしまっても仕事上差し支えない。

Firefox本体やプラグインに問題がなくても、JAVAスクリプトなどによってメモリ・リークを引き起こされることもあるらしい。
Firefox にはメモリ・リークをチェックするプラグインがあるので、それを入れてみた。
Leak Monitor
https://addons.mozilla.org/ja/firefox/addon/2490

そうしたら、出るわ出るわ、もうしょちゅうポップアップするのでうざくて使えないほど、メモリ・リークのアラートが出まくる。
Firefox本体の問題ではなく、表示したサイトのスクリプトに問題があるのかもしれないが、やはり Firefox の使用が原因のひとつであるのは間違いない。
にしても Firefox の代替ブラウザといってもなあ。
Opera は動作は機敏だし、悪くはないが、プラグインが貧弱なので、見られないサイトが多い。
テキストと写真程度のHTML文書をローカルで見るなら Konqueror もいいのだが、やはりWebサイトを見て回るには不便だ。

そこで行き当たったのがこの記事。
http://jp.techcrunch.com/archives/firefox-3-beta-1-the-memory-use-says-it-all/
早速 Flock 2.0 をインストールしてみた。
http://flock.com/

Flock は、Firefox をベースに開発されたブラウザで、Firefox のプラグインやアドオンのほとんどがそのまま利用でき、インストール時に Firefox のブックマークや蓄積された個人情報を簡単に引き継ぐことができる。
Flock 2.0 は、Firefox3 がベースになっており、今のところまだ英語版しかないが、Firefoxユーザなら問題なく使えるだろう。
ウリはSNSやブログ、ソーシャルブックマークなどの利用がより便利になった「ソーシャルWebブラウザ」とのことであるが、個人的にはそういう附加機能はどうでもよい。
http://www.atmarkit.co.jp/news/200711/05/flock.html

インストールしてみて、Firefoxより動作が軽快であることがすぐにわかった。
メモリ使用量自体は少なくなく、タブを20とか開いていると180MBくらいはいってしまうが、Firefox3よりはるかに動作が軽い。
そして、悩まされていたメモリ・リークらしき現象の起きる頻度は激減した。
メモリ・リークらしき現象がまったくなくなったわけではないが、我慢できる程度に減った。
Flock の開発には Nautilus の開発元だった Eazel のスタッフがかんでいるというのも納得である。
http://d.hatena.ne.jp/keyword/Eazel

出来損ないのブラウザはいつまでトップで居続ける気か

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

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

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

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

XOOPSの場合は使っているテーマの組み込むのが手っ取り早い。
まずはこちらのファイルをダウンロード。
http://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と入力フォーム

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

Firefox3とIPAフォント

Firefox3の正規版がリリースされた。
Fedora9やUbuntu8.4ではβ版のころ既に標準ブラウザにしていたことだし、対応プラグインもかなり出揃ってきたので、インストールしてみた。

レンダリングエンジンが大きく変わったとかで、フォントの表示もなんか違う。
困ったのはIPAフォントやIPAモナーフォントにアンチエイリアスがかからないことだ。
IPA+Mフォントだときれいに表示されるし、見出し部分だけ汚かったりするので、ローカルな問題かもしれない。
フォント周りは自分でもよくわからないくらいいじっているので、OSをクリーンインストールした状態で入れてみないと、どこに問題があるのか、よくわからない。

しばらくはいじりながら慣らし運転してみることにする。

XOOPSとWordPressを行ったり来たり

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

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

WordPressのHTMLエディタ

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

動作検証用Weblogはじめました

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