文字コードの多様化とインターネットやクライアント-サーバーなどの分散環境の普及によって,文字化けトラブルの頻度が飛躍的に拡大した。特に Webシステムでは,WebブラウザとWebサーバー,プログラム(スクリプト)言語,そしてデータベースと文字化けが発生する要因が数多く存在する。 Webサーバー側の文字化けは,他のコラムにお任せすることとして,今回はMySQLの文字化けに関して解説する。

文字化けの仕組み

 文字化けは開発者にとって悩みの種である。しかし,文字化けの仕組みを少しでも知っていれば,意外と簡単に解決できるものだ。このコラムで,ぜひその知識を学んでほしい。

MySQL 4.1の変更点

 さて,MySQLにおいては,バージョン4.1のリリースを境に文字化けが起きることが非常に多くなった。では,バージョン4.1は,それ以前のバージョンと何が変わったのだろうか。そこに文字化けを解決するヒントがある。

表1●MySQL4.1の主な変更点

  内容 文字化けとの関連
新機能 サブクエリーのサポート  
Unicode (utf8 および ucs2)サポート
文字コードの自動変換機能の追加
変更点 カラム,テーブル,およびデータベースごとにキャラクタセットを定義
カラム(フィールド)の定義がバイト単位から文字単位に変更  
timestamp 型の表示フォーマットが変更  
パスワードの保存形式が変更  

 上記の中で,文字コードに関係する項目が3つある。これらを順番に解説する。

文字コードの増加(Unicodeのサポート)

 MySQL 4.0では,2種類の日本語文字コードしかサポートしていなかった。しかし,MySQL 4.1からUnicodeが追加され,大きく分類すると3種類の文字コードが使用可能になった。

表2●MySQLのサポートする日本語文字コード

    シフトJIS EUC-JP Unicode
4.0 sjis ujis  
4.1 sjis / cp932 ujis utf8/ ucs2
5.0 sjis / cp932 ujis /eucjpms utf8/ ucs2

 つまり,MySQL4.0では,2種類の文字コードしかないので,文字化けが発生すれば,もう一方の文字コードで試せばよかった。しかし,MySQL5.0では,6種類の文字コードがあるため,文字化けが発生する機会が増えてしまった。

文字コードの定義

 MySQL 4.0では,サーバー全体で文字コードの定義を行った。しかし,MySQL 4.1では,カラム(フィールド),テーブル,データベース毎に文字コードを設定可能になった。

 その関連として,カラムの定義で文字列型に設定する場合,char(X)にて指定する数値がバイト数ではなく文字数に変更されたのだ。そのため,char(10)は,文字コードによって10バイト,20バイト,30バイトと物理的なバイト数が異なるようになった。

この先は会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら