PHPの文字化けについて教えて下さい
created: 2009-06-26 10:06 | modified: 2009-07-03 11:24 | reply: 5
[4313] PHPの文字化けについて教えて下さい
user: tsubasa | created: 2009-06-26 10:06
こんにちわ。
いつも拝見させて頂いております。
PHPの文字化けに悩んでおります。
現在はファイル保存＆出力タグ＆php.iniをShift-JISに統一しておりますが各所に『\』が出たりして文字化けしてしまいます。
解消方法をご教示頂けますでしょうか？
また本来はEUC-JPかUTF-8を使用したいのですがSQL ServerをDBとしているのでShift-JISの方がいいというサイトも見ました。
SQL Server使用の際はShift-JISの方がいいのでしょうか？
知識不足で申し訳ありませんがよろしくお願い致します。
いつも拝見させて頂いております。
PHPの文字化けに悩んでおります。
現在はファイル保存＆出力タグ＆php.iniをShift-JISに統一しておりますが各所に『\』が出たりして文字化けしてしまいます。
解消方法をご教示頂けますでしょうか？
また本来はEUC-JPかUTF-8を使用したいのですがSQL ServerをDBとしているのでShift-JISの方がいいというサイトも見ました。
SQL Server使用の際はShift-JISの方がいいのでしょうか？
知識不足で申し訳ありませんがよろしくお願い致します。
[4314] 文字化け対策の心がけ他
user: ゆうじ | created: 2009-06-27 02:26
こんばんわ。
「\」が出るってことは、magic_quotes_gpc は On ですか。
これが On だと「\」の文字が「\\」のようにエスケープされます。
ややこしいことに、Shift_JIS の文字コードには
2バイト目に「\（\x5C）」を含む文字が存在するので
magic_quote_gpc が On だと、
これらの直後に余分な「\」が付け加えられます。
「ソ（\x835C）」「表（\x955C）」なんかがそうです。
文字列処理を行うときには
エスケープしたままでは不都合ばかりなので
必ずエスケープを排除してからというのが実際です。
また PHP6 では magic_quote_gpc 設定そのものがなくなる見込みです。
なので magic_quote_gpc は Off で運用するよう考えた方がいいです。
そのうえで、必要な個所で最低限のエスケープ処理を行ったほうが
はるかにわかりやすく、Shift_JISのような副作用を招かずに済みます。
「\（\x5C）」の件は、Shift_JIS の文字コードの問題なので
PHPに限らず他の言語やアプリケーションでも副作用がありえます。
考えられてるように EUC や UTF-8 で統一する方向をおすすめします。
この他に文字化けの原因があるとすれば、
文字エンコーディングの誤検出だろうと推測できますが
誤検出個所や文字列が特定できないと対処もできません。
先ずは各ポイントで、想定した通りの文字エンコーディングか
mb_detect_encoding と bin2hex あたりを使って
確かめてみるしかありませんね。
SQL Server は使ったことが無くまったくわかりません。
こちらも知識不足ですみません。
おまけで、私の文字化け防止５か条です。
１．可能な限り、エスケープを含まない生データを取り扱う。
２．可能な限り、文字エンコーディングを統一する。
３．可能な限り、文字エンコーディング変換は行わない。
４．$_GET $_POST $_COOKIE の値は必ず文字エンコーディングを検出し
必要があればPHPの内部エンコーディングに変換する。
５．DBやファイルなど外部への入出力時は、
必要があれば文字エンコーディング変換を行い
あわせてそれぞれの形式にあったエスケープ処理を行う。
「\」が出るってことは、magic_quotes_gpc は On ですか。
これが On だと「\」の文字が「\\」のようにエスケープされます。
ややこしいことに、Shift_JIS の文字コードには
2バイト目に「\（\x5C）」を含む文字が存在するので
magic_quote_gpc が On だと、
これらの直後に余分な「\」が付け加えられます。
「ソ（\x835C）」「表（\x955C）」なんかがそうです。
文字列処理を行うときには
エスケープしたままでは不都合ばかりなので
必ずエスケープを排除してからというのが実際です。
また PHP6 では magic_quote_gpc 設定そのものがなくなる見込みです。
なので magic_quote_gpc は Off で運用するよう考えた方がいいです。
そのうえで、必要な個所で最低限のエスケープ処理を行ったほうが
はるかにわかりやすく、Shift_JISのような副作用を招かずに済みます。
「\（\x5C）」の件は、Shift_JIS の文字コードの問題なので
PHPに限らず他の言語やアプリケーションでも副作用がありえます。
考えられてるように EUC や UTF-8 で統一する方向をおすすめします。
この他に文字化けの原因があるとすれば、
文字エンコーディングの誤検出だろうと推測できますが
誤検出個所や文字列が特定できないと対処もできません。
先ずは各ポイントで、想定した通りの文字エンコーディングか
mb_detect_encoding と bin2hex あたりを使って
確かめてみるしかありませんね。
SQL Server は使ったことが無くまったくわかりません。
こちらも知識不足ですみません。
おまけで、私の文字化け防止５か条です。
１．可能な限り、エスケープを含まない生データを取り扱う。
２．可能な限り、文字エンコーディングを統一する。
３．可能な限り、文字エンコーディング変換は行わない。
４．$_GET $_POST $_COOKIE の値は必ず文字エンコーディングを検出し
必要があればPHPの内部エンコーディングに変換する。
５．DBやファイルなど外部への入出力時は、
必要があれば文字エンコーディング変換を行い
あわせてそれぞれの形式にあったエスケープ処理を行う。
[4315] Re:文字化け対策の心がけ他
user: tsubasa | created: 2009-06-29 15:17
ゆうじさん
こんにちわ。
お返事遅くなり申し訳ありません。
magic_quotes_gpcの設定を確認してみたいと思います。
やはりEUC や UTF-8 で統一するほうがいいのですね。
なんかすっきりしました！
教えて頂いた文字化け防止５か条を確認しつつ
再度、挑戦してみたいと思います。
ありがとうございます。
SQL Serverについては思い出すことなどありましたら
またご教示下さい。
こんにちわ。
お返事遅くなり申し訳ありません。
magic_quotes_gpcの設定を確認してみたいと思います。
やはりEUC や UTF-8 で統一するほうがいいのですね。
なんかすっきりしました！
教えて頂いた文字化け防止５か条を確認しつつ
再度、挑戦してみたいと思います。
ありがとうございます。
SQL Serverについては思い出すことなどありましたら
またご教示下さい。
[4316] UTF-8の変更によるエラーが解消できません。。。
user: tsubasa | created: 2009-07-02 10:41
ゆうじさんのアドバイスを頂いてUTF-8に環境を変更してみましたがプログラムを実行してみると下記の２つのエラーが発生しました。
エラー内容①：odbc_exec()[function.odbc-exec]:SQL error:[Microsoft][ODBC SQL Server Driver][SQL Server]～文字化けした$sqlの表記～SQL state 37000 in SQLExecDirect in C://.......
エラー内容②：odbc_fetch_row();supplied argument is not a valid ODBC result resource in C://....
ちなみにソースの中にある①の部分では文字化けしていませんでした。
色々、調べて[mb_convert_encoding($sql,'SJIS','UTF-8')]を各所に入れてみましたが結果は同じでした。
是非、解決方法をご教示下さい。
よろしくお願い致します！
******************** ソース ********************
if(! $con= odbc_connect("web","web","web")) {
exit("DBに接続できませんでした。");
}
$sql = "select 件数、日付 from group by 担当";
$print $sql;←①
$r = odbc_exec($con,$sql);
while(odbc_fetch_row($r)){
$clm1 = odbc_result($r,"件数");
$clm2 = odbc_result($r,"日付");
}
odbc_close($con);
エラー内容①：odbc_exec()[function.odbc-exec]:SQL error:[Microsoft][ODBC SQL Server Driver][SQL Server]～文字化けした$sqlの表記～SQL state 37000 in SQLExecDirect in C://.......
エラー内容②：odbc_fetch_row();supplied argument is not a valid ODBC result resource in C://....
ちなみにソースの中にある①の部分では文字化けしていませんでした。
色々、調べて[mb_convert_encoding($sql,'SJIS','UTF-8')]を各所に入れてみましたが結果は同じでした。
是非、解決方法をご教示下さい。
よろしくお願い致します！
******************** ソース ********************
if(! $con= odbc_connect("web","web","web")) {
exit("DBに接続できませんでした。");
}
$sql = "select 件数、日付 from group by 担当";
$print $sql;←①
$r = odbc_exec($con,$sql);
while(odbc_fetch_row($r)){
$clm1 = odbc_result($r,"件数");
$clm2 = odbc_result($r,"日付");
}
odbc_close($con);
[4317] SQL Server のフィールド名にUTF-8
user: ゆうじ | created: 2009-07-03 00:06
エラー内容（２）は、odbc_exec() で正しい結果リソースが
得られなかったために出てる２次的なエラーなので、
問題は（１）に絞れます。
（１）は「SQL error」なので $sql に問題ありってことです。
PHPのソースが UTF-8なら、当然 $sql に含まれてる
マルチバイトのフィールド名も UTF-8 ってことなので
UTF-8のフィールド名が受け付けらず
SQL error になってると推測します。
SQL Server は使ってないのでわかりませんが
そもそものフィールド名に UTF-8 は可能なのですか。
または SQL Server 側で設定が必要なのではありませんか。
以下、本件の解決策ではなく個人的見解なので参考まで。
フィールド名にマルチバイトが使えるにしても
フィールド名にマルチバイトを用いるメリットが
「考えずに読める」こと以外に思い浮かびません。
特に理由があるなら話は別ですが
フィールド名は _a-zA-Z0-9 だけで構成した方が
データを保守する上で圧倒的に有利だと思っています。
得られなかったために出てる２次的なエラーなので、
問題は（１）に絞れます。
（１）は「SQL error」なので $sql に問題ありってことです。
PHPのソースが UTF-8なら、当然 $sql に含まれてる
マルチバイトのフィールド名も UTF-8 ってことなので
UTF-8のフィールド名が受け付けらず
SQL error になってると推測します。
SQL Server は使ってないのでわかりませんが
そもそものフィールド名に UTF-8 は可能なのですか。
または SQL Server 側で設定が必要なのではありませんか。
以下、本件の解決策ではなく個人的見解なので参考まで。
フィールド名にマルチバイトが使えるにしても
フィールド名にマルチバイトを用いるメリットが
「考えずに読める」こと以外に思い浮かびません。
特に理由があるなら話は別ですが
フィールド名は _a-zA-Z0-9 だけで構成した方が
データを保守する上で圧倒的に有利だと思っています。
[4318] Re: SQL Server のフィールド名にUTF-8
user: tsubasa | created: 2009-07-03 11:24
ゆうじさん
ありがとうございます。
１度サーバー側の設定を調べてみます。
それでわからないようであればフィールド名を英数にして挑戦してみます。
大変参考になりました。
ありがとうございました！
ありがとうございます。
１度サーバー側の設定を調べてみます。
それでわからないようであればフィールド名を英数にして挑戦してみます。
大変参考になりました。
ありがとうございました！
