WP All Importでの文字化け解決法を徹底解説

WordPressに何かしらのデータをインポートする場面は多数あるかと思います。弊社でも定番に「WP All Import」を利用しており、ユーザーに、ACFに便利に利用しています。

ユーザーをインポートしたときにスキップされたのがどれだがわからないのはちょっと辛いのですが。。。

実は、それ以外にも文字化けするケースがあることに気づきましたのでそのチェックポイント等を本記事を公開していきます。本文の途中に記述もありますが、動作環境の問題らしくプラグイン提供側のサポートでは対応していただけないとのことです。

どのような文字が化けるのか？

全ての文字列を発見できているわけではありませんが（する必要もありませんが）以下のwp all importでインポートしたときに文字化ける例と文字化けしない例をアップします。

 文字化けとなる

萩
辻
辻岡

文字化けにならない

萩の花が咲き乱れる小径を抜け、彼は急いでその辻を曲がった。待ち合わせの時間はもう過ぎている。
萩原
萩野
萩本
辻村
辻本

短い日本語のときに誤判定になるようです。名前や単語等をインポートするときには要注意です。

この内容をサポートに問い合わせたところ、プラグイン提供元では、そのような文字化けは発生せず、それぞれの動作環境問題なのでプラグイン提供側では対応しないとのことでした。

この文字化けを更に追求してみた

ユーザーのインポートも多数行うので毎回修正しているのは非常に手間となるため、具体的にどの部分でそのような文字化けになるのかを追求していきます。

ファイルをアップロードするとインポート用の「XML」ファイルに変換するようです。気になる人は、「wp-content/uploads/wpallimport/uploads」の中を覗いてみると良いです。

このXMLファイルに変換する時点ですでに文字化けが発生していました。

ということで、アップロードからXMLファイル作成あたりを見ていったところ、「fixEncoding」というfunctionでPHP関数「mb_convert_encoding」で１つの項目ずつ、文字コードを判別している動作のようです。

AIにmb_convert_encodingの正確性を聞いてみたところ、

⚠️ mb_convert_encodingの文字コード自動判定は不正確です

mb_convert_encoding()関数自体は文字コードの変換を行う関数であり、文字コードを自動で判定する機能はおまけ的なものです。特に、変換元のエンコーディングを省略するか、"auto"を指定した場合（内部でmb_detect_encoding()が使われます）の自動判定の精度は高いとは言えません。

とのことで、不正確のようです。

文字コードの曖昧性: 多くのマルチバイト文字コード（日本語のShift_JIS、EUC-JP、UTF-8など）は、特定のバイト列が複数のエンコーディングで有効な文字として解釈できてしまう曖昧さを持っています。特に日本語以外のデータが混ざると、判定が難しくなります。

まあ、難しいようです。環境も含めてなんだかんだ影響があるようで。。。これ以上追求しても仕方がないのでここまでとします。

この文字化けの対処はどうするか？

結論として、別の文字コード判定functionを作成しました。

そして、プラグインの該当箇所で拡張したfunctionがあれば、そっちを参照するようにというコードを１文どうしても追加することになりました。

目的の文字化けは解消されました。短い文字だけ影響するのでユーザーインポート時にはご注意ください。