XOOPS Cube UTF-8化：Utf8LangMgrの負荷問題
以前次世代のXOOPS「XOOPS Cube」を言語ファイルの書き換えなしにUTF-8化するモジュール「Utf8LangMgr」を紹介しましたが、それに関してこんな記事を発見しました。
Myalbum-pをUTF-8環境でインストールすると文字化けする（Xoops Users Group Japan）
要は、Utf8LangMgrでXOOPS CubeをUTF-8化して運用するとサーバの負荷が非常に大きくなるとのこと。考えてみれば読み込む度にチェックするわけですから重くもなりますね。
XOOPS自体結構サーバに負荷がかかるシステム（※厳密に言えば使用するモジュールによります）ですから、XREAなんていう格安サーバでコレつかったら使い物にならないサイトになっちゃいそうです。
となると、現状UTF-8化は従来のlanguageファイルの文字コード変換（EUC−JP ⇒ UTF-8）以外に術がない、ということになります。
確かにこの方法の方が確実でしょうし、負荷も小さいのでしょうが、アップデートの度にUTF-8化しなければいけないのが非常に面倒なのと、languageファイル以外でエンコードを指定している部分があるモジュールの場合はそれも探して修正しなければいけない訳で、早い話非常に面倒なのです。
ただでさえアップデートは億劫なのに、UTF-8化のために余計に手間を取られるということで、さらにやる気が……
以前はこれが嫌でXOOPS Cube以外のCMSも物色してみたのですが、日本ではXOOPSが圧倒的なシェアを占めていて、他のCMSの情報は非常に少ないのです。
私のようにPHPやデータベースについてはシロウトにウブ毛が生えたぐらいのレベルでしかない者にとって情報が少ないのは致命的。何か問題に遭遇するとその場でTHE ENDとなってしまいます。
以前物色したCMSの中ではUTF-8でマルチサイトも可能なTypo3に魅かれたのですが、その後いろいろ調べてみた結果、Typo3はかなり敷居が高いことが判明。
英語云々というレベルの話ではなく、日本のレンタルサーバではまだ少数派であるPHP5、MySQL5仕様が前提で、おまけにカスタマイズにはTypo3特有の記述法を覚えないといけないとかなんとかいう話で、腰が引けてしまったのです。
WEB屋ではないので、コレばかりに時間を取られる訳にはいきません。XOOPSはシロウトなりに積み重ねてきた知識と経験があるので、なかなか離れられないのが現実ですね。
そんな訳でまたふりだしに戻ってしまった感じです。現状では従来の方法でUTF-8化したXOOPS Cubeを選択する他ないような気がしますが、まだTypo3に未練が残るワタクシ。自殺行為になるのは目に見えているのですが……
