ホーム > フォーラム > 開発 > コア開発 > 文字コードのクライアントハンドシェークは正しい処理?

文字コードのクライアントハンドシェークは正しい処理?
投稿者: orrisroot | 投稿日時: 2007/2/23 16:11 | 閲覧: 67961回
orrisroot
こんにちは.

RC を利用していて気になった点についてです.
/modules/legacy/language/japanese/charset_mysql.php
についてですが,この MySQL の文字コードのクライアントハンドシェークはこれでいいんでしょうか?

--

1.character_set_server, collation_server のところは必要ない?
この値が影響するのは,データベースを新規に作成する場合ぐらいかと思います.

試しにもともと character_set_server が latin1 で動作しているサーバに対して charset_mysql.php 中の character_set_server, collation_server のクエリを投げてから root 権限で CREATE DATABASE (イントロデューサなし)を発行したところ指定した文字コードのデータベースが作成されました.

ということで,あらかじめ作成された1つのデータベースに対して操作を行う XOOPS Cube では無駄な設定かなーと.

2.character_set_database, collation_database のところは必要ない?
この値が影響するのは,どのような場合でしょうか?

上記のデータベースの時と同様にテーブルの新規作成に影響するのかと思って,character_set_database が latin1 のデータベースに対して,charset_mysql.php 中の character_set_database, collation_database のクエリを投げてから CREATE TABLE (イントロデューサなし)を発行したところ指定した文字コードのテーブルは作成されず,latin1 のものができてしまいました.

あと考えられるのは,クライアント・サーバ間の文字コード変換機能についてかと思ったのですが,だとするとサーバ側の文字コードを決めつけてしまうことになりますので逆にデータベース内の文字化けの原因につながりそうな気がします.

--

ということで,上記 1.2.のサーバの文字コード設定に関するクエリは必要ないかと思いますがいかがでしょうか?

逆にこれによって,懸念する足かせが外れるため,サーバ側 utf8,クライアント側 ujis で自動文字コード変換させ,仮にクライアント側を他のマルチバイト環境に動的に切り替えても,サーバ側には特に影響なし.のような恩恵にもあずかれるような気がします.

以上です.一考いただければ.

コメント(21)

新しいものから | 古いものから | ネスト表示 | RSS feed
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: onokazu | 投稿日時: 2007/2/24 12:59
onokazu
引用:

1.character_set_server, collation_server のところは必要ない?
この値が影響するのは,データベースを新規に作成する場合ぐらいかと思います.

試しにもともと character_set_server が latin1 で動作しているサーバに対して charset_mysql.php 中の character_set_server, collation_server のクエリを投げてから root 権限で CREATE DATABASE (イントロデューサなし)を発行したところ指定した文字コードのデータベースが作成されました.

ということで,あらかじめ作成された1つのデータベースに対して操作を行う XOOPS Cube では無駄な設定かなーと.


インストーラがデータベースを作成する場合には有効ですが、そうでない場合には確かに
必要がなくなるかもしれないですね。

引用:

2.character_set_database, collation_database のところは必要ない?
この値が影響するのは,どのような場合でしょうか?

上記のデータベースの時と同様にテーブルの新規作成に影響するのかと思って,character_set_database が latin1 のデータベースに対して,charset_mysql.php 中の character_set_database, collation_database のクエリを投げてから CREATE TABLE (イントロデューサなし)を発行したところ指定した文字コードのテーブルは作成されず,latin1 のものができてしまいました.


データベースのcharacter_set_databaseがそのデータベース内に作成されるテーブルの文字コードを
決定するようなので、確かに必要ないかもしれないですね。

引用:

あと考えられるのは,クライアント・サーバ間の文字コード変換機能についてかと思ったのですが,だとするとサーバ側の文字コードを決めつけてしまうことになりますので逆にデータベース内の文字化けの原因につながりそうな気がします.


この辺り詳しくないですが、SET NAMES ujisでcharacter_set_connection/_client/_resultsを
ujisに指定しているので、これらの設定と、テーブル内の文字コード(テーブル作成時に指定済み)を
使用して変換を行なうものと思っていたので、文字化けにつながるような問題にはならないと思う
のですが、いかがでしょうか。
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: orrisroot | 投稿日時: 2007/2/27 11:03
orrisroot
こんにちは。

