メールテンプレートにて、一部文字化けが発生しております。

基本的には、以下の2つのテンプレートで発生しております。

症状としては、以下の様な文字化けが起こります。

【正しい】（一部）
************************************************
　ご注文商品明細
************************************************
　　↓
【文字化け状態】（一部）
************************************************
＆#12288;＆#12372;＆#35531;＆#27714;＆#37329;＆#38989;
************************************************
（※表示のために＆は大文字にしています。）

また、改行が2行になってしまいます。
また、文字化けの始まる最初に<p>というのが付きます。

ちなみに以下のテンプレートでは発生しておりません。
customer_regist_mail.tpl

特にメールテンプレートを触ったわけではないですし、文字コードもチェックしたのですが、特に問題ありませんでした。

「受注管理」の「個別通知」辺りを使い始めたら起こったような気がしないでもないのですが、確証がありません。

何か解決方法がありましたら、ご教授いただければと思います。

-------------------------------------------------------------------------------
[EC-CUBE] 2.12.2 (2.11.5からデータベースを移行しました。）
[レンタルサーバ] heteml
[PHP] PHP 5.3.19
[データベース] MySQL 5.0.82-community-log
-------------------------------------------------------------------------------

昨日、GMO-PGモジュール（2.12用）を導入したところ、
当方でも全く同じ現象が起きはじめました。

・自動返信には問題が無い
・メールテンプレート部分だけ文字化けをしている
・データベースから引き出した文字列については文字化けをしていない
・実際にメールを送ってみたのですが、文字化けをしたまま

追記

1月15日にheteml側で何らかの作業をしているようです。
http://heteml.jp/info/detail/id/192

初期からあるテンプレートは文字化けをしていません。
追加tplのみ文字化けをしています。

状況的にmbstring周りの挙動が怪しそうに見えますが、初期では文字化けせず、その後に追加されたファイルだけ文字化けというのは少々不可解ですね・・。

確かhetemlはmbstring関係のPHPプログラムからの指定が十分に効かなかった環境だった記憶が・・・

管理画面＞システム設定＞システム情報
の最初の部分の環境情報と、
その下のPHP情報内のmbstringに関する部分の設定情報が分かると何かしら分かるかもしれません。
mbstring.internal_encodingやmbstring.func_overload等の設定値の部分です。

恐らくPHP側のアップデートのタイミングで、何かしらのPHP設定が変わったりしたのかもしれないです（設定値追加が影響かもしれない？）。

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

その一画の情報、全てを掲載します。
当方でも色々試行錯誤しているのですが、何か解決法があればご教授いただけると助かります。

PHP Version 5.3.19

Multibyte Support enabled
Multibyte string engine libmbfl
HTTP input encoding translation disabled

Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) backtrack check On
Multibyte regex (oniguruma) version 4.7.1

mbstring.detect_order auto no value
mbstring.encoding_translation Off Off
mbstring.func_overload 0 0
mbstring.http_input UTF-8 pass
mbstring.http_output UTF-8 pass
mbstring.http_output_conv_mimetypes ^(text/|application/xhtml\+xml) ^(text/|application/xhtml\+xml)
mbstring.internal_encoding UTF-8 no value
mbstring.language ja Japanese
mbstring.script_encoding no value no value
mbstring.strict_detection Off Off
mbstring.substitute_character none no value

設定値だけ見ると不審な点は無いですね・・・

この問題は管理画面＞受注管理のメール通知機能から送る場合に生じているのでしょうか？
それとも、そのほかにも生じている所がありますか？

また、最近追加されたtplファイルだけ生じているとのことなので
Smartyキャッシュ周りが怪しいので少々リスクを承知のうえで作業出来るようであれば、以下の確認をしてみると良いと思います。

data/Smarty/templates_c/default/
のディレクトリに

%%11^123^124E4517%%order_mail.tpl.php

のような名前のファイルがあると思います。
先頭の部分は環境によって代わりますが、末尾が order_mail.tpl.php のファイルを探して中を開くと中身はどうなっていますか？
14行目あたりに「　ご請求金額」という文字が読める状態でありますか？

読める状態ならば正常ですが、読めないようであれば、Smartyのキャッシュ生成ルーチンに何らかの問題が生じてる可能性があります（そうなると調べるのは容易じゃなさそう・・・）。

もし読めない状態の場合、改善するかどうか分かりませんが、当該ファイルを一回どこかにバックアップして削除。
その後、文字化けする処理をさせる事によりキャッシュを再生成させてみる事で改善するかもしれません。

ですが、これは悪化する可能性もあるので少々怖いです・・・（バックアップの書き戻しで対応出来るのかどうか不明）

※hetemlの情報を見ると1/15のアップデート途中にセッションファイル等一時ファイル系の生成に何らかの障害があったようなので、疑うとしたら、そこらの影響が怪しいですが・・・

※ちなみに、さくらのVPS上でCentOS6のクリーンな環境で、EC-CUBE2.12.2インストール＋GMO-PG決済モジュールのインストールをしてみましたが、再現しませんでした。

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

色々気になったのでhetemlで環境作って試してみました。
色々触っているうちに再現させることに成功しました。

手元に再現環境作れたので、あとは地道に調べて結果報告したいと思います。

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

原因判明しました。
かなり複雑な問題ですが自分の備忘録も兼ねて少々濃い内容を書きます。簡単に見たい人は●のあたりと、最後を確認して下さい。

●第一の原因（主因）
「hetemlサーバー内のlibxmlの不具合、libxmlのバージョンが古い」

heteml環境のPHPがリンクしている libxmlライブラリが 2.6.16 と少し古いのですが、当該バージョンのライブラリには不具合(Bug)があり、これが特定の利用状態に当てはまると今回のような状況になります。

libxmlライブラリが2.7以上であれば改善済みの不具合のようです。libxmlが2.7.6の環境では再現しませんでした。

※といっても、PHPの動作要件は2.6.0以上となっているので、必ずしもhetemlが一方的に悪いわけでもないです。

※当該不具合の詳細ですが、PHP5のDOM::loadHTMLは不正なHTMLを読み込ませても一応、処理を続けることが出来る仕様です。ところが、特定のパターン（テキストの羅列＋記号？）に当てはまるHTMLの場合、該当のパターン部分を余計なノード(?)として勝手に操作してしまいます。これが<p>タグが勝手に追加されている理由です。この問題とXMLの仕様上の関係からマルチバイト文字を含まれるテキスト部分を長大なタグとして扱おうとし、自動で数値文字参照に変えているようです。さらに、そこまでしても旨く扱えず、libxml内の変数columnカウンタも異常な値になっているようです。2.7.6では、余計な操作は無くなり、タグも追加されず、数値文字参照にもならず、libxml内の変数columnカウンタも一応使えるような値になっていました。


●第二の原因：
「EC-CUBE本体としての問題としては、プラグイン用のTransform機能に、テキストだけのメールテンプレートを読み込ませる事が出来る、読み込んでしまう」

実際には今回の問題はトランスフォームを多重に呼び出された際に生じる問題となっています（オブジェクト内の変数リセットが不十分？）。

これは不具合と言うには少々酷かもしれませんが、プラグインのトランスフォーム機能の改善点として追加しなければいけないかもしれません。
※トランスフォーム機能は色々と問題があるので互換性を考慮しつつ修正を株式会社ロックオンさんと別途検討中です。


●第三の原因：
「EC-CUBE本体が、メールテンプレートのSmarty処理時にプラグインが無用にTransform機能を呼び出してしまう場合がある」

今回の問題は、プラグインをインストールしていなければ生じません。
またプラグインが特定の画面に介入しようとしなければ生じません。

簡単に確認したところ管理系画面にトランスフォームで介入するいくつかのプラグインが該当する可能性があります。その中の一つが、話題にも出ていたGMO-PG決済モジュールです。

前述のようにPHPの動作環境差異、しかもライブラリの不具合までプラグイン側に責任を持たすのは少々酷なのですが、プラグイン側で対策も可能です。
※GMO-PG決済モジュールに関しては当方からGMO-PG様に連絡します。早々に対策がされると思いますので該当する方はGMO-PG様のサポートに連絡すると良いと思われます。

●第四の原因：
「EC-CUBE本体がlibxmlのエラーを無視している」

実装次第ではPHPレベルでエラーを補足可能なのですが、EC-CUBE本体のプラグイン機能内では、DOMモジュールでのエラー（例外発生）を基本無視するようになっている問題。

これは恐らく動作環境（DOMはEC-CUBE自体では必須では無い）との兼ね合いもある部分です。
エラーで止まらず、そのまま走るのは良いのですが、エラーは補足して記録した方が良さそうですので、ここらへんも、しっかりとした実装に改修する必要があるという認識です。


こんなところでしょうか。

とりあえず、すぐに出来る対策としては、プラグイン管理にてOFFに出来るプラグインを探し、一回オフにしてみて、再現しない状態を作り、あとはhetemlなりEC-CUBE本体なりプラグインなりの対応を待つという感じになると思います。

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

AMUAMU 様

ありがとうございます。

当方でキーになったのは、GMO-PGモジュールのようです。
なので、ダメ元でheteml運営にxmllibのアップグレードを打診してみます。

導入プラグインを確認したところ、GMO-PGmod導入時に自動でいくつかのプラグインも入るようですね。GMO-PGmod関連のプラグインを止めたところ、当方で起きた現象が無くなりました。

取り急ぎ、文字化けを解決できました。
ありがとうございます。

私からもGMO-PGとhetemlに打診します。