UPDATE時にSETしたい日本語文字列が文字化けし、失敗する。こんにちはゲストさん。>>解決済みの質問UPDATE時にSETしたい日本語文字列が文字化けし、失敗する。UPDATE時にSETしたい日本語文字列が文字化けし、失敗する。POSTした時点では正しく表示されているのですが、(Printで確認)UPDATEを実行しますと、日本語文字列が化けまして正常に実行できません。他の箇所でも同様の、ユーザー入力の日本語文字列によるUPDATEを実施しており、そちらは上手く言っています。そちらとの違いは可変変数を使用しているか否かといった程度で、それが原因とは少々考えにくいです。仮に原因であったとしても解決法が私の技量・知識では見つけることが困難です。まる1日悩んでいるのですが解決できないのでご教授いただきたく思います。文字コードに関しては、MYSQLテーブル・項目はutf8_general_ci,ソースはphpも、POST元のhtmlもUTF-8に統一しております。ソースは下記のようなものを書いております。die("データベースの選択失敗。※の行の、日本語文字列を省くと正常にUPDATEできる。die("MySQL切断に失敗しました。05:22:21通報するQNo.5767722wendy0303すぐに回答ほしいです質問者が選んだベストアンサー>#5ちょっと、話が逸れるけど。`(バッククォート)は、MySQL限定でオブジェクト名(テーブル名、フィールド名等)が予約語と重なる際や、特殊文字を使用する場合などに用いられる、エスケープ文字のようなもの。オブジェクト名すべてに用いることは別に問題はないです。言え、MySQL限定というのがクセモノで、他のDBではまた別のエスケープ文字が使われるわけで。『すべてのオブジェクトをエスケープしましょう』というルールは、たとえば、PEAR::MDB2などの汎用インターフェイスの、『DBが変わった場合でもソースコードの修正個所は最小限に抑えられるように作る』というのと真逆のルールとも言えます。DBが変わった場合、DB固有の書き方に改めなければならない個所は出てきますが、すべてのSQLを書きかえる必要があるっていうよりは格段に少なくなるでしょう。仕事の現場では、『エスケープしなければならないオブジェクト名は付けてはいけない』というルールが一般的ですね。(と言うよりも、当たり前すぎてわざわざそんな事明文ルール化せずに、やってしまった奴がこっぴどく怒られるだけだと思いますが。)※逆にテーブル名は[T_],フィールド名は[F_]を頭に付けることをルール化して、上記を満たす場合もあります。そのうえで、エスケープはしません。仕事の現場で一般的にはって話なだけで、`(バッククォート)を付けるのが間違いと言うわけではないですが、趣味で個人でって人を含めても、かなりの少数派だとは言えます。ちなみに、`(バッククォート)を入力するには、キーボードではShift+@です。皆様の回答、ありがとうございます。本当にありがとうございます。皆様お世話になっております。機能自体も期待動作を果たす事が出来ました。文字列の形式と、クエリ文字列の記述の仕方に問題があったように思えます。変更(2.で表示されているシングルクォートもそのまま)と、修正する事で解決できました。phpMyAdminで表示されるSQL文は、テーブル名や項目名を全てシングルクォートで囲っています。これまでの開発で余り目にしなかったので、なんとなく気持ち悪くて消してしまっていたのです。今回のように、残さないと上手くいかない時もあります。ここら辺の理解は、今後理解を深めていくか、BellBellさんが申されているように使わなくても問題が起きないように、ネーミングを設計段階から徹底していく等の習慣を心がけたいと思います。13:13:34お礼yambejpさま、回答ありがとうございます。お礼が遅くなり申し訳ありません。詳細・経緯はベストアンサーとしました、BellBell様の回答にレスさせて頂きましたおかげさまで解決致しまして、現在実装できています。解決の手がかりとなったのはyambejpさまの指摘に有りましたシングルクォートでした。ありがとうございました。(0)通報するANo.4BellBell気になることで、原因として考えられなくもないのは、mysql_real_escape_string等を利用して、特殊文字をエスケープしていない事ですね。Shift-JIS環境で\マークをエスケープして文字化けを防ぐ事でも知られていますが、'をエスケープしてSQLインジェクションを防ぐことにも使用されます。2バイト文字列を1バイトに分解した場合に、'が含まれる可能性があればそのせいでクエリーが動作しない事も防ぐ事になります。※2バイト文字中に'が含まれる問題、というのは寡聞にして聞いたことがありませんので、文字コードの関係上発生しないのかも知れません。あと、直接問題とは関係ない事で気になる点がループの中でDBへの接続、切断を繰り返していること。通常は、DBへの接続、および切断はループ外で一度ずつ行い、ループ内では確立された接続に対しての操作を行う事が普通です。※無駄にDBへの接続、切断を繰り返すことで接続できないエラーが発生する可能性を高めているだけ。10回ループ中の、3回まで成功して途中で失敗するなどという可能性もあり、内容によっては致命的なシステムトラブルの可能性が。言えば、無駄に実行時に時間の掛かる処理(DB接続)を繰り返し行っているだけという見方もできます。die("MySQL切断に失敗しました。");一般にmysql_closeはエラーチェックしません。仮に切断に失敗したとしても、PHP終了時にはDB接続は解放されるため。※人によっては、DB接続の終了は自動解放に任せてmysql_closeそのものを呼び出さない事も多々あります。ちなみに、私がどうしてもクエリーの間違いを見つけられない場合クエリー発行直前にprintなどでクエリーを表示して、そのクエリーに失敗した場合は、そのSQLをコピペでPHPMyAdminなどから実行してみるそのエラーメッセージを元に、クエリーの間違いを探す。間違いが見つかれば、その情報を元にソースコードを見直しという手順を取る事があります。重要な指摘、参考になっております。現在問題は解決しまして、全体のコードを整えている所です。余計な処理をしていないか、見直し、すっきりした物にしようとしている所です。ありがとうございました。接続で使われている文字コードセットが期待するものでない場合、文字化けしてしまいます。バージョンに依存しますが、次の関数を利用して文字コードセットを指定することが出来ます。利用できるのであれば、切り替えたほうがよいと思います。現在の接続の文字コードセットを確認できますので、より正確な情報が得られるでしょう。http://jp.php.net/manual/ja/mysqli.character-set-name.phpまた、クエリを準備する場合、適切なエスケープを施すことが大事です。これを行うためには、接続の文字コードセットが適切な手順で指定されることが必要となります。利用してはいけません。外部からのデータを処理する方法や、データベースとの接続方法など、もう少し吟味すべき箇所があると思います。慎重な作業をされますことを願っております。11:31:53お礼samchayさま、回答ありがとうございます。お礼が遅くなり申し訳ありません。詳細・経緯はベストアンサーとしました、BellBell様の回答にレスさせて頂きましたおかげさまで解決致しまして、現在実装できています。解決の手がかりとなったのはクエリのくくり(クォート等)でした。指摘頂きましたとおり、注意深く吟味する事で解決が出来た事と実感しております。ありがとうございました。(0)通報するANo.2noname#111181UPDATEクエリを投げる前に下記を実行してみてください。10:34:47お礼i80286さま、お世話になっております。お礼が遅れて申し訳ありません。Bellbell様の回答も書かせて頂きましたが直接の原因はクエリ文のクォート、ダブルクォートの括りでした。それ以前は文字化け=文字コードが原因というタカを括っていた為、i80286様が指摘してくださった、UTF-8をはっきりと指示することで「文字コードが原因ではない」と、原因を断定して絞っていく事が出来ました。現在解決しまして、実装に至っております。ありがとうございました。さんありがとうございます。シングルくくりを初めとして、ダブルくくり、.の有無、.$等など...いろいろ試しましたが上手く行かないようです。";で、指定したクエリを実行して、エラー内容が、クエリの送信に失敗しました。「打合せ」だったUSAGEの中身が文字化けしています。(0)通報する登録日----年--月--日ありがとうポイント-ptお礼率-%ベストアンサー率-%お気に入りユーザーブロックユーザーあなたにオススメの質問phpでmysqlのデータがupdateできません。