Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
前回の続きで、character_set_connectionをbinaryにした場合を調べてみよう。
mysql> SET @@character_set_connection=binary;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+---------+
| Variable_name | Value |
+--------------------------+---------+
| character_set_client | eucjpms |
| character_set_connection | binary |
| character_set_database | latin1 |
| character_set_results | eucjpms |
| character_set_server | latin1 |
| character_set_system | utf8 |
+--------------------------+---------+
6 rows in set (0.00 sec)
mysql> SELECT parametercharset('漢字');
+----------------------------------------------------+
| parametercharset('漢字') |
+----------------------------------------------------+
| 漢字:B4C1BBFA:eucjpms |
+----------------------------------------------------+
1 row in set (0.01 sec)
mysql>
この場合は、正常に動いているように見える。
これは当然で、eucjpms → binary → eucjpms という変換が行なわれているからである。binaryとその他のキャラクタセットとの間の変換は、実は何も行なわないので、 データそのものは無変更で渡され、キャラクタセットの指定が変更されるに過ぎない。
パラメータのキャラクタセットを binaryに
いままでは、character_set_connection を binary にしたが、 これはcp932に戻して、パラメータのキャラクタセットを binaryにしてみよう。
mysql> SET @@character_set_connection=cp932;
Query OK, 0 rows affected (0.00 sec)
mysql> DROP FUNCTION parametercharset;
Query OK, 0 rows affected (0.11 sec)
mysql> DELIMITER //
mysql> CREATE FUNCTION parametercharset( s CHAR(20) CHARACTER SET binary )
-> RETURNS CHAR(50) CHARACTER SET binary
-> DETERMINISTIC
-> BEGIN
-> SET @PR1 = s;
-> SET @STR = CONCAT( s, ':', HEX(s), ':', CHARSET(s) );
-> SET @CSR = CHARSET(@STR);
-> RETURN @STR;
-> END//
Query OK, 0 rows affected (0.01 sec)
mysql> DELIMITER ;
mysql>
BEGIN〜ENDの中で、パラメータで渡された文字列そのものを@PR1に保存する ように変更し、他の変数への保存は少くした。
さて、これを実行するとどうなるだろうか。
mysql> SELECT parametercharset('漢字');
+----------------------------------------------------+
| parametercharset('漢字') |
+----------------------------------------------------+
| Š??š |
+----------------------------------------------------+
1 row in set, 1 warning (0.06 sec)
mysql>
変な表示になってしまった。ファンクションが受け取ったパラメータは @PR1にセーブしておいたので、それを調べてみよう。
mysql> SELECT @PR1; +----------------------+ | @PR1 | +----------------------+ | Š??š | +----------------------+ 1 row in set (0.00 sec) mysql>
文字化けしてしまったようだ。もっと詳しく、16進数にして見てみよう。
mysql> SELECT HEX(@PR1); +------------------------------------------+ | HEX(@PR1) | +------------------------------------------+ | 8ABF8E9A00000000000000000000000000000000 | +------------------------------------------+ 1 row in set (0.00 sec) mysql>
'漢字'という文字列が、ちゃんとcp932に変換され、後は00になって、 全体でバイトになっているようだ。 これは、パラメータに s CHAR(20) CHARACTER SET binary と 固定長のbinary型文字列で、サイズが20としたからである。
表示がうまく行かないのは、クライアントが受け取る場合の キャラクタセットを示すcharacter_set_resultsの値が 今はeucjpmsになっているのだが、実際に返された文字列のキャラクタセットが 表面上はbinaryで、その実cp932になっているからである。
パラメータのキャラクタセットをわざわざbinaryにすることは少ないと思われるので、 このやり方のテストは止めて、次回は普通の情况に近いテストを行なおうと思う。
たとえば、サーバ側、つまりファンクションの方がutf8で、 クライアントが cp932 とかという組み合わせである。
戻る：character_set_connectionを変えたときのファンクションパラメーは
フィードバック：
There is no comment.