2007年1月24日
MySQLとACCESSと文字コード
ACCESSのデータをMySQLでいきなり使おうと思っても文字化けしてしまうことが多い。やはり設定が必要なのだ。Windowsの日本語の文字コードといばShift-JISなんだが、正式にはWindows-31Jと呼ばれていて、若干違うところがあるらしい。このWindows-31Jと互換性があるように作られたのがMySQLのcp932と呼ばれる文字コードなのだ。
MySQL4.0までは、サーバ側、クライアント側という設定が出来なかったので、文字化け問題は現在ほど複雑ではなかったみたいだ。要は全部同じ文字コードにセットしておけば、問題が軽減すると思うので、ACCESSからデータを取り込む場合は、cp932という文字コードを使うのが無難だろう。
文字コードの設定を確認するには、
mysql> show variables like 'char%';
又は
mysql> status;
サーバー文字コード指定
default-character-set=cp932
または、設定ウィザードを使う。
クライアント文字コード指定
mysql> SET NAMES cp932;
Shift_JIS / SJIS最も普及していて、それでいて方言のたくさんあるコードです。
Windows上のShift_JISは、Windows-31J とも呼ばれています。Shift_JISは、MSではない正式なJIS X 0201やJIS X 0208の文字セットのみを使用したShift_JISの規格を示す場合に使います。Windows-31Jはその他変な文字がいろいろ加わっていたり Unicodeとの対応が数文字違ったりします。Windows上では区別できませんが、Javaでは別々に扱えます。今後は区別してください。ISO-2022-JPと違い、JIS X 0208の何年版に対応しているのかは、場合によって異なるかもしれません。JIS X 0208:1997からはShift_JISが明記されていますが、付属書であって正確にはJISの規格ではありません。
0x00-0x7fはASCIIと同じではなく、JIS X 0201とかローマ字と呼ばれていたりする配置。\記号(／か￥)など~(￣か～?)がASCIIから変わっている。
で、JIS X 0208の文字はそれ以前に使われていた半角カナの位置とかぶらないように空いた場所を埋めるように配置されている。
漢字はJIS X 0208のコードを基にして、0x80 - 0x9F、0xE0-0xEF (Windows-31Jでは0xFCまで) からはじまる2バイトに納まるように変換される。2バイト目は0x40 - 0x7E、0x80-0xFC だったかな?
WIndows-31J / MS_Kanji / CP932 / MS932 / Cp942 / csWindows31JShift_JISでははしご高と口高などが同じ文字コードなのですが、Windows-31Jではこれを区別しています。その他、随所に違いがみられます。別名、CP932 や MS932ともいいますが、これはUnicodeとの対応を示す変換表の名前? さらにCp932とMS932は少し違う? Windows-31J がIETFだかどこかに登録されている正式名称です。全角ハイフン「－」や「～」などのコードをUNICODEに変換する場合、Shift_JISと違うので、混乱します。このページは、たぶんWindows-31Jの文字コードになってしまっています。IEなどではWindows-31Jという名前では識別できず、Shift_JISやcsWindows31Jという名前で認識されます。
文字的には、JIS X 0201、JIS X 0208:1990?(年不明)の他に、13区にNEC特殊文字、89区～92区にNEC選定IBM拡張文字、115～119区にIBM拡張文字が割り当てられている。
それぞれ重複するものがあるため、JIS 0208、NEC特殊文字、IBM拡張漢字、NEC選定IBM拡張漢字の順で優先される? JISの区点では115区などは存在しないため、CP50221 (ISO-2022-JP系)など区点ベースの文字コードに変換する場合はIBM拡張漢字はNEC選定IBM拡張文字の位置に変換して対応されている。
機種依存文字だけUnicodeとの変換表を追加すればよかっただけのものを、MSがShift_JISにある文字までJISと違うUnicode上のコードに割り当てたのが混乱の原因。
NEC外字領域でIBM外字領域にもある文字は、IBM文字推奨、NEC文字は使わないのがよいようです。
- by editor
- at 14:06
編集長のおすすめの一冊！2010
comments