euc-jpのデータをutf-8で文字化けしないようにする方法 - PHPプロ！Q&A掲示板
があるのですが、現在は、utf-8にフォームがエンコードされ
ています。
そのeuc-jpだった時に保存されたデータを使用するときに、
文字化けしてしまいます。
データをutf-8で登録しなおせばよいのでしょうが、できればeuc-jp
で保存したままで、文字化けしないで表示させたいです。
方法はあるのでしょうか。ヒントをおしえていただけましたら幸いです。
この質問への意見の募集は締め切られ、ポイントは既に配分されました。
意見を投稿することはできますが、ポイントを受け取ることはできません。
ツリー一覧
A02-1-3-1-1signal
まず、文字化けの原因はシステムの文字コードとDBのA02-1-3-1-1-1soraiyasignal様
ご丁寧なご説明をありがとうございます。A02-1-3-1-1-1-1signal1. 必要なテーブルのレコードを mysqldump で取得する
A02-1-3-1-1-1-1-1soraiyasignal様
アドバイスをありがとうございます。
A02-1-3-1-1-1-1-2soraiyaSIGNALさま
データベースのeuc-jpで保存されたデー回答一覧
A01
answerer3Lvr4Qj9 [1月3日 22:45]
データはどこに保存されていますか？DBですとDBと接続する時のエンコーディングの指定とか、DB側の設定とか諸々絡んできそうです。その辺りの詳細を書いて頂けると、レスしやすいかもです。
単純にファイルに保存しているだけであれば、例えば、mb_convert_encoding()を使ってこんな感じでどうでしょうか。
- $str = ファイルから読み出す関数();
- $str2 = mb_convert_encoding($str, 'euc-jp', 'euc-jp');
- if ($str == $str2) {
- // EUC-JPとして処理
- } else {
- // UTF-8として処理
- }
ただ、こういうのって後々色々と厭な感じに引きずりそうな感じがありますので、やっぱりeuc-jpのデータをutf-8に直しておくか、或いはデータを格納するファイルなりディレクトリなり、DBであればテーブルなりを分離して混ざらないようにした上で、何らかのラッパークラスを用意しておくとかしておかないと数年後とかに厭な状態とか厭な気分になりそうな予感がしますので、充分お気を付け下さい。
A01-1
replyersoraiya [1月4日 17:50]
「フォームからPOSTされたデータがeuc-jpなりutf-8なりになっている、という理解で宜しいでしょうか？（恐らく、フォームを表示しているHTMLが以前はeuc-jpだったのがutf-8になった、という事？）」
ハイ、そういうことです。
初心者のため言葉が不自由でうまく説明できないのですが、ご理解いただき有難いです。
フォームからpostされたデータが以前のものはeuc-jpになっています。
データはDBにeuc-jpで格納されています。
もともと英語用に書かれていたスクリプトを日本語で使用できるようにeuc-jpにエンコードしていました。下記がその一例です。
ところが新しいphpスクリプトでは全てutf-8にエンコードされました。
その結果、euc-jpでDBに格納されている古いデータが文字化けを起すようになりました。できればデータをutf-8で入れ替えする作業を行わずに、文字化けしないで出てくるようにしたいのですがいかがでしょうか。
「DBであればテーブルなりを分離して混ざらないようにした上で、何らかのラッパークラスを用意しておくとかしておかないと...」と書いてくださいましたが、難しいことなのでしょうか。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
mb_language('Japanese');
mb_internal_encoding('EUC-JP');
#2007-04-14#
# 件名文字化け対策にSubjectEncode関数追加
function subjectMime ( $str )
{
return (mb_encode_mimeheader($str, 'ISO-2022-JP', 'B'));
}
function Jmime ( $str )
{
return (mb_encode_mimeheader(J2jis($str), 'ISO-2022-JP', 'B'));
}
function J2jis ( $str )
{
return(mb_convert_encoding($str,'JIS','EUC-JP'));
}
function errp ( $str )
{
global $jp_code;
print '<html>' . "\n" . '<head>' . "\n";
print '<meta http-equiv="Content-Type" content="text/html; charset=';
#2006-06-20#
# if ($jp_code == 'SJIS') {
# echo 'Shift_JIS';
# } else {
# echo $jp_code;
# }
if ($jp_code == 'SJIS' || $jp_code == 'SJIS-win') {
echo 'Shift_JIS';
} elseif ($jp_code == 'eucJP-win') {
echo 'EUC-JP';
} else {
echo $jp_code;
}
print '">' . "\n" . '<title>ERROR</title>' . "\n";
print '<style type="text/css">' . "\n";
print '<!--' . "\n";
print '.style2 {font-family: Geneva, Arial, Helvetica, san-serif}' . "\n";
print '.style3 {' . "\n";
print ' font-size: 14px;' . "\n";
print ' color: #000000;' . "\n";
print '}' . "\n";
print '-->' . "\n";
print '</style>' . "\n";
print '</head>' . "\n";
print '<body>' . "\n";
print '<br><br><center><font color="ff0000">' . $str . '</font></center><br>' . "\n";
print '</body>' . "\n" . '</html>';
}
$str = '';
foreach ($_POST as $key => $item) {
if ($key == 'aid') {
continue;
}
$str .= $item;
}
#2006-06-20#
#$jp_code = mb_detect_encoding($str,'EUC-JP, SJIS, JIS, UTF-8', 'ASCII');
$jp_code = mb_detect_encoding($str, 'EUC-JP, eucJP-win, SJIS, SJIS-win, JIS, UTF-8', 'ASCII');
if ($jp_code == 'ASCII') {
$jp_code = 'EUC-JP';
}
mb_http_output($jp_code);
ob_start("mb_output_handler");
#------- 2005/10/28 $fromname をEUC-JPに
#2006-06-20#
#if (($jp_code == 'SJIS') && (get_magic_quotes_gpc())) {
if (($jp_code == 'SJIS' || $jp_code == 'SJIS-win') && (get_magic_quotes_gpc())) {
$fromname = stripslashes($fromname);
}
if ($jp_code <> 'EUC-JP') {
$fromname = mb_convert_encoding($fromname, 'EUC-JP', $jp_code);
}
#---
A01-1-1
replyer3Lvr4Qj9 [1月4日 19:11]
となりますと、DBについて教えて欲しいところですが・・・その前に。
今回問題となっているスクリプトは、soraiya様が個人で使用しているアプリでしょうか？それとも商いとして、お客様が使用しているアプリでしょうか？
お客様が使用しているアプリであるならば、開発環境などで（今回の件であればスクリプトがUTF8に入れ替わった時）事前の動作確認などはしてらっしゃいますか？
あるいは現在、事前の動作確認をしている真っ最中で、そこで問題が起きているということでしょうか？
soraiya様の事情は量りかねますが、もし事前確認もせずに本番環境に入れてしまい、文字化けした時点で異常に気づいた、と言うのであれば、スクリプト云々以前にそうした作業プロセスも直した方が良いです。自分自身書いてて耳が痛くはありますが。
ともあれ、まずは使用しているDBとそのバージョンを教えて下さい。
あと気になりましたのは、データのUTF-8への入れ替えを避けたがっているように見えますがこれは何故でしょうか？データ量が多いからでしょうか？使用しているDBの制約でしょうか？
・・・とはいえ、教えて頂いても上手く返信できるか正直、自信がありません。DBに異なる文字コードのデータを入れてしまった場合どうなるかについては自分も経験がない為、上手い解決策が考えつかないと思います。
ですので、私ではなく、私以外の新たな親切な回答者の為にも、
・DBのバージョンやテーブルの文字コード
・PHPスクリプトがどのような順序でDBに接続しているか
・DBを操作する為にどのようなライブラリ(PEARのDB/MDBなり、ADODBなり、スクリプト独自なり）を利用しているのか
等教えて下さい。
「DBであればテーブルなりを分離して混ざらないようにした上で、何らかのラッパークラスを用意しておくとかしておかないと」
ですが、自分で書いておきながらですが・・・難しいです。
まず、そもそも事前動作確認をした時に問題を把握していないと、この対処は難しいと思います。さらにラッパーを用意するとなると、それだけ後々のメンテナンス性を犠牲にすることになります（ソースコードが読みづらくなるし、ドキュメントが残されていないとその意図を後の人が推測できないという意味で）。
ラッパー関数ならまだしも、ラッパークラスとなると、作る側も、後々メンテする側も幾ばくかのオブジェクト指向の知識が必要になってきます。
サンプルコードも載せて頂きましたが、数年に渡り使い込まれてきた事を想像できます。
例えば今回、ラッパーを作る、或いは何らかの手法でスクリプト側で対処するような措置をとったとして、さらに数年後、soraiya様、或いは仕事を引き継いだ別の方が内容を確実に把握してそのコードをメンテナンスできるか？という点がネックになってきます。
そういう所を踏まえますと、やはり、DB上の古いEUC-JPのデータをUTF-8に入れ替えた方が後々、躓く心配が少なくなります。ですので、何故soraiya様が入れ替えを避けるのかが気になった次第です。
DBの入れ替えであれば、知識やテクニックはDBだけの世界になりますのでDBのマニュアルなりドキュメントなりサポートフォーラムなりで、よりシンプルに解決できると思います。（さすがに自分はそこまではお手伝いできそうにありません・・・。力不足です。）
A01-1-1-1
replyersoraiya [1月4日 23:37]
ご返答をありがとうございます。
「今回問題となっているスクリプトは、soraiya様が個人で使用しているアプリでしょうか？それとも商いとして、お客様が使用しているアプリでしょうか？」
ハイ、商い用です。お客様がフォームから名前などの情報を入力して、それがDBに入っています。（私自身は、日本語が苦手な外国人担当者の代わりに日本語を入力したり、こうして質問を書いたりしていて実際の知識はないため、実は質問の内容を理解するだけでも難題となっています。）
「お客様が使用しているアプリであるならば、開発環境などで（今回の件であればスクリプトがUTF8に入れ替わった時）事前の動作確認などはしてらっしゃいますか？
あるいは現在、事前の動作確認をしている真っ最中で、そこで問題が起きているということでしょうか？」
アプリの開発者にテスト用の環境を作ってもらいテストをしているのですが、そこで文字化けが生じています。
「ともあれ、まずは使用しているDBとそのバージョンを教えて下さい。
あと気になりましたのは、データのUTF-8への入れ替えを避けたがっているように見えますがこれは何故でしょうか？データ量が多いからでしょうか？使用しているDBの制約でしょうか？」
データのUTF-8への入れ替えがすんなりとできるのであれば行いたいですが、たとえばすでに入っているデータを全てコピーして削除して入れなおすというような入れ替えは、データが多いため避けたいのです。
「・DBのバージョンやテーブルの文字コード
・PHPスクリプトがどのような順序でDBに接続しているか
・DBを操作する為にどのようなライブラリ(PEARのDB/MDBなり、ADODBなり、スクリプト独自なり）」
これら環境については、これでよいのか分かりませんが下記に分かっていることを記載させていただきます。
使用中のphp拡張：Mysql
MySqlクライエントのバージョン：４.1.22
テーブル照合順序：latin_swedish_ci
MySQL接続照合順序：utf8_unicode_ci
Mysqlの文字セット：utf-8 unicode
適切な答えかどうか分かりませんが、他の情報が必要でしたら
申し訳ありませんが、初心者でも分かりやすい言葉で教えてください。
よろしくお願いいたします。
A02
answerersignal [1月4日 22:44] (最終編集：1月4日 22:53)
データベースの文字エンコードは EUC のままでこの場を乗り越えたい」
ということであれば、
1. データベースのデータを UTF-8 にする
2. データベースから出し入れの際に EUC → UTF-8 の変換をする
のどちらかになると思います。
1. が NG ということになれば必然的に 2. を採用するしかないのですが
データベースの出し入れの部分をすべて修正しなければなりません。
# なので、提示されたソースは無関係です
がんばって、該当箇所を探し出して、変換をかけましょう。
- $data = 'フォームから取得したデータ';
- $data = mb_convert_encoding( $data, 'EUC', 'UTF-8' );
- # この後にデータベース格納処理
- $data = 'データベースから取得したデータ'
- $data = mb_convert_encoding( $data, 'UTF-8', 'EUC' );
- # この後にHTML表示処理
A02-1
replyersoraiya [1月5日 00:24] (最終編集：1月5日 01:03)
ご返答いただきありがとうございます。
申し訳ありませんが、私自身の理解に間違えがありました。
PHPmyadminで確認をしましたら、
テーブルのCollation（照合順序？）一つ一つは
latin_swedish_ciなのですが、
テーブルの最後のトータルが記載されている部分では、
ujis_japanese_ci となっています。
これはつまり、テーブルの文字コードがeuc-jpになっているということでしょうか。
問題はeuc-jpでインプットされたお客様情報が、utf-8でアウトプットすると文字化けするという状態です。つまり、euc-jpにエンコードされたページのフォームからお客様情報を入力してもらうとDBに情報が格納され、その情報をutf-8にエンコードされたphpでお客様へ送ると、文字化けが生じるという問題です。euc-jpにエンコードすれば文字化けしないと思いますが、phpスクリプトはロックされて追加できません。そこで、utf-8のままphpでお客様へ送りたいのです。
とすると、データベースのほうで何かするしかないでしょうか。
A02-1-1
replyer3Lvr4Qj9 [1月5日 00:55]
- DBのデータはeuc-jpで保存されていると記載してしまいましたが、実際は以前からutf-8に設定されていてutf-8で保存されているということです。
１．「PHPスクリプトはロックされていて」という表現が曖昧ですが、これは、「MySQLからデータを取得し、HTMLに整形して表示するPHPスクリプト」の事を指しており、このスクリプトが何らかの事情で変更できない/してはならない状態にあると解釈して宜しいですか？
２．PHPのバージョンはいくつですか？小数点以下の数字まで教えて下さい。
３．MySQLの設定あるいはPHPスクリプト側で
SET NAMES *****
というSQLを発行するようになっているか確認してみて下さい。"****"の部分は文字コード名が入ります。
PHPスクリプト側は、"set names"でgrepしてみて下さい。
あとはやぶれかぶれですが、データの出力時に、MySQLからデータを取得する直前に、
SET NAMES UJIS
あるいは
SET NAMES UTF8
というクエリを発行すると、上手く行く・・・かも、しれません。
Google先生も併せて確認してみて下さい。
「PHP MySQL 文字化け」
http://www.google.com/search?q=PHP+MySQL+%E6%96%87%E5%AD%97%E5%8C%96%E3%81%91&ie=utf-8&oe=utf-8
A02-1-2
replyersignal [1月5日 03:03]
あなたの状況は、旧システムの拡張もしくは新システムに入れ替えをしている途中で
旧システムが EUC を想定して作られているのが、新システムでは UTF-8 になっていて
かつ、その新システムのソースは凍結されていて、追加修正はできない。
ということですか？
旧システム＋新システムという状況であれば、ソースの修正なくしては対応できません。
こういうことです
- DB(EUC)からデータ(EUC)の取得
- データ(EUC)をデータ(UTF-8)に変換 ←ソースの修正
- データ(UTF-8)をHTML(UTF-8)で表示
ちなみに、現状なぜ文字化けするかというと
- DB(EUC)からデータ(EUC)の取得
- データ(EUC)をHTML(UTF-8)で表示 ←文字コードがチグハグ
しかし、完全に新システムへ移行するのであれば、データベースの文字コードの
変換することでソースの修正は必要なくできると思います。
こういうことですね
- DB(UTF-8)からデータ(UTF-8)の取得
- データ(UTF-8)をHTML(UTF-8)で表示
A02-1-3
replyer3Lvr4Qj9 [1月5日 10:10]
テーブルの文字コードはeuc-jpでしたか。
文字化けの流れとしては、signal様が書かれている通りだと思います。また、PHPスクリプトが変更不能だとすれば、DB側で対処するほか無い点についてもsignal様と同意見です。
で、実際にujisのテーブルを作ってみて、UTF-8のデータをPHPから入れられるか試してみたのですが、mysqlと接続した後で
SET NAMES UTF8
というクエリを発行すると、
PHP <---- (UTF-8) ----> MySQLサーバー(ここで変換) <--- (EUC-JP) ---> ujis(euc-jp)のテーブル
のようになり、どうにかUTF8のデータをPHP側からMySQLのeuc-jpのテーブルに入れることができました。
http://dev.mysql.com/doc/refman/4.1/ja/charset-connection.html
もしその辺りを修正・追加が可能であるならば、この手法を試してみて下さい。
A02-1-3-1
replyersoraiya [1月5日 23:14]
signal様、きれいにまとめてくださってありがとうございます。
現状をもう少しお話させていただけますと、現在、オリジナルのシステムとテストのシステムがあります。
オリジナルのシステムはeuc-jpで動いています。
テスト環境ではutf-8で動いています。テスト環境にはメインのシステムからeuc-jpで保存されているデータをコピーしました。その結果、コピーされたeuc-jpのデータが文字化けを起します。
ですのでsignal様がおっしゃったようにDBをutf-8に変更する場合（オリジナルのシステムをutf-8に変更することになりますが）、結局は文字化けを起すことになるのではないかと思います。
3Lvr4Qj9様がアドバイスくださった下記内容ですが、お恥ずかしいことに専門外の私には全く意味が分からず、せっかくのアドバイスの内容も試してみることができません。
お手数をおかけして大変申し訳ないのですが、初心者でも分かるように、具体的にどうすれば良いのかご説明いただけませんでしょうか。
「実際にujisのテーブルを作ってみて、UTF-8のデータをPHPから入れられるか試してみたのですが、mysqlと接続した後で
SET NAMES UTF8
というクエリを発行すると、
PHP <---- (UTF-8) ----> MySQLサーバー(ここで変換) <--- (EUC-JP) ---> ujis(euc-jp)のテーブル
のようになり、どうにかUTF8のデータをPHP側からMySQLのeuc-jpのテーブルに入れることができました。
http://dev.mysql.com/doc/refman/4.1/ja/charset-connection.html
もしその辺りを修正・追加が可能であるならば、この手法を試してみて下さい。 」
なにとぞよろしくお願いいたします。
A02-1-3-1-1
replyersignal [1月6日 01:42]
まず、文字化けの原因はシステムの文字コードとDBの文字コードがチグハグなためにおきています。
そのチグハグな状況を改善できれば文字化けはおきなくなります。
> オリジナルのシステムはeuc-jpで動いています。
> テスト環境ではutf-8で動いています。テスト環境にはメインのシステムからeuc-jpで保存されているデータをコピーしました。
> その結果、コピーされたeuc-jpのデータが文字化けを起します。
その通りです。文字化けて当然ですね。
問題はココです。
- テスト環境にはメインのシステムからeuc-jpで保存されているデータをコピーしました。
ここの作業を手抜きしたからこういうことになります。
テスト環境のシステムの文字コードは UTF-8 なので、データも UTF-8 に変換しましょう。
> ですのでsignal様がおっしゃったようにDBをutf-8に変更する場合
> （オリジナルのシステムをutf-8に変更することになりますが）、
> 結局は文字化けを起すことになるのではないかと思います。
オリジナルの環境とテストの環境が共存することがなければ、文字化けはおきません。
あなたの状況では総入れ替えのようですので気にしなくて大丈夫です。
- （オリジナルのシステムをutf-8に変更することになりますが）
専門の人にこう言ってください。
「システムの文字コードが変わったので、データベースの文字コードも変える必要があります。
テスト環境の構築はオリジナルのデータを UTF-8 に変換して投入してください。」
A02-1-3-1-1-1
replyersoraiya [1月6日 13:09]
ご丁寧なご説明をありがとうございます。
残念ながら専門の人がいないので、自分でなんとかするか、誰かに頼まないといけないのですが、「オリジナルのデータをUTF-8に変換して投入する」方法を、私のような初心者に説明していただくことはできますでしょうか。
お手数をおかけして申し訳ございませんが、よろしくお願いします。
A02-1-3-1-1-1-1
replyersignal [1月8日 00:52]
2. UTF-8 で新しくテーブルを作る
3. nkf とかで(1)のデータを EUC → UTF-8 に変換する
4. 変換したデータを流し込む
本当に初心者なら誰かに頼んだほうが無難かもです。
A02-1-3-1-1-1-1-1
replyersoraiya [1月8日 02:54]
アドバイスをありがとうございます。
そうですね、誰かに頼む方向で考えてみます。
なんとなくどのような流れで解決していけば良いか分かってきた感じがします。
本当にありがとうございました。
A02-1-3-1-1-1-1-2
replyersoraiya [1月10日 00:09] (最終編集：1月12日 22:41)
データベースのeuc-jpで保存されたデータをutf-8に変換する方法をアドバイスしてくださいましたが、自分ではどうしようもできず、ネットでそのような方を探しておりますがラチがあかず、当ウェブサイトでも個人的には紹介できないとのことで、この掲示板を通してお願いさせていただくことにいたしました。失礼のこととは思いますが、お願いできませんでしょうか。
よろしければ、直接メールにてご連絡いただけましたら幸いです。
メールアドレスは、"damavand5600" に "@yahoo.co.jp"をつけたアドレスとなります。
なにとぞ、よろしくお願いいたします。
soraiya
A02-1-3-2
replyersoraiya [1月8日 03:00]
アドバイスを誠にありがとうございました。
とても大切なアドバイスで、いただいたアドバイスを試してみたかったのですが、やはり知識がないためちんぷんかんぷんで、代行してくれる方を探してみたいと思います。
本当にありがとうございました。
ページのトップへ
GETのままでは検索エンジンのロボットが拾ってくれなかったためにSEO対策として有効だと言われていますね。