引用:
引用:
あと考えられるのは,クライアント・サーバ間の文字コード変換機能についてかと思ったのですが,だとするとサーバ側の文字コードを決めつけてしまうことになりますので逆にデータベース内の文字化けの原因につながりそうな気がします.


この辺り詳しくないですが、SET NAMES ujisでcharacter_set_connection/_client/_resultsをujisに指定しているので、これらの設定と、テーブル内の文字コード(テーブル作成時に指定済み)を使用して変換を行なうものと思っていたので、文字化けにつながるような問題にはならないと思うのですが、いかがでしょうか。


うーん。そーですか。ということは、
CREATE DATABASE cubedb CHARACTER SET utf8;
として作成したデータベースでも japanese ならば文字コードの自動変換が正常に働き文字化けなしで正常動作するということかと思いますので

間違った可能性のある文字コードをサーバ側の文字コードとしてクライアント側から明示的に指定していること。

が問題で「システムの動作には影響がない」ようだが「コードの読み手に誤解を与え」かねない「無意味なコード」ということになるのではないでしょうか。

そう考えると、やっぱり、プログラムからは character_set_server, collation_server, character_set_database, collation_database の4行は消しておいた方がよいかと思います。
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: onokazu | 投稿日時: 2007/2/27 15:17
onokazu
そうですね、この辺りなんらかの検討が必要かもしれないですね。
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: orrisroot | 投稿日時: 2007/2/27 15:21
orrisroot
引用:
そうですね、この辺りなんらかの検討が必要かもしれないですね。

はい.ご検討よろしくお願いいたします.
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: minahito | 投稿日時: 2007/2/27 15:44
minahito
引用:

orrisrootさんは書きました:
うーん。そーですか。ということは、
CREATE DATABASE cubedb CHARACTER SET utf8;
として作成したデータベースでも japanese ならば文字コードの自動変換が正常に働き文字化けなしで正常動作するということかと思いますので

間違った可能性のある文字コードをサーバ側の文字コードとしてクライアント側から明示的に指定していること。

が問題で「システムの動作には影響がない」ようだが「コードの読み手に誤解を与え」かねない「無意味なコード」ということになるのではないでしょうか。


自分はDBぜんぜん専門外なのでさっぱり分からないのですが、この部分のコードの形成にいたってはMySQL3,4,5 の3バージョンにまたがる問題とかフォーク前のバージョンである XOOPS 2.0.x JP で作成済みのDBからの引継ぎなどの問題がちょっと絡んでいたような気がするので、念のためこの部分をコーディングした人の開発前線への復帰を待って、打ち合わせ待ちにさせてください。

あと、
引用:
として作成したデータベースでも japanese ならば文字コードの自動変換が正常に働き文字化けなしで正常動作するということかと


japanese とありますが、いま同梱されているものは japanese EUC パックなので、ご指摘のとおり、 UTF-8 で作成を行う指示を出す japanese UTF-8 ランゲージパックに japanese EUC パックに含まれる初期化のコールバックがかかることはありません。(もしそういうパックがあったとすれば、それはランゲージパック作成者がコールバックを弄り忘れたバグといえる)

確かギリシア語パッケージが UTF-8 への完全シフトを図っていて、テーブル作成から言語パッケージ内のコールバックまでをそれで統一する作業をやっていたはず...

# にしてもプロフェッショナルな話でさっぱりわからん... orz
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: orrisroot | 投稿日時: 2007/2/27 18:13
orrisroot
引用:
自分はDBぜんぜん専門外なのでさっぱり分からないのですが、この部分のコードの形成にいたってはMySQL3,4,5 の3バージョンにまたがる問題とかフォーク前のバージョンである XOOPS 2.0.x JP で作成済みのDBからの引継ぎなどの問題がちょっと絡んでいたような気がするので、念のためこの部分をコーディングした人の開発前線への復帰を待って、打ち合わせ待ちにさせてください。

あー.そういえば,既存のDBからの引継ぎのことは考えていませんでしたが,私の利用している XOOPS 2.0.x JP の MySQLサーバ側のデータベース文字コードもやっぱり utf8 でした.ハックを入れて SET NAMES ujis とかを mysql database class に埋め込んでいたような..
この場合も考慮対象にはいってるんでしょうか...

引用:
引用:
として作成したデータベースでも japanese ならば文字コードの自動変換が正常に働き文字化けなしで正常動作するということかと

japanese とありますが、いま同梱されているものは japanese EUC パックなので、ご指摘のとおり、 UTF-8 で作成を行う指示を出す...

えーと.ここで書きたかったのは japanese = ujis の意味でした.サーバ側 utf8 クライアント ujis でも SET NAMES ujis さえ発行されていれば根本的に文字化けしないという意味でして..

引用:
# にしてもプロフェッショナルな話でさっぱりわからん... orz

うーん.あたしにゃ minahito さんの書くコードの方がプロフェッショナルな感じがしてまして,逆にこういう根本的なところにしか反応できません.
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: minahito | 投稿日時: 2007/2/28 14:14
minahito
引用:
orrisrootさんは書きました:
えーと.ここで書きたかったのは japanese = ujis の意味でした.サーバ側 utf8 クライアント ujis でも SET NAMES ujis さえ発行されていれば根本的に文字化けしないという意味でして..


あーなるほど、そういう用途のものだったんですね(←そこからか orz)

引用:
うーん.あたしにゃ minahito さんの書くコードの方がプロフェッショナルな感じがしてまして,逆にこういう根本的なところにしか反応できません.


いやヨソの異文化を持ち込んで、元来スマートに書けるスクリプト言語のスタイルを汚しているだけで ...orz ... PHPer からはよく突っ込まれます。ホント申し訳ない...
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: orrisroot | 投稿日時: 2007/3/12 23:23
orrisroot
こんにちは.

もうひとつおかしなところなのですが,このファイル charset_mysql.php でバージョンチェックを入れている数字ですが,

/*!41000 ...


これだと 5.x.x では OK ですが,4.1.x では条件を満たさないようです.
# CentOS 4.4 (RHEL4互換) の 4.1.20 でダメでした.

4.1.x 以降に対応させるには

/*!40101 ...


ではないでしょうか?

4.1.20 についてきた mysqldump 10.9 では,データベース(character_set_database 値)が ujis の場合

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES ujis */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;


などと初期化がなされるようです.
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: minahito | 投稿日時: 2007/4/9 15:09
minahito
上から指摘されたことをぺたぺたはっていったら2行になったのですが(滝汗
結論からすると日本語用charset_mysql.phpは


$GLOBALS['xoopsDB']->queryF("/*!40101 SET NAMES ujis */");
$GLOBALS['xoopsDB']->queryF("/*!40101 SET SESSION collation_connection=ujis_japanese_ci */");


で無問題ということでしょうか?

これを今、はたして無検証でコミットしていいのかどうか(←検証余力ゼロなので皆さんにお願いするしかない)すごく悩んでます。
スペックでの理論上は何の効果も持っていない行を削ったのだから、6行→2行にはなっているが、RC以前とRC2以後は動作は一切変化しないということですよね?
やっちまうか...
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: Marijuana | 投稿日時: 2007/4/9 16:22
Marijuana
引用:
上から指摘されたことをぺたぺたはっていったら2行になったのですが(滝汗
結論からすると日本語用charset_mysql.phpは


$GLOBALS['xoopsDB']->queryF("/*!40101 SET NAMES ujis */");
$GLOBALS['xoopsDB']->queryF("/*!40101 SET SESSION collation_connection=ujis_japanese_ci */");



で無問題ということでしょうか?


ローカル環境に新規インストールする際に2行にして試してみたところ、文字化けしました。
#installディレクトリを変更してました、legacy側では文字化けしません。
元々の6行では文字化けしません。

環境は
WindowsXP
MySQL5.0.27
PHP5.2.1
Apache2.0.59
です。
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: Marijuana | 投稿日時: 2007/4/9 16:33
Marijuana
引用:
ローカル環境に新規インストールする際に2行にして試してみたところ、文字化けしました。

ごめんなさい。installディレクトリも書き換えてました^^;

legacy側を2行にしてインストールしたモジュールのテーブルもujis_japanese_ciになってますし文字化けもなく動いてます。
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: minahito | 投稿日時: 2007/4/9 20:08
minahito
ありがとうございます (^o^)/

ってことは install 側は削るとまずいんですね。
あとは X2 -> XCL で問題が出ないかですが、それに関しては問題が起きても復旧が楽なので RC -> 正式はスムーズにつなげられますね。
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: minahito | 投稿日時: 2007/4/10 12:12
minahito
突っ込みました。
インストール側は、2行に削ると文字化けするということなので MySQL のバージョン判断ミスと指摘された部分のみを修正。

通常起動側は2行です。

インストール時は2行じゃまずいのは CREATE DATABASE があるから? CREATE TABLE とかは本当に無事いけるのか、今度時間があるときにでも見ておきます。誰かモジュールインストールなどでトライした人がいたら情報ください。
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: onokazu | 投稿日時: 2007/4/12 11:30
onokazu
以前、自分がテストした時にインストール側を変更したかは覚えていない(確かしたような気がする)のですが、サーバ側のcharacter_setの各種設定はどのようになっているでしょうか?
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: minahito | 投稿日時: 2007/4/18 17:18
minahito
うーん...

XAMPP 2.3 で、
XOOPS2 2.0.16 JP をインストールした後 -> 2.1 で文字化け発生。

ただ、後から5行パターンに戻しても文字化けするのでよくわかりません。絶対再現パターンでもないらしい... 2.0.16 のテーブル作成時に問題があったかな...
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: orrisroot | 投稿日時: 2007/4/26 20:10
orrisroot
すみません.
自分でスレ立てておいてコメントの更新に気づいてませんでした.
# RC2 が出てることにも気づいてなかったり・・・
とりあえず以下のパターンの組み合わせを適当にチョイスしてやってみます.

- charset_mysql.php を変える(2種類)
 2行,6行
- MySQL のバージョンを変える(3種類)
 4.0 系, 4.1 系, 5.0 系
- RC2のインストール方法を変える(2種類)
 新規インストール, 2.0.16a からのアップデート
- MySQL のDBの言語を変える(3種類)
 ujis(eucjpms), utf8, latin1

連休明けには何とか・・・
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: orrisroot | 投稿日時: 2007/4/27 1:19
orrisroot
はぁ・・・

やっていて,えらくパターンが多そうなのでこれまでの話から類推できるポイントを先に述べてしまします.

1.MySQL 4.0系を使っている人には charset_mysql.php は一切影響しない.

2.RC2 新規インストール時は DB の作成を XCube に任せる場合
  MySQL 4.1系, 5.0系では,MySQL のサーバの言語が character_set_server が ujis 以外の時に文字コード指定をしなければならない.
  a) SHOW VARIABLES LIKE 'version'
    で 4.1 以降か確認して
    CREATE DATABASE dbname CHARACTER SET ujis COLLATION ujis_japanese_ci
    を指定してやる.
  b) install の charset_mysql.php のように character_set_server, collation_server を投げてやる.
  ちなみに b) の操作が仕様として OK なのか,正確な技術資料を見つけられてませんので個人的には a) の方が堅実のような..

3.2.0.16a-JP からアップデートする人は charset_mysql.php は install, legacy とも 2行で OK.ただし,次項4の人は別の問題が起きる.

4.MySQL 4.1系, 5.0系で latin1 のまま 2.0.16a-JP japanese を使っている人は クライアント側がデフォルトの動作で latin1 を名乗っていたものが RC2 アップデート以降 ujis を名乗るようになるため,全体的に文字化けし悲惨なことになる.DB を ujis, eucjpms, utf8 で作り直すより方法がない.ただし,次項5の人は例外
  a) インストール時のエラーメッセージでそのユーザへのシステムでの対応を切り捨てる. FAQ あたりで文面でフォローしておく.
  b) インストーラが根性で DB の再作成を試みる.
    もちろん理屈では内容のバックアップ+ALTER(DB, 全てのテーブル,全てのテーブル内の全ての文字列フィールド)+文字コード変換後リストアでも OK..

