- ベストアンサー
MySQL5.1の文字列サイズは文字数ではない?
- MySQL 5.1の文字列型フィールドのサイズ指定は文字数ではないことに疑問があります。
- utf8の日本語を保存する際に3倍のサイズを要することに不便さを感じています。
- MySQL5.1のリファレンス記述と一致しないため、設定に誤りがあるのか疑問に思っています。
- みんなの回答 (4)
- 専門家の回答
質問者が選んだベストアンサー
>MySQL 5.1 でVARCHAR、CHAR などの字列型フィールドのサイズ指定は、 >文字数であると認識していたのですが、違うのでしょうか。 MySQL 4.1で仕様変更(unicodeの実装)があり、char(n)のnの意味が変わりました。 MySQL 4.0まではバイト数、MySQL 4.1以降は文字数です。 >あるいは、どこか設定を誤っているのでしょうか。 標準のインストール方法だと、latin1が仮定されるので、何箇所かの設定が必要になります。特に、この手のトラブルは、設定漏れといったケースが多いです。 >書き忘れておりました。 >show variables like '%char%' >show create table 表名 >共に全てutf8になっています。 >1.テーブル作成 ・・・ 問題なく成功。文字コードもutf8。 どこをどう見て、そう判断しているのかを知りたいのですよ。ですから、表示された結果を教えて欲しいのです。 表名、列名、あるいはデータなどで公開できない部分もあるでしょうが、第三者が判断するために必要な情報まで未提示では、設定誤りやバグ情報を調べたりするのが非効率的なのです。
その他の回答 (3)
- chukenkenkou
- ベストアンサー率43% (833/1926)
原因になかなか辿り着けないので、日本MySQLユーザ会のメーリングリストで質問してみてはいかがでしょうか? もちろん無料ですし、法人だけでなく個人会員も多数います。メンバーの使用環境などが多様で、MySQLの日本法人の方からアドバイスをもらえることもあります。
お礼
chukenkenkou 様 アドバイスありがとうございます。 現在、紹介頂いた日本MySQLユーザ会の過去ログを検索させて頂いております。 それでも見つからない場合は、お勧めに従い日本MySQLユーザ会のメーリングリストにて質問しようかと考えております。 その際は、マルチポストになるので、こちらは締めさせて頂くつもりです。 取り急ぎお礼まで。 以上、失礼いたします。
補足
問題解決しました。 ありがとうございます。 そしてごめんなさい。 >原因になかなか辿り着けないので たどり着けない理由は私からの情報提示ミスでした。 実行環境と状況確認環境が異なっていたため、嘘の情報をこちらに提示しておりました。 補足要求でご指摘頂いていたにも関わらず、まことに申し訳ございませんでした。 以下、解決経緯 その後、日本MySQLユーザ会の過去ログを検索しつつ、情報収集した結果、以下のブログ記事に辿り着きました。 http://blog.cheki.net/archives/332 実は、show variavles を実行環境のPerl経由でなく、WindowsのDOS窓から行っておりました。(これが今回の原因です) 実行環境であるPerl上で show variables を実行してみると、結果は以下の様になりました。 character_set_client latin1 character_set_connection latin1 character_set_database utf8 character_set_filesystem binary character_set_results latin1 character_set_server utf8 character_set_system utf8 よって、SET NAMES utf8 を実行してやることで問題解決いたしました。 show variables で得られる結果の意味を考えれば、当然の内容でした。 ご迷惑をお掛け致しました。 ありがとうございます。
- chukenkenkou
- ベストアンサー率43% (833/1926)
使用しているMySQLのバージョンは、具体的には何ですか? >書き忘れておりました。 >show variables like '%char%' >show create table 表名 >共に全てutf8になっています。 実際にどのような結果が得られているのか、提示できませんか?
お礼
chukenkenkou 様、たびたび補足要求、申し訳ございません。 [MySQLバージョン] 5.1.30 [状況と得られる結果] 1.テーブル作成 ・・・ 問題なく成功。文字コードもutf8。 実行SQL CREATE TABLE `test` (`column_A` VARCHAR(6)); 2.データ書き込み・・・失敗。Perl5.8.8のDBI経由。 IDEはEPIC Perl on Eclipse 3.3.2。 DBIバージョンは1.67。 実行SQL INSERT INTO `test`(`column_A`) VALUES ('ああああああ'); 実行結果=エラー内容 DBD::mysql::st execute failed: Data too long for column 'column_A' at row 1 at //localhost/public_html/cgi-bin/test.pl line 20. です。 ちなみに、データ書き込みを以下のSQLで実行すると、問題なく成功します。 実行SQL INSERT INTO `test`(`column_A`) VALUES ('ああ');
- chukenkenkou
- ベストアンサー率43% (833/1926)
データベース、テーブルの文字コードは、適切なものになっていますか? SQLを入力できる状態で、以下のshowコマンドを実行してみてください。 show variables like '%char%' show create table 表名
お礼
chukenkenkou 様、補足要求ありがとうございます。 書き忘れておりました。 show variables like '%char%' show create table 表名 共に全てutf8になっています。 書込みはPerlのDBI経由で、Perlのコードもutf8です。 以上、失礼いたします。
お礼
chukenkenkou 様、重ねて面倒をお掛けします。 >どこをどう見て、そう判断しているのかを知りたいのですよ。ですから、表示された結果を教えて欲しいのです。 以下、確認した内容と結果 show variables like '%char%'結果 character_set_client | utf8 | character_set_connection | utf8 | character_set_database | utf8 | character_set_filesystem | binary | character_set_results | utf8 | character_set_server | utf8 | character_set_system | utf8 | テーブル作成実行結果 CREATE TABLE `test`(`column_A` VARCHAR(6));を実行 Query OK, 0 rows affected (0.00 sec) show create table 表名 実行結果 | test | CREATE TABLE `test` ( `column_A` varchar(6) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8 | status実行結果 -------------- mysql Ver 14.12 Distrib 5.0.67, for Win32 (ia32) Connection id: 1220 Current database: sample Current user: root@localhost SSL: Not in use Using delimiter: ; Server version: 5.1.30-community MySQL Community Server (GPL) Protocol version: 10 Connection: localhost via TCP/IP Server characterset: utf8 Db characterset: utf8 Client characterset: utf8 Conn. characterset: utf8 TCP port: 3306 Uptime: 6 days 7 hours 8 min 9 sec Threads: 1 Questions: 711307 Slow queries: 8 Opens: 78 Flush tables: 1 Open tables: 0 Queries per second avg: 1.307 -------------- 確認したところは以上です。 これで事足りますでしょうか?