Linux(CentOS)、Apache、Oracle(SJIS)、PHPで webシステムを作ることになったのですが、
oracle + PHP の開発経験がないので
PHP側の文字コードが SJIS、UTF-8 どちらが良いか分からず悩んでいます。
一度
・PHPの文字コードをSJIS、php_info()のenvironment→NLS_LANG=Japanese_Japan.JA16SJIS
・PHPの文字コードをUTF-8、php_info()のenvironment→NLS_LANG=Japanese_Japan.AL32UTF8
で簡単なプログラムを組んで SELECT、INSERT、UPDATEは試してみたところ、
どちらも文字化けせず問題なさそうでした。
(DB接続はOCI8関数を使いました)
自分としては、PHP側はSJISを使わずUTF-8を使いたいのですが
SJISを使ってoracleと文字コードを統一した方が文字化けなどでそこまで詰まらなそうなので
SJISの方が良いのかもしれないのでは?と思っています。
ですので、PHP側がどちらの文字コードがオススメか、分かる方がいましたら教えてください。
その理由もお聞かせいただけると嬉しいです。
SJISを使ってoracleと文字コードを統一した方が文字化けなどでそこまで詰まらなそうなので
SJISの方が良いのかもしれないのでは?と思っています。
ある意味、感覚としては正しいと思います。
ただし、いくつかの例外を除けば。
人はそのいくつかの例外のことを、バッドノウハウと呼んだりします。
http://oku.edu.mie-u.ac.jp/~okumura/php/sjis.html
まず、有名なのは 2byte目が 0x5c の2byte文字の問題。
文字リテラル内で、特殊な文字をエスケープする¥と、2byte文字の 2byte目の 0x5c を同等に扱ってしまいます。
古くは、C言語や Perl のときから、お馴染みの問題です。
PHP では、さらにこんな問題も。
この文字化けは、PHPのMagic Quote GPC(Get Post Cookie)という設定とShift-JISの文字コードの組み合わせが原因になって起こります。
http://www.syon.co.jp/syontech/tech003.html
じゃあ、0x5c だけを気を付けていれば良いのか、というと PHP は 0x5d にも気を使う必要があるそうです。
配列のキーにSJISを使っていて、PHPがUTF-8である場合、特定の文字でキー文字列がブチ切られるのです。
http://lab.flama.co.jp/archives/355
おっと、こちらは PHP が UTF-8 ですね。
ページが SJIS で、そこからのリクエストを UTF-8 な PHP が受ける、というちょっと特殊な感じですが。
どちらにしろ、2byte文字の扱いが甘い言語を使う場合には、こういった事柄について正しい知識と、それらが引き起こす問題から逃げない姿勢が、一番大事だと思います。
要件がよく分からないのですが、Web側(PHP側)からOracleへのデータ登録が発生するのであれば、Web側(PHP側)もSJISにすることをお勧めします。
たとえばHTML5に準拠したサイトを作るのであればUTF-8にすることが望ましいのですが、UTF-8で入力された文字の一部について、対応するSJISコードがないため、Oracleに登録する際に文字化けするためです。
回答ありがとうございます。
商品の名前や在庫データを修正するといったシステムなので、データ登録は発生します。
SJISに対応しない文字がここまであるとは知りませんでした。
対応しない文字は弾くなど、処理が増えることも考えないといけないのですね。
SJISを使ってoracleと文字コードを統一した方が文字化けなどでそこまで詰まらなそうなので
SJISの方が良いのかもしれないのでは?と思っています。
ある意味、感覚としては正しいと思います。
ただし、いくつかの例外を除けば。
人はそのいくつかの例外のことを、バッドノウハウと呼んだりします。
http://oku.edu.mie-u.ac.jp/~okumura/php/sjis.html
まず、有名なのは 2byte目が 0x5c の2byte文字の問題。
文字リテラル内で、特殊な文字をエスケープする¥と、2byte文字の 2byte目の 0x5c を同等に扱ってしまいます。
古くは、C言語や Perl のときから、お馴染みの問題です。
PHP では、さらにこんな問題も。
この文字化けは、PHPのMagic Quote GPC(Get Post Cookie)という設定とShift-JISの文字コードの組み合わせが原因になって起こります。
http://www.syon.co.jp/syontech/tech003.html
じゃあ、0x5c だけを気を付けていれば良いのか、というと PHP は 0x5d にも気を使う必要があるそうです。
配列のキーにSJISを使っていて、PHPがUTF-8である場合、特定の文字でキー文字列がブチ切られるのです。
http://lab.flama.co.jp/archives/355
おっと、こちらは PHP が UTF-8 ですね。
ページが SJIS で、そこからのリクエストを UTF-8 な PHP が受ける、というちょっと特殊な感じですが。
どちらにしろ、2byte文字の扱いが甘い言語を使う場合には、こういった事柄について正しい知識と、それらが引き起こす問題から逃げない姿勢が、一番大事だと思います。
回答ありがとうございます。
5C問題はSJISを避けたい理由の一つでした。
0x5dは知りませんでした。他にもあったのですね。
今まで「何となくは知っている」で来てしまったので、
文字コードについて再度勉強し、正しく理解したいと思います。
DB の文字コードが SJIS ってのが厳しいですよね。
ページの charset や、処理する php を UTF-8 にした場合、UTF-8 → SJIS で対応する文字が無い、というケースをどう処理するのかが、悩みの種です X-|
回答ありがとうございます。
2012/11/23 23:21:585C問題はSJISを避けたい理由の一つでした。
0x5dは知りませんでした。他にもあったのですね。
今まで「何となくは知っている」で来てしまったので、
文字コードについて再度勉強し、正しく理解したいと思います。
DB の文字コードが SJIS ってのが厳しいですよね。
2012/11/23 23:29:42ページの charset や、処理する php を UTF-8 にした場合、UTF-8 → SJIS で対応する文字が無い、というケースをどう処理するのかが、悩みの種です X-|