5.MySQL 4.1系, 5.0系で skip-character-set-client-handshake を利用してる人
 ・RC2 新規インストール + DB latin1 : 影響なし(※1の問題は残る)
 ・RC2 新規インストール + DB ujis : 完全に影響なし
 ・2.0.16a からのアップデート + DB latin1:影響なし(※1の問題は残る)
 ・2.0.16a からのアップデート + DB ujis : 完全に影響なし
 こんな人には charset_mysql.php が 2行か 6行かは一切関係ない.

6.MySQL 4.1系, 5.0系で RC2 新規インストール時 DB の作成を自分でやる人
 ・CREATE DATABASE dbname CHARACTER SET ujis COLLATION ujis_japanese_ci
 ・CREATE DATABASE dbname CHARACTER SET eucjpms COLLATION eucjpms_japanese_ci
 ・CREATE DATABASE dbname CHARACTER SET utf8 COLLATION utf8_generic_ci
 とかでちゃんと文字コード指定して作成してれば install 側の charset_mysql.php も 2行で問題なし.

7.install 側にも character_set_database, collation_database はやっぱりいらない.

※1:
 latin1 な DB に EUC-JP の文字コードを格納しているため,例えば 'あい' 0xA4,0xA2,0xA4,0xA4 の文字が '△' 0xA2,0xA4 の検索キーワードでヒットする.そりゃそーですね.

--
これらはまだ類推段階ですが4.あたりが実証できれば一番多くのユーザが陥りそうな問題になるような気がしてます.minahito さんが嵌っているのもこれかと.
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: Marijuana | 投稿日時: 2007/4/27 12:38
Marijuana
MySQL5.0.37で軽く試してみました。
mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | latin1 |
| character_set_connection | latin1 |
| character_set_database   | latin1 |
| character_set_filesystem | binary |
| character_set_results    | latin1 |
| character_set_server     | latin1 |
| character_set_system     | utf8   |
+--------------------------+--------+

skip-character-set-client-handshakeは使ってません。
この状態でX2.0.16JPをインストールしてXC2.1へアップグレードしてみました。

1.X2.0.16JPインストール(client,serverともlatin1なので文字化けなし)
2.XC2.1へアップグレード(2ndインストーラから先に進めません)
*↓状況から恐らくSQLでエラーになってると思うけど確認してません
3.legacyのcharset_mysql.phpを2行ともコメントアウト(これで2ndインストーラが機能しました)
文字化けせずに動作。

こんな環境ってWindowsぐらい?
X2でMySQL4.1以上だとSET NAMES ujis投げないと文字化けする環境の方が多そうだけどね。

バージョンと設定でたくさんの組み合わせあるから100%の対応なんて無理だろうし、極少数のパターンに対応させるぐらいなら別の部分に時間使って欲しいと思う。

そもそもX2はMySQL4.1以上って動作環境に入ってないから、アップグレードはあまり考慮しなくていいんじゃない?
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: minahito | 投稿日時: 2007/4/27 13:11
minahito
まぁ時間を使うも何も僕は最初から何も分かってないんですけど(爆

orrisrootさん、ありがとうございます。
もしまた何かわかったら教えてくださいませ。 m(__)m

(.net移動後にパッチトラッカーを動作させるので、そこからなどからパッチを投稿できるような体制をいま作っています。)

基本的には orrisroot さんが示してくださった2行パターンでほとんどのケースはうまくいくようなので安心しました。初期化工程は複数のオーバーライド手段があるのでサイトに応じてチューンナップできると思いますが、さしあたって 2.1 段階では、 LEGACY_JAPANESE_ANTI_CHARSETMYSQL を定義するプリロードをおけばこのLegacy標準パッケのchaset_mysql.phpの行程はスキップされるようにしました。

2.0.16->2.1 で問題が発生したら、

<?php
define("LEGACY_JAPANESE_ANTI_CHARSETMYSQL", true);
?>


とだけ書いた Hoge.class.php ファイルをサイトプリロードに投げ込めば問題が起こらなくなると思います。

今のところ突撃例にも文字化け障害報告はないので問題ないと思いますが、これでひとまず万全...と思いたいです。
Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: orrisroot | 投稿日時: 2007/4/28 1:23
orrisroot
こんばんは.
Marijuanaさんが 5.0系を試してくださったので,4.1系でやってみました.

やっぱり,
 ・charset_mysql.php:install 6行, legacy 2行
 ・MySQLバージョン :4.1.22
 ・RC2 インストール :2.0.16a からのアップデート
 ・MySQL DB 言語  :latin1
だと失敗します.

ということで正しく文字コードが設定されている 2.0.16a で試してみました.
 ・charset_mysql.php:install 6行, legacy 2行
 ・MySQLバージョン :4.1.22
 ・RC2 インストール :2.0.16a (set names ujis 埋込済)からのアップデート
 ・MySQL DB 言語  :ujis
だとうまくいくようです.

っていうことで MySQL 4.1系, 5.0系の人で latin1 な人は XCube2.1 のアップデートで嵌ります.正しく救済するにはアップデートする前に(2.0.16a-JPを使っている段階)で文字コードを正しく直してやれば,アップデートが正常に動作するようです.

以下,手元で例した救済方法です.
# 誤字があったらごめんなさい.

-- ここから --

MySQL root ユーザ の パスワード root@pass
XOOPS 用 MySQL ユーザ cube, パスワード cube@pass, データベース cubedb

1. 確認
$ mysql -ucube -pcube@pass cubedb
mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+-----------------------------------------------+
| Variable_name            | Value                                         |
+--------------------------+-----------------------------------------------+
| character_set_client     | latin1                                        |
| character_set_connection | latin1                                        |
| character_set_database   | latin1 (← これがlatin1な人は嵌る)            |
| character_set_results    | latin1                                        |
| character_set_server     | latin1                                        |
| character_set_system     | utf8                                          |
+--------------------------+-----------------------------------------------+
6 rows in set (0.00 sec)
mysql>exit

2.データベースをダンプ
$ mysqldump --default-character-set=latin1 -Q --opt -ucube -pcube@pass cubedb > cubedb.sql

3.データベースを削除する
$ mysql -uroot -proot@pass
mysql> DROP DATABASE cubedb;

4.データベースを ujis で作り直す
mysql> CREATE DATABASE cubedb CHARACTER SET ujis COLLATE ujis_japanese_ci;
mysql> FLUSH PRIVILEGES;

5.ダンプした SQL ファイルの文字コードをエディタで正しく書き換える.
 ・エディタは EUC-JP を扱えるエディタを使用する.
  - SET NAMES latin1 を SET NAMES ujis に置換
  - CHARSET=latin1; を CHARSET=ujis; に置換
  - binary 属性を持っているフィールドがある場合
   character set latin1 collate latin1_bin を character set ujis collate ujis_bin に置換
 ・cubedb-fixed.sql などとして保存

6.書き換えた SQL ファイルを作り直した DB に食わせる.
$ mysql -ucube -pcube@pass cubedb
7.XOOPS_ROOT_PATH/class/database/mysqldatabase.php にパッチを当てる
--- mysqldatabase.php.orig	2007-04-27 23:14:10.934832000 +0900
+++ mysqldatabase.php	2007-04-27 23:14:47.677185000 +0900
@@ -85,6 +85,7 @@
                 return false;
             }
         }
+        mysql_query('SET NAMES ujis', $this->conn);
         return true;
     }

7.サイトに接続して,これまでどおり文字化けなしで見えるか確認できればOK.

8.さぁ XCube2.1 にアップデートしましょう.

-- ここまで --

引用:
そもそもX2はMySQL4.1以上って動作環境に入ってないから、アップグレードはあまり考慮しなくていいんじゃない?

それいいですね.

個人的には既に4.0が公式ミラーから消えている状態ですし,逆に新しいものは 4.0 以下を切り捨てる考え方もいいなぁ.

引用:

バージョンと設定でたくさんの組み合わせあるから100%の対応なんて無理だろうし、極少数のパターンに対応させるぐらいなら別の部分に時間使って欲しいと思う。

X2, XC21 の方が 4.1系,5.0系で正しく DB の設定を行う方法を公式に明言してしまう(数あるパターンから 1パターンだけ選んでこれが正しい使い方と言い切ってしまう)と実は時間の節約になったりして.

投票(0)

新しいものから | 古いものから | RSS feed
 
To Top