2026年9月29日

古いphpMyAdminでWordPressのデータが文字化けする原因と設定の見直し方

エラー・白い画面

古いphpMyAdminでWordPressのデータベースを開くと日本語や絵文字が文字化けする場合、まず確かめるべきなのは「サイトの表示も化けているかどうか」です。サイトが正常に表示されているなら、データは無事で、phpMyAdminとデータベースの間の文字コードの扱いが合っていないだけのことがほとんどです。この記事では、表示だけの問題とデータ自体の問題を見分ける方法、それぞれの直し方、そしてデータを壊さないための注意点を説明します。

なぜ古いphpMyAdminで化けるのか

WordPressは4.2以降、データベースの文字コードとして utf8mb4 を使います。utf8mb4 は絵文字や一部の漢字を含むすべてのUnicode文字を扱える方式で、wp-config.php の DB_CHARSET にも通常 'utf8mb4' が入っています。

MySQLには、これより前からある utf8（現在は utf8mb3 とも呼ばれ、1文字3バイトまでしか扱えない方式）もあります。古いphpMyAdminやその設定では、データベースに接続するときの文字コードが utf8 や latin1 のままになっていることがあり、その場合、utf8mb4 で保存された文字が「?」になったり、意味の分からない記号の並びになったりします。

phpMyAdminは画面に表示するために、サーバーとの接続文字コードを決めてデータを受け取ります。つまり、データベースの中身が正しくても、受け取り方を間違えれば画面では化けます。この点を押さえておくと、慌ててデータを書き換えて本当に壊してしまう事態を避けられます。

まず「表示だけの問題か」を見分ける

次の順で確認します。

サイトの表示を確認する：記事のタイトルや本文がサイト上で正しく表示されているか見ます。正しければ、データは無事である可能性が高く、直すべきはphpMyAdmin側です。
別の手段でデータを見る：WP-CLIが使えるなら、WordPressと同じ設定で接続して中身を確認できます。

wp db query "SELECT ID, post_title FROM wp_posts ORDER BY ID DESC LIMIT 5"

保存されているバイト列を確認する：表示の問題を避けて、実際に保存されている値を16進数で見ます。

SELECT ID, post_title, HEX(post_title) FROM wp_posts WHERE ID = 123;

たとえば「あ」は utf8mb4 では E38182 の3バイトです。日本語のタイトルが E3 で始まる3バイトの並びになっていれば、データは正常に保存されています。一方、C3 や C2 で始まる並びが続き、元の文字数に比べてバイト数が大きく膨らんでいる場合は、一度別の文字コードとして解釈されて保存し直された「二重エンコード」の可能性があります。

表示だけの問題なら：phpMyAdmin側を直す

phpMyAdminを更新する

いちばん根本的な対処は、phpMyAdminを新しいバージョンに更新することです。古いバージョンは文字コードの扱いだけでなく、既知の脆弱性や新しいPHPへの非対応が残っていることがあり、公開サーバーに置いたままにするのは避けたいものです。

レンタルサーバーで提供されているphpMyAdminを使っている場合は、事業者が新しい版を用意していないか確認します。自分で入れたものなら、公式サイトから最新版を取得して入れ替えます。

接続の照合順序を確認する

更新できない事情がある場合は、phpMyAdminのトップ画面にある接続の照合順序（「サーバ接続の照合順序」などと表示されます。表記はバージョンで異なります）が utf8mb4 系になっているか確認し、utf8mb4_unicode_ci などに変更します。

設定ファイル（config.inc.php）で既定値を指定することもできます。

// phpMyAdmin の config.inc.php
$cfg['DefaultConnectionCollation'] = 'utf8mb4_unicode_ci';

この設定項目の有無や既定値はphpMyAdminのバージョンで違うため、使っている版のドキュメントで確認してください。

WordPress側の設定は変えない

phpMyAdminで化けるからといって、wp-config.php の DB_CHARSET を utf8 などに変えるのはやめてください。サイト側の保存や表示がかえって壊れます。通常は次の状態のままで問題ありません。

define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

別のツールを使う

phpMyAdminにこだわる必要が無ければ、WP-CLIの wp db query や wp db export を使う方法もあります。WordPressと同じ接続設定を使うため、文字コードの食い違いが起きにくいのが利点です。軽量なデータベース管理ツールのAdminerも選択肢ですが、phpMyAdminと同様に、公開サーバーに置く場合はアクセス制限と更新の管理が欠かせません。

エクスポート・インポートで化けた場合

古いphpMyAdminでエクスポートしたファイルを別のサーバーにインポートしたら化けた、というケースもよくあります。この場合は、ファイルの文字コードと、インポート時の指定が合っているかを確認します。

エクスポート時のファイルの文字コードは utf-8 を選びます。
インポート時も、ファイルの文字コードとして utf-8 を指定します。
移行先のデータベースやテーブルが utf8mb4 に対応しているか確認します。

phpMyAdminを経由せず、コマンドで文字コードを明示してエクスポートする方法もあります。

# WP-CLI（追加の引数は mysqldump に渡される）
wp db export backup.sql --default-character-set=utf8mb4

# mysqldump を直接使う場合
mysqldump --default-character-set=utf8mb4 -u dbuser -p dbname > backup.sql

大きなデータベースは、phpMyAdminのアップロード上限やタイムアウトで途中までしか取り込まれず、それが文字化けのように見えることもあります。件数が元のサイトと合っているかもあわせて確認します。

データ自体が化けている場合

サイトの表示も化けていて、HEX の確認で二重エンコードが疑われる場合は、データの修復が必要です。これはデータを書き換える作業なので、次の点を守ってください。

作業前にデータベース全体のバックアップを取ります。
本番ではなく、複製したステージング環境で試します。
まず SELECT で変換後の結果を確認し、正しく戻ることを確かめてから UPDATE します。

latin1 として二重に変換された文字列を戻すときによく使われるのが、次のような変換です。まずは表示だけで試します。

SELECT ID,
       post_title,
       CONVERT(CAST(CONVERT(post_title USING latin1) AS BINARY) USING utf8mb4) AS fixed_title
FROM wp_posts
WHERE ID = 123;

fixed_title が正しい日本語になれば、この方法で戻せる可能性があります。ただし、化け方は経緯によって違うため、すべての行に同じ変換が当てはまるとは限りません。

特に注意が必要なのは、wp_options や wp_postmeta に入っているシリアライズされたデータです。シリアライズされた値には文字列のバイト数が記録されているため、SQLで文字列を書き換えてバイト数が変わると、WordPressがその値を読めなくなり、設定が消えたように見えます。こうしたデータの修復は、バックアップから戻すほうが安全な場合が多いです。

なお、phpMyAdminの画面表記や設定項目、レンタルサーバーで提供されるバージョンは変わることがあります（2026年10月現在）。

まとめ

WordPressは utf8mb4 を使います。古いphpMyAdminが utf8 や latin1 で接続していると、データが正常でも画面で化けます。
サイトの表示、WP-CLI、HEX の確認で、表示だけの問題か、データ自体の問題かを先に見分けます。
表示だけなら、phpMyAdminの更新か接続の照合順序の変更で対処し、wp-config.php の DB_CHARSET は変えません。
エクスポート・インポートでは文字コードを utf-8（utf8mb4）に明示します。
データの修復は、バックアップを取りステージングで SELECT による確認をしてから行います。シリアライズされたデータの書き換えには特に注意します。