ロリポップphpMyAdminバージョンアップ

レンタルサーバのロリポップが、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バックアップ」を参考にしてください。

phpmyadminログイン画面

この記事についての情報

似た内容の記事

この記事に対するトラックバック

トラックバックURL: http://www.lucky-bag.com/mt/mt-tb.cgi/260

Comments

(o) said:

私もロリポップなのですが、インポート問題が気になっていて以前から自分のディレクトリに2.6.0をインストールして使っています。

ロリポのインストールしたpma 2.6.0では、zip圧縮したダンプファイルを生成できないとか、user.lolipop.jpという一つの(分散化してあるのかもしれませんが)ホストで動作するために負荷が結構高いとか、時間帯によってはテーブルの取得にしばしば失敗するとか、結構ストレスが溜まりますね。

e-luck said:

(o)さん、こんばんは。
ちょっと気になるのは、サイトの文字コードがUTF-8の場合に、ファイル保存したSQLファイルの文字コードがSHIFT-JISで書き出されてしまい、2バイトが化けることです。pmaが2.6.0になったからと言う訳ではなく、PHP4.3.10にバージョンアップしてからの事象なんですが。
結局、ローカルに落としたSQLファイルをTelaPadとかで開いて、漢字コード指定再読込で保存して回避しているのですが。

(o) said:

phpMyAdminでは、ユーザーインタフェースのCharsetのほかに、ダンプ時に出力エンコーディングを選択するオプションがありますが、それが「non」以外になっていると他のエンコーディングに変換されます。もしそういうことでないのでしたら私がまだ遭遇していない症状ですね。

e-luck said:

えぇ、「non」での事です。
例えば、English(en-utf-8)でログインした場合でも駄目なんですよねぇ。
自分だけなの症状なんですかね。

(o) said:

えと、ちょっと疑問に思ったことがあるので聞いてもいいですか?

> 結局、ローカルに落としたSQLファイルをTelaPadとかで開いて、漢字コード指定再読込で保存して回避しているのですが。

ということは、TeraPadで開くとSJISと認識されて文字化けする、文字コード指定再読み込みでUTF-8として再読み込み、という意味なのでしょうか?

e-luck said:

遅くなってすいません。
ええ、そうです。おっしゃる通りです。
今、家のマックでもやっぱりSHIFT-JISと認識されていますね。

(o) said:

だとすると、ちゃんとUTF-8でダンプされているということですね。ダンプファイルをUTF-8と認識するかSJISと認識するかは確率的な問題ですから、特定のエディタがSJISと誤認する可能性はあります。Terapadだとオプションで初期文字コードをSJISからUTF-8に変更することできます(これによってこれまで正常に読めていたSJISのファイルが文字化けする可能性は多少あります)。

あとおまけですが、ときどきTrackbackで末尾の1,2バイトが欠落したUTF-8文字列が送られてくることがあります。こうしたデータは、文字コードの誤認の原因になりやすいですね。

e-luck said:

基本的にTerapadの文字コードは自動認識で、初期文字コード(これは新規ファイルの場合ですよね?)はUTF-8の設定にしてあります。
今手元に12月20日と28日にダンプしたのが残っているのですが、それぞれヘッダ?部分の記述はPHP Versionは4.2.4-devと4.3.10となっていて、28日にダンプした分は化けているんです。で、当然文字コードはそれぞれUFT-8(20日)とSJIS(28日)となっているんですよね。
ファイル自体はちゃんとUTF-8でダンプされているのに、エディター側がそれを認識出来なくなっているって事ですよね?いや、違うな。UTF-8でダンプされているけど、SJISで保存されているって事ですかね。

(o) said:

TeraPadの機能については私が誤解していました。勝手に自動認識するみたいですね。

症状的には、ファイル自体はちゃんとUTF-8でダンプされているのに、エディター側がそれを認識出来なくなっているというので、正しいです。多分どこかに誤認の原因となるデータが含まれている可能性がありますが、見つけるのは正直難しいです。

e-luck said:

某巨大掲示板でデバッガと呼ばれる(笑)(o)さんが、そう言われるんであれば、やっぱ、難しいですよね。(すいません、冗談です)
文字化け状態でも、おそらくインポート自体は問題無く出来るという認識なんですが、何となく気持ち悪いですよね。

(o) said:

(笑)

私がやるとすれば、こんな感じです。
(1)今やっている方法でUTF-8で再読み込みして、別名で保存します(改行文字はオリジナルに合わせます)。
(2)元のファイルとの差分をdiffなどを使って調べます。差分がなければお手上げ。
(3)運よく差分があり、だいたいどのあたりか分かったらphpMyAdminで修正してやります。

e-luck said:

side-by-sideで出力したら、ごっそり<と>が表示されて嫌になりました(笑)
さらっと見た感じ、各テーブルのダンプデータはOKで、各テーブルの構造が全滅っぽいですね。
正直、あまり詳しくないんでお手上げです。
このまま見なかった事にする可能性大です(笑)

e-luck said:

いや!直りました!
差分を見てたら、MTログのデータ部分に怪しいのを見つけまして、MTのログ消去したら、無事化けていないSQLファイルを落とせました。
(o)さん、感謝です!

(o) said:

素晴らしい!!
たまたま簡単に消せる「ログ」でほんとに良かったですねー。お疲れ様でしたー。

e-luck said:

いや、ホントありがとうございました。
結局、MTのサイト内検索にて半角スラッシュの入った語句を検索した方がいて、それかも知れません。いやー、仕事そっちのけでやった甲斐がありました(笑)