スレッド表示 | フラット表示〕 全トピック 920 件中 23 番目 次≫ ≪前

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の方がいいのでしょうか?

知識不足で申し訳ありませんがよろしくお願い致します。
reply: 4314 4316 返信 編集 削除

[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 は使ったことが無くまったくわかりません。
こちらも知識不足ですみません。


おまけで、私の文字化け防止5か条です。

1.可能な限り、エスケープを含まない生データを取り扱う。

2.可能な限り、文字エンコーディングを統一する。

3.可能な限り、文字エンコーディング変換は行わない。

4.$_GET $_POST $_COOKIE の値は必ず文字エンコーディングを検出し
  必要があればPHPの内部エンコーディングに変換する。

5.DBやファイルなど外部への入出力時は、
  必要があれば文字エンコーディング変換を行い
  あわせてそれぞれの形式にあったエスケープ処理を行う。
Parent: 4313  reply: 4315 返信 編集 削除

[4315] Re:文字化け対策の心がけ他

user: tsubasa | created: 2009-06-29 15:17
ゆうじさん

こんにちわ。
お返事遅くなり申し訳ありません。

magic_quotes_gpcの設定を確認してみたいと思います。

やはりEUC や UTF-8 で統一するほうがいいのですね。

なんかすっきりしました!

教えて頂いた文字化け防止5か条を確認しつつ
再度、挑戦してみたいと思います。

ありがとうございます。

SQL Serverについては思い出すことなどありましたら
またご教示下さい。
Parent: 4314  返信 編集 削除

[4316] UTF-8の変更によるエラーが解消できません。。。

user: tsubasa | created: 2009-07-02 10:41
ゆうじさんのアドバイスを頂いてUTF-8に環境を変更してみましたがプログラムを実行してみると下記の2つのエラーが発生しました。

エラー内容①: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);
Parent: 4313  reply: 4317 返信 編集 削除

[4317] SQL Server のフィールド名にUTF-8

user: ゆうじ | created: 2009-07-03 00:06
エラー内容(2)は、odbc_exec() で正しい結果リソースが
得られなかったために出てる2次的なエラーなので、
問題は(1)に絞れます。
(1)は「SQL error」なので $sql に問題ありってことです。

PHPのソースが UTF-8なら、当然 $sql に含まれてる
マルチバイトのフィールド名も UTF-8 ってことなので
UTF-8のフィールド名が受け付けらず
SQL error になってると推測します。

SQL Server は使ってないのでわかりませんが
そもそものフィールド名に UTF-8 は可能なのですか。
または SQL Server 側で設定が必要なのではありませんか。


以下、本件の解決策ではなく個人的見解なので参考まで。
フィールド名にマルチバイトが使えるにしても
フィールド名にマルチバイトを用いるメリットが
「考えずに読める」こと以外に思い浮かびません。
特に理由があるなら話は別ですが
フィールド名は _a-zA-Z0-9 だけで構成した方が
データを保守する上で圧倒的に有利だと思っています。
Parent: 4316  reply: 4318 返信 編集 削除

[4318] Re: SQL Server のフィールド名にUTF-8

user: tsubasa | created: 2009-07-03 11:24
ゆうじさん

ありがとうございます。

1度サーバー側の設定を調べてみます。

それでわからないようであればフィールド名を英数にして挑戦してみます。

大変参考になりました。

ありがとうございました!
Parent: 4317  返信 編集 削除
スレッド表示 | フラット表示〕 全トピック 920 件中 23 番目 次≫ ≪前
ページの一番上へ
Googleグックマークに登録 Yahooグックマークに登録 livedoorクリップに登録 @niftyクリップに登録 はてなブックマークに登録 deliciousに登録 Buzzurlに登録 FC2ブックマークに登録
最近更新された掲示板トピックス
管理人Blog
Yahoo Search

最近更新したNote
PHPマニュアル
今日のブックマーク
PHPマニュアル関数検索
関数名を入力し検索ボタンをクリック↑