3.41 → 3.66アップデートで、更新がうまく言ったと思ったのも束の間。アイテムのデータフィールドが全てLatin1に。ititle・ibody・imoreでcharset set latin1。部分的にいじっていたテンプレートの日本語部分も、同様に文字化け。どこかで対象ブログのヴァージョンと同じものをインストールし、事前に3.66更新パックを試してからでないと、これじゃあ怖くて更新できません。
バックアップをとるのは当然としても、アップデーターが「成功!!」と言ってくるわりには、妙な結果です。
ちなみに、今回の対処は、latin1とされてしまったitemテーブルを削除し、手作業でitemテーブルを再作成し、バックアップから復元、でした。
今回、実験のために、自前のどうでも良いブログを犠牲にしましたが、このままではお客様のブログには適用しかねます。
どうも、アップデートの対象ヴァージョンと3.66との各種組み合わせの中に、化けた根拠はSQLテーブルのlatin1指定なので、ひょっとしたらLMNucleusの内容から移植されたところで、日本語化について抜けたところがあったりしないのかなぁ、と推測したりしてしまいましたが、どうなのでしょう。或いは、3.41といった古いヴァージョンからだと、一旦3.64あたりにアップした上で、3.66への更新をかけるべきなのか、とも思ったりしています。いずれにしても、全く別なブログを仕立てた上で、更新チェック専用にして実験することにします。
他にも3.66更新で文字化けというエントリもありましたから、お困りの方は他にもおられるやも知れないと、問題の報告まで。
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
アップデート処理に関しては、既存のテーブルのエンコードを別のもの(latin1など)に変換する処理は、本家版・日本語版ともに入っていないです。
https://www.google.co.jp/search?q=htmls … ars+php5.4
LMNucleusから移植した処理は、ほぼ全て上記の問題に関するものなので、データベースとは直接の関係はなさそうです。
データベースのエンコード設定がイレギュラーなまま(latin1など)日本語のサイトを運用できていた古いバージョンのNucleusから、文字化けの問題を本質的に解決した3.6系にアップデートした際に、結果的に文字化けが発生してしまう件は確認されていて、他のケースは現時点では問題自体が確認されていないです。
もしよければ調べてみたいですので、手探りになると思いますが、さらにヒントがあれば教えていただきたいです。
今のところ気になるのは、utf8・EUC-JPのどちらか、レンタルサーバであればそのサービス名、そのサービスは試用できるかどうか、データベースのバージョン、データベースの(テーブルではなく)デフォルトのエンコード、などの情報です。
アップデーターが「成功!!」と言ってくるわりには、妙な結果です。
$CONF['Language']がjapanese-utf8やjapanese-eucなどになっているのに、テーブルのエンコードがlatin1などになっている場合は、問題があることを表示するとよさそうですね。ちょっと考えてみます。
オフライン
素早いご応答、いたみいります。
レンタルサーバーは米のHE.netですが、もうじきサーバー環境を更新するという知らせがありましたので、最新状態に変わる前に、状況を把握するためでもありました。
試用は不可能です。現在、ヴァーチャルサーバー切り貸しサービスを終えてまして、新たに契約できるのはサーバーまる一台ぐるみレンタルだけです。
PHP 5.2.4-2ubuntu5.27 / MySQL 5.0.96-0ubuntu3 (5.0.96) です。エンコードは全て、UTF-8。同じサーバー上で、3.65sp1まで問題なく使えてきています。
こんなところで、どうでしょうか。
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
latin1に変わったのはitemテーブルのititle・ibody・imoreフィールドだけでしょうか?
だとすると、
https://github.com/NucleusCMS/NucleusCM … p#L95-L103
アップグレードスクリプト内でこの3つのフィールドにタッチするのは上記の部分だけなんですが・・・だとしても関係なさそうに思います。
(この部分はv2.0用だし、3.65sp1と変わってないので、3.66で挙動が違うというのも考えにくいですし)
3.41といった古いヴァージョンからだと、一旦3.64あたりにアップした上で、3.66への更新をかけるべきなのか、とも
Nucleusに限らないのですが、これはやらないほうがいいと思います。なぜかというと、アップグレードスクリプト自体に含まれる不具合を修正していることがあるからです。たとえば3.65sp1と今回の3.66にも、データベース内のバージョン更新を行なわないという軽微な不具合があります。
PHP 5.2.4-2ubuntu5.27 / MySQL 5.0.96-0ubuntu3 (5.0.96)
この環境でutf8だと問題なさそうですね。うーん?
オフライン
自動でできるアップグレードはありません。データベースは既に最新の Nucleus 用にアップデートされています。
3.65sp1からのアップグレードであれば、アップグレード時に上記のように表示されると思います。この場合、データベースの構造を変換するような処理は一切行ないません。
ここをクリックしてデータベースを Nucleus v3.66 用にアップグレードします
3.5系以前の場合は上記のように表示されます。このリンクをクリックするとデータベースの構造を変換する処理を行ないますが、今回はこれは表示されなかったはず。
このへんはどうでしたか?
オフライン
3.41からの分では、もちろん、下のものが表示されています。同じサーバー上で、新しいヴァージョンも混ざって動いている、という意味でした。(ちょっとややこしい書き方でした。すみません)
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
今回は3.65sp1は関係なく、3.41から3.66へアップデートした際のトラブルということですね。了解です。
アイテムのデータフィールドが全てLatin1に。ititle・ibody・imoreでcharset set latin1。部分的にいじっていたテンプレートの日本語部分も、同様に文字化け。
charset set latin1ということですが、これは具体的にはどのように確認されましたか?
他にも3.66更新で文字化けというエントリもありましたから、
こちらの情報も気になります。もしよければそのエントリーの内容を教えていただいていいですか?
オフライン
Latin1の確認は、NavicatとSecuelPro、GUIのSQLツールアプリで見ています。
なお、もう一つ文字化けの件についての話題があった件は、「http://japan.nucleuscms.org/forum/viewtopic.php?id=5942」で、私の勘違いです。3.66ではありませんでした。お詫びして訂正します。
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
なるほどそのようなツールがあるのですね。実際にテーブルの情報を確認されたようなので、間違いないと思います。
ひとつ気になるのですが、もともとlatin1だったということはないでしょうか?3.4系あたりまでは、テーブルのエンコードがlatin1でも表面的には文字化けせず使えていました。その場合、3.6系にアップデートすると文字化けが発生します。
オフライン
他にも同じサーバー、アカウントでNucleusを幾つかインストールしていて、それらも同様に確認していますが、UTF-8になっています。ですので、最初からLatin1という間違いはないはずです。時間ができたら別に再インストールでブログを仮にこさえて、そこでアップデートを再チェックする作業をする予定でおりますが、多忙で思うにまかせていません。すみません。
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
3.70更新ではテーブルの問題で更新は叶わぬままにエラーで、表示ページ群は吹っ飛びました。やはり怖くて、更新はムリですね…。LMNucleus CMSかWordpressをインストールして、そっちに引っ越して貰うしかないような感じですが、LMはまだ手間はかかるようですが… https://www.facebook.com/higuchicom/pos … 9781544985
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
Facebookのその記事は古い情報で、v3.7xはLMNucleusのコミット内容も全て取り込んであります。LMNucleusはエンコードまわりの考慮がされておらず、日本語環境での導入は高い確率で問題が発生します。最新のPHP環境への対応も不十分です。
もしよければ具体的な状況を教えていただいてよいですか?
オフライン
いろいろ、ありがとうございます。
ふと思い立って、InpExpを介したらどうだろうと…。で、WordPressでも別に問題が発生していて、ちょっと変えるには疑問だらけなので、更新からInpExpで吐いたファイルを戻したらどうだろうと。ただ、InpExpが現在動作しませんで、どうにもなりませんけれど。
SQL側は、どうやら大元デフォルトがLatin1らしく、テーブルだけをUTF-8にしても駄目でした。と、いうことは、デフォルトでlatin1の場合に化けさせないバージョンというのがあれば良いなぁとか、思ってしまいますが。サーバー引っ越しだの何だのとなるとかなり大変ですし、お客様には関係あってもお分かりいただきにくいコトですので。
あと、 http://snowland.net/nucleus/item/3767/category/7 のような変換ツールがあると良いなぁ、とも。いずれにせよ、もうしばらく悩みながら取り組んでみます。
編集者 tomi (2015-06-18 12:26:40)
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
お返事遅くなりました。この件、ありがちなケースとして認識していますので、少し気になってます。もしよければ、サイトのURLなど具体的な情報をご案内いただければ解決までフォローさせていただきます。
直接連絡が必要であれば yamamoto@kyms.jp までご連絡ください。
オフライン
どうも、ご心配いただいているようで恐縮です。
実は、ことごとく失敗を続けています。結局、latin1からとりだしたUTF8のバックアップは、いずれもUTF8になっている(nkf --guess)ものの、それでも、表示上は日本語になってない。UTF8のDBを新たに作ってそこに戻しても、一緒。
Nucleusのバックアップ・レストアは同一ヴァージョンでないと使えないから、無意味。プラグインInpExpも、最近のヴァージョンでは動作せず、無意味。
正直、お客様のブログでの対処方法の安全な結論は、そのまま固定ファイルを生成するプラグインなんてものがあるなら全部固定HTMLとして吐き出させ、ブログプログラムとしての役割を終えさせる。で、新ヴァージョンのNucleusで新たに再スタートしてもらうのが良いのではないか、です。
他のブログプログラムに移行するのは、お客様が操作に馴染んでおられることや、作り込んでいるスキンの造作などもあり、あり得ません。
なお、折角お申し出いただいておりますが、サイトは同一ホスティングの別サーバーに複数あり、それぞれに導入時期の違いなどから環境が微妙に違うようですので、難しいかと。お気持ちは有り難く頂戴します。
…と、いうわけで、固定したHTMLページとして全てを吐き出させ、古いNucleusを安全に休眠させるような方法が採れないか、というのが、現在望んでいるところです。
まだまだコード回りの変換などトライしてはみますが、本当にややこしくて、つい、めげています。
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
古いバージョンのNucleusの管理画面で生成したバックアップデータは化けてないと思います。これがあればバージョンアップは可能で、業務では実際にバージョンアップをしています。ただし手作業が間に入るので(難しい作業ではないですが慣れが必要)、この過程の処理をプラグインなどの形でツール化したいと考えています。たぶん数行程度の処理を差し替えるだけで実装できるはずですが。
もしお手伝いできる状況のサイトがありましたら、ご連絡ください。
オフライン
ありがとうございます。
実は、管理画面生成のバックアップ(sql)からのレストアでは、同一の3.31→3.31でも化けます。化け様は、疑問符(?)の連続です。Navicatで作ったバックアップ(csv)はちゃんと読めますし、文字化けもなく、そのままレストアして復旧。最悪のトラブルは回避できています。ちなみに、疑問符の連続になるのは、別途新規インストールした3.7での新規投稿も同様です。
で、ググってみたところ、Wordpressでも疑問符の連続になるという問題が発生しており、ひょっとしたら実は、この3.66前後及び3.7に起きた問題は、wordpressなど他のCMSも全て内包していて、その部分は触らずに放置、或いはSQL設定によってインストール方法を変えるなどのロジックを採ってないか(ンなことでけるんかいな…)、と思うようになりました。つまり、正面からSQL側の問題と対峙せず、とりあえず使える状態を保っている、と (御参考 https://ja.forums.wordpress.org/topic/150125 )。米の本家Nucleusの開発を終了させたのも、この解決できそうでできない問題がハードルだった、ということは…ないでしょうかねぇ。なんせ、初期からののlatin1設定のSQLは相当量ありそうに思えますから。
ちなみに、Navicatでの実験時のテーブルの処理の仕方ですが、先ず、_itemテーブルを定義だけコピー。できたテーブルにバックアップファイルをレストアし、元になったテーブルとコピーのテーブルの名前を変えて、コピー側を元のファイル名にして完了、です。これで、どう化けたとしても元には戻せて、助かっています。
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
本家が開発終了を宣言したのは、宣言した人のほぼ個人的な問題で、こちらはいずれまた原作者を交えて話し合いの機会を持ちたいと考えています。
管理画面から取得したSQLデータをテキストエディタで開いてみて、それも化けていますか?たぶん化けてないはずで、それなら簡単に対応できますが、もし化けていてもサイトの表示は化けていないわけなので、少し遠回りになりますが対応する方法はあります。
アップデート時に化ける理由は分かっていますので、あとは何度かテストをして処理を実装すれば解決できると思います。
オフライン
ありがとうございます。とても大きなヒントでした。
「もし化けていてもサイトの表示は化けていないわけなので、少し遠回りになりますが対応する方法はあります。アップデート時に化ける理由は分かっていますので…」
と、今までの経緯( http://japan.nucleuscms.org/forum/viewtopic.php?id=4826 )・経験からで…
/nucleus/libs/sql/mysql.php 78行目 sql_set_charset($charset);
/nucleus/libs/libs/globalfunctions.php 377行目 sql_set_charset(_CHARSET);
をコメントアウト、で文字化けは解消しました。一応、実験に供していたブログの一つは、無事3.7となりました。
ちなみにこのやり方、疑問符に化けても、崩れて化けても有効でした。
さて、大凡はこれで無事なのですが、カテゴリがまだ、化けています。どっかに類似の鍵があるんでしょうが…
ともあれ、本家本人とも話しあわれるとのこと。心強い限りです。是非、辞めずにお続けください。 m(_"_)m
編集者 tomi (2015-07-09 16:10:48)
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
この方法だと、厳密にはセキュリティ上の問題があります。MySQLが接続時にエンコードを明示するようになったのは、文字を正確に扱う目的(並べ替えなど)に加え、セキュリティ上の問題を解決する目的があります。今となっては旬な脆弱性(?)でもないので、そうそう狙われることはないと思いますが・・
この問題を解決するには、アプローチとしては、データベースの運用を正規化することが必要になります。Nucleusの管理画面から取得できるリストアデータは文字化けしていないはずなので、いったんデータベースをエンコードを指定して正しく作り直してから、このリストアデータを読み込ませると解決します。phpMyAdminなどで開いて文字化けしてなければ、そのまま最新のNucleusを走らせることができます。もし解決したい場合は検討してみてください。
オフライン
幾つかのパターンで順次試してきましたが、まだ完璧なノントラブルの更新には至っていません。更新時、挿入しているHTMLタグやHTML特殊文字を勝手に、かつ半端に除去してしまうのは、セキュリティ上のことではあるのでしょうが、どうにかならんのでしょうか。一見無事に移行できたようでいて、できてない。この件を含めると、実はバックアップからは厳密には戻せない、ということになります。3.7への更新の印象は、まるで地雷原のようです。
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン
3.7の問題であれば簡単なのですが、MySQL側の問題なので普通に考えると難しいですね。ただ、作業としてはデータベース側とインポートするデータの両方を正規化してphpMyAdminなどでインポートするだけですんなり完了します。もし再現環境を用意することができれば、この作業を自動化するツールを作ってみます。
オフライン
https://github.com/NucleusCMS/NucleusCM … 88e4d3.zip
実際に問題が起きているサイトで詳細を確認する機会がありましたので、各部を改善してみました。
・DB側のコレーション設定(エンコード)を最初に確認
・DB側のコレーションのとおりにsql_set_charset関数でエンコードをセットする
・それがNucleusの言語ファイルで指定されているエンコードと同じであれば問題なし
・Nucleusの言語ファイルで指定されているエンコードと違う場合は、管理画面を開くたびにJavaScriptでアラートを表示
・【ここがポイント】管理画面の「DBの保存と復元」でデータのバックアップを取得する
・ここで取得したデータは正しいコレーション設定に正規化されているため、このデータを使って再リストアすればDBが正規化される
・解決。アラートも表示されなくなる
という感じです。
これで、v3.4あたりからのアップデートで文字化けが発生する問題は解決できると思います。(念入りなテストは必要ですが)
DBのコレーション設定を直接正規化するツールも作成できると思いますので、時間がある時にやってみます。
オフライン
https://github.com/NucleusCMS/NucleusCM … 8a6fd7b57c
日本語環境では問題があるデフォルト設定のままアップデートされてしまったDBのコレーション設定(エンコード)を正規化するツールを作成しました。手作業で変換するとかなりの作業量になるので、当ツールをお使いいただければと思います。既存のテーブルには変更を加えず、「temp_」というプレフィックスを付加した新しいテーブルを作成しますので、変換後にconfig.phpでテーブルプレフィックスの設定を変更してください。
v4.1・v5.0以降のMySQLが定着する頃に本格的な普及が始まったWordPressやDrupalなどの後発CMSと違い、Nucleusはv3・v4のMySQLが全盛の頃にユーザが増えていますので、最近になってレンタルサーバ側でPHPやMySQLのアップデートが始まったため、この種のトラブルで困っている古いユーザさんも多いと思います。
オフライン
忙しさにかまけてしばらくここを拝見しておりませんでしたら、Yamaさん、素晴らしいものをこさえてくださっていたのですね。多謝です。これで、どぉしようかと悩んでいるサイトも更新できそうです。先ずはどこぞで実験した上で、また報告しますね。でも、フォーラムの中に留まっているのはもったいないので、公開してさしあげてはどうでしょう。実はWPではトラブルで全部吹っ飛ぶという可能性があって、とても怖くて実装できないと最終的に判断したところでした。Nucleusには是非、しぶとく残る…いや、むしろ今後も、伸びていただきたCMSだと思っています。本当にありがとうございました。反応が遅くなったことをお詫びし、御礼申し上げます。
--Tomi------------------------------------------
tech@digi-hound.com
DIGIHOUND LLC USA President
---------------------------------------------------
オフライン