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

文字コードのクライアントハンドシェークは正しい処理?
投稿者: orrisroot | 投稿日時: 2007/2/23 16:11 | 閲覧: 73567回
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)

Re: 文字コードのクライアントハンドシェークは正しい処理? 
投稿者: onokazu | 投稿日時: 2007/4/28 20:11
onokazu
skip-character-set-client-handshake ですが、これが設定されていても確かSET NAMESでclient/connection/resultは変更されたかと思います。なので、SET NAMESを常にコールする2.1ではskip-character-set-client-handshakeに関しては特別に考えなくても良いかもしれません。

投票(0)

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