個別記事
- 前後の記事
ロリポップphpMyAdminバージョンアップ
- この記事が属するカテゴリー
- web&blog
レンタルサーバのロリポップが、phpMyAdminのバージョンを2.5.7から2.6.0へ変更したようです。つか、知らなくて普通にログインしようと思ったら、いきなり変わっててビビったわけですが。どうやらPHPのバージョンアップによって、インポートが出来なくなっていたらしい。
サーバーのPHPバージョンアップを4.3.10にアップしましたが、PHPMyAdmin にて データのインポートが行われない現象が発生しておりました。 その為、PHPMyAdmin のバージョンを2.6.0に変更致しました。
おかげで、LanguageにJapanese(ja-utf-8)を指定できるようになり、DBバックアップのためのエクスポート作業において、日本語表示での作業が可能になりました。ちなみにバックアップの方法は「phpMyAdminでMySQLバックアップ」を参考にしてください。
2005-01-13T16:55:17+09:00
| コメント (15)
| トラックバック (0)
|
関連性が高いエントリー 5 件
トラックバック
- このエントリーのトラックバックURL:
- http://WWW.lucky-bag.com/cgi/mt/mt-tb.cgi/125
"ロリポップphpMyAdminバージョンアップ"へのトラックバックはまだありません。
コメント
- (o) さんからのコメント
![[TypeKey Profile Page]](http://www.lucky-bag.com/nav-commenters.gif)
私もロリポップなのですが、インポート問題が気になっていて以前から自分のディレクトリに2.6.0をインストールして使っています。
ロリポのインストールしたpma 2.6.0では、zip圧縮したダンプファイルを生成できないとか、user.lolipop.jpという一つの(分散化してあるのかもしれませんが)ホストで動作するために負荷が結構高いとか、時間帯によってはテーブルの取得にしばしば失敗するとか、結構ストレスが溜まりますね。
- 2005年01月13日 18:18
- e-luck さんからのコメント
(o)さん、こんばんは。
ちょっと気になるのは、サイトの文字コードがUTF-8の場合に、ファイル保存したSQLファイルの文字コードがSHIFT-JISで書き出されてしまい、２バイトが化けることです。pmaが2.6.0になったからと言う訳ではなく、PHP4.3.10にバージョンアップしてからの事象なんですが。
結局、ローカルに落としたSQLファイルをTelaPadとかで開いて、漢字コード指定再読込で保存して回避しているのですが。
- 2005年01月13日 18:49
- (o) さんからのコメント
phpMyAdminでは、ユーザーインタフェースのCharsetのほかに、ダンプ時に出力エンコーディングを選択するオプションがありますが、それが「non」以外になっていると他のエンコーディングに変換されます。もしそういうことでないのでしたら私がまだ遭遇していない症状ですね。
- 2005年01月13日 19:30
- e-luck さんからのコメント
えぇ、「non」での事です。
例えば、English(en-utf-8)でログインした場合でも駄目なんですよねぇ。
自分だけなの症状なんですかね。- 2005年01月13日 19:42
- (o) さんからのコメント
えと、ちょっと疑問に思ったことがあるので聞いてもいいですか?
> 結局、ローカルに落としたSQLファイルをTelaPadとかで開いて、漢字コード指定再読込で保存して回避しているのですが。
ということは、TeraPadで開くとSJISと認識されて文字化けする、文字コード指定再読み込みでUTF-8として再読み込み、という意味なのでしょうか?
- 2005年01月13日 20:27
- e-luck さんからのコメント
遅くなってすいません。
ええ、そうです。おっしゃる通りです。
今、家のマックでもやっぱりSHIFT-JISと認識されていますね。- 2005年01月13日 22:45
- (o) さんからのコメント
だとすると、ちゃんとUTF-8でダンプされているということですね。ダンプファイルをUTF-8と認識するかSJISと認識するかは確率的な問題ですから、特定のエディタがSJISと誤認する可能性はあります。Terapadだとオプションで初期文字コードをSJISからUTF-8に変更することできます(これによってこれまで正常に読めていたSJISのファイルが文字化けする可能性は多少あります)。
あとおまけですが、ときどきTrackbackで末尾の1,2バイトが欠落したUTF-8文字列が送られてくることがあります。こうしたデータは、文字コードの誤認の原因になりやすいですね。
- 2005年01月14日 14:17
- e-luck さんからのコメント
基本的にTerapadの文字コードは自動認識で、初期文字コード（これは新規ファイルの場合ですよね？）はUTF-8の設定にしてあります。
今手元に１２月２０日と２８日にダンプしたのが残っているのですが、それぞれヘッダ？部分の記述はPHP Versionは4.2.4-devと4.3.10となっていて、２８日にダンプした分は化けているんです。で、当然文字コードはそれぞれUFT-8（２０日）とSJIS（２８日）となっているんですよね。
ファイル自体はちゃんとUTF-8でダンプされているのに、エディター側がそれを認識出来なくなっているって事ですよね？いや、違うな。UTF-8でダンプされているけど、SJISで保存されているって事ですかね。- 2005年01月14日 15:25
- (o) さんからのコメント
TeraPadの機能については私が誤解していました。勝手に自動認識するみたいですね。
症状的には、ファイル自体はちゃんとUTF-8でダンプされているのに、エディター側がそれを認識出来なくなっているというので、正しいです。多分どこかに誤認の原因となるデータが含まれている可能性がありますが、見つけるのは正直難しいです。
- 2005年01月14日 15:52
- e-luck さんからのコメント
某巨大掲示板でデバッガと呼ばれる（笑）(o)さんが、そう言われるんであれば、やっぱ、難しいですよね。（すいません、冗談です）
文字化け状態でも、おそらくインポート自体は問題無く出来るという認識なんですが、何となく気持ち悪いですよね。- 2005年01月14日 16:24
- (o) さんからのコメント
（笑）
私がやるとすれば、こんな感じです。
(1)今やっている方法でUTF-8で再読み込みして、別名で保存します(改行文字はオリジナルに合わせます)。
(2)元のファイルとの差分をdiffなどを使って調べます。差分がなければお手上げ。
(3)運よく差分があり、だいたいどのあたりか分かったらphpMyAdminで修正してやります。- 2005年01月14日 17:25
- e-luck さんからのコメント
side-by-sideで出力したら、ごっそり<と>が表示されて嫌になりました（笑）
さらっと見た感じ、各テーブルのダンプデータはOKで、各テーブルの構造が全滅っぽいですね。
正直、あまり詳しくないんでお手上げです。
このまま見なかった事にする可能性大です（笑）- 2005年01月14日 18:20
- e-luck さんからのコメント
いや！直りました！
差分を見てたら、MTログのデータ部分に怪しいのを見つけまして、MTのログ消去したら、無事化けていないSQLファイルを落とせました。
(o)さん、感謝です！- 2005年01月14日 18:51
- (o) さんからのコメント
素晴らしい!!
たまたま簡単に消せる「ログ」でほんとに良かったですねー。お疲れ様でしたー。- 2005年01月14日 19:03
- e-luck さんからのコメント
いや、ホントありがとうございました。
結局、MTのサイト内検索にて半角スラッシュの入った語句を検索した方がいて、それかも知れません。いやー、仕事そっちのけでやった甲斐がありました（笑）- 2005年01月14日 19:07
コメントしてください
コメント内ではタグは一切使えません。コメント内にてタグを表記したい場合は、お手数ですが、文字実体参照を利用して < を < 、> を > とそれぞれ置き換えてください。