WordPressサイトを別のサーバーへ引っ越しするというのは、サイト運営者にとって避けては通れない道の一つです。新しい環境でサイトを再出発させるのはワクワクする一方で、技術的な問題に直面することも少なくありません。特に、データベースの移行に伴う「文字化け」は、多くの人が経験する代表的なトラブルと言えるでしょう。
今回は、私が実際に遭遇したWordPress引っ越し時の文字化け問題と、その解決に至るまでの経緯、そしてそこから学んだ重要な教訓について、詳しく解説していきます。もしあなたがWordPressの引っ越しを控えている、あるいはすでに文字化けに悩まされているなら、きっとこの記事が助けになるはずです。
ページコンテンツ
予期せぬ文字化けの発生
ある日、私は運用中のWordPressサイトをより高性能な新しいサーバーへ引っ越しすることにしました。引っ越し作業は、WordPress本体ファイルの移動と、最も重要であるデータベースの移行の大きく二つに分かれます。
標準的なデータベース移行手順
データベースの移行は、一般的に以下の手順で行います。
- 移行元サーバーでのデータベースのエクスポート（ダンプ）
- 移行先サーバーでの新しいデータベースの作成
- 移行先サーバーでのデータベースのインポート（流し込み）
このプロセスの中で、文字コードの指定が非常に重要になります。というのも、データベースに格納されているテキストデータは、特定の文字コード（例：UTF-8、Shift_JISなど）でエンコードされているため、エクスポート時とインポート時で異なる文字コードを指定してしまうと、文字が正しく認識されず「文字化け」が発生してしまうからです。
私のWordPressサイトのデータベースは、当時広く使われていたutf8（MySQLのutf8は実際には3バイトまでの文字をサポート）で運用されていました。新しいサーバーのデータベースも同様にutf8で設定する予定でしたので、私は自信を持って移行作業を進めました。
最初の試み：utf8での統一
移行元サーバーでデータベースをダンプする際、私はmysqldumpコマンドに--default-character-set=utf8オプションを指定しました。
mysqldump -u [ユーザー名] -p --default-character-set=utf8 [データベース名] > dump.sqlそして、移行先サーバーでこのdump.sqlファイルを新しいデータベースに流し込む際も、同様にutf8を指定しました。
ysql -u [ユーザー名] -p --default-character-set=utf8 [データベース名] < dump.sql一見すると、これで問題なく移行できるはずでした。しかし、サイトの表示を確認すると、部分的に文字化けが発生しているではありませんか！特に、絵文字や一部の特殊文字が表示されるべき箇所が、明らかに意味不明な記号の羅列になっていました。
「なぜだ？」と頭を抱えました。移行元と移行先のデータベース設定、そしてダンプ・インポート時の文字コードをutf8で統一したはずなのに、文字化けが解消されない。これは、私が知っている一般的な文字化けの原因とは異なる、何か別の要因があるに違いないと感じました。
混乱の極み：utf8mb4を指定してみた結果
文字化けの原因を探る中で、私はふとMySQLの文字コードについて再確認しました。すると、WordPressの最近のバージョンでは、絵文字などの4バイト文字を正しく扱うために、データベースの文字コードとしてutf8ではなく**utf8mb4**を推奨していることを思い出しました。
「もしかしたら、移行元のデータベースは実質的にutf8mb4のデータを扱っていて、それをutf8でダンプしようとしたために問題が起きたのではないか？」
そう考えた私は、次なる試みとして、移行元データベースのダンプ時にutf8ではなく**utf8mb4**を指定することにしました。そして、移行先のデータベースに流し込む際もutf8mb4を指定しました。
二度目の試み：utf8mb4での統一（失敗）
移行元サーバーでデータベースをダンプする際、--default-character-set=utf8mb4オプションを指定。
mysqldump -u [ユーザー名] -p --default-character-set=utf8mb4 [データベース名] > dump_mb4.sqlそして、移行先サーバーでこのdump_mb4.sqlファイルを新しいデータベースに流し込む際も、同様にutf8mb4を指定しました。
mysql -u [ユーザー名] -p --default-character-set=utf8mb4 [データベース名] < dump_mb4.sql「今度こそ！」と期待してサイトを確認しました。しかし、結果はまさかの「文字化けが全く改善されていない」。どころか、もしかしたら前よりもひどくなっているような気さえしました。
ここで私は完全に混乱しました。utf8でダメならutf8mb4で、と試したのに、状況は変わらない。一体何が問題なのか、皆目見当がつきませんでした。
真の原因の特定：バイナリデータの検証
八方塞がりの状況で、私は最後の手段として「ダンプされたSQLファイルのバイナリデータそのもの」を検証することにしました。テキストエディタで開いても意味不明な文字の羅列に見える部分を、バイナリエディタで開いて生のデータを確認するのです。
疑問に感じたこと
- 最初のダンプ（
--default-character-set=utf8）で作成されたdump.sqlこのファイルをバイナリエディタで確認すると、文字化けしていた部分（例えば、絵文字など）に対応するバイナリが、本来あるべきバイト列とは明らかに異なっていることを発見しました。これは衝撃的でした。つまり、データベースから正しいデータが読み込まれたにもかかわらず、ダンプのプロセス中にそのデータが壊れてしまっていた、ということです。 - 二度目のダンプ（
--default-character-set=utf8mb4）で作成されたdump_mb4.sqlこちらも同様にバイナリエディタで確認しました。すると、やはり文字化けしていた部分のバイナリが、期待される正しいバイト列とは異なっていることを確認しました。
この発見は、私にとって非常に重要な示唆を与えました。問題は、移行先サーバーでの流し込み時やWordPressの設定ではなく、移行元サーバーでのダンプの段階でデータが壊れてしまっている、という可能性です。
解決への光明：mysqldump時のcharacter-setの再考
私がこの問題で深く考えていなかった点が一つありました。それは、mysqldumpコマンドの--default-character-setオプションが、「ダンプするデータの文字コード」を指定するのではなく、「MySQLクライアントとサーバー間の通信で使用する文字コード」を指定するものだ、という事実です。
そして、MySQLの内部では、データはそれぞれのテーブルやカラムに設定された文字コードで格納されています。もし、実際のデータがutf8mb4で格納されているにもかかわらず、クライアント（mysqldump）との通信をutf8で行おうとすると、絵文字などの4バイト文字が正しく扱われずに、途中で切り捨てられたり、別の文字に変換されてしまう可能性があるのです。
再び試す：ダンプ時もutf8mb4を指定
この仮説に基づき、私は再び移行元サーバーでのダンプに挑戦しました。今度は、「実際のデータがutf8mb4で格納されている可能性が高い」という前提に立ち、ダンプ時も--default-character-set=utf8mb4を明示的に指定しました。
mysqldump -u [ユーザー名] -p --default-character-set=utf8mb4 [データベース名] > final_dump.sqlそして、このfinal_dump.sqlファイルをバイナリエディタで確認しました。すると、驚くべきことに、文字化けしていた箇所に対応するバイナリデータが、ようやく正しいバイト列になっていることを確認できました！これこそ、私が求めていた正しいデータです。
このfinal_dump.sqlファイルには、破損したデータではなく、絵文字を含むすべての文字が正しくエンコードされた状態で格納されていることが分かりました。
最終的な解決と学び
正しいバイナリデータを含むfinal_dump.sqlが手に入ったので、あとはこれを移行先サーバーのデータベースに流し込むだけです。移行先サーバーのMySQLも、当然ながらutf8mb4をサポートしている必要があります。WordPressの最新バージョンを使用している場合は、wp-config.phpでデータベースの文字セットがutf8mb4に設定されていることも確認しましょう。
最後の流し込み
mysql -u [ユーザー名] -p --default-character-set=utf8mb4 [データベース名] < final_dump.sqlドキドキしながら、新しいサーバーに引っ越ししたWordPressサイトを開いてみました。すると、今まで文字化けしていた部分が、すべて完全に正しい文字で表示されているではありませんか！感動しました。
この一連のトラブルシューティングを通じて、私は非常に重要な教訓を得ました。
教訓：MySQLの文字コードとmysqldumpの深い関係
- MySQLの
utf8は完全なUTF-8ではない
MySQLのutf8文字セットは、実際にはUTF-8の3バイトまでの文字しかサポートしていません。絵文字などの4バイト文字を扱うには、**utf8mb4**を使用する必要があります。WordPressが近年utf8mb4を推奨しているのはこのためです。 mysqldumpの--default-character-setは重要
このオプションは、ダンプされるデータの文字コードがどうであるかというよりも、mysqldumpクライアントがMySQLサーバーと通信する際の文字コードを決定します。もしデータベース内のデータがutf8mb4で格納されているのに、ダンプ時にutf8を指定すると、4バイト文字が正しく転送されず、結果としてダンプファイル内でデータが破損してしまう可能性があります。- データが壊れるのはダンプ時
今回のケースでは、文字化けの原因は移行先での流し込み時ではなく、移行元でのダンプ時にすでにデータが壊れていたことでした。ダンプされたSQLファイルのバイナリを確認することで、この事実を突き止めることができました。 - 常に最新の環境に合わせる
WordPressの引っ越しでは、移行元の環境と移行先の環境、そしてWordPressが推奨する設定を常に確認し、それに合わせてデータベースのダンプ・インポートを行うことが重要です。特に、文字コードに関しては、utf8mb4を基本として考えるべきです。
まとめ
WordPressの引っ越しで文字化けに遭遇した場合、慌てずに以下の点を再確認してみてください。
- 移行元のデータベースが、見た目上
utf8となっていても、実際にはutf8mb4のデータ（特に絵文字など）を含んでいる可能性があることを認識する。 mysqldumpコマンドを実行する際には、--default-character-set=utf8mb4を明示的に指定する。これにより、MySQLクライアントとサーバー間の通信がutf8mb4で行われ、4バイト文字も正しくダンプされます。- ダンプされたSQLファイルをバイナリエディタで確認し、実際に正しいバイナリデータが格納されているかを検証する。これが、データ破損の有無を確認する最も確実な方法です。
- 移行先のデータベースも**
utf8mb4で作成し、インポート時も--default-character-set=utf8mb4を指定する**。
WordPressの引っ越しは、一見するとシンプルな作業に見えますが、データベースの文字コードといった細かい部分で落とし穴があります。しかし、適切な知識と検証を行うことで、ほとんどの問題は解決可能です。今回の私の経験が、同じような問題に直面している誰かの助けになれば幸いです。
安全でスムーズなWordPressの引っ越しを実現し、新しいサーバーで快適なサイト運営を楽しみましょう！