Charset conversion without mojibake

Charset conversion without mojibake means you change how stored bytes are labeled and interpreted on a spare copy first, then verify the data before you touch production. You dump the schema, inspect real rows, convert with a deliberate process, and inspect again. A browser encoding dropdown or a blind search-replace of “utf8” in a dump will not fix double-encoded text and often makes names worse.

Understand what the bytes already are

The database charset tells the engine how to read the bytes sitting in each column. It is not a decorative label on the schema. When a column is declared latin1 but already holds UTF-8 bytes, some clients still show names correctly while others show mojibake. A naive convert to utf8mb4 then recodes those bytes a second time and breaks the text. The usual repair is to convert the column to binary or blob first, then to utf8mb4, so the engine keeps the same bytes and only changes the interpretation. That is what people mean by fixing double encoding. Always rehearse the full path on a copy of the data.

Do not open the SQL dump and replace every “utf8” string with “utf8mb4” across the file. That edit can hit article content and leave garbage in posts. Use ALTER on the tables instead. WordPress already expects utf8mb4, so a brand-new site should start there and skip this repair path entirely.

Match the connection charset after the tables

Once the tables are utf8mb4, set DB_CHARSET to utf8mb4 in wp-config.php. A latin1 connection writing into utf8mb4 tables is another way to double-encode new data going forward. phpMyAdmin also uses its own connection charset when you browse rows. Confirm you are not viewing correct UTF-8 data through a latin1 window and “fixing” text that was already fine.

The collation dropdown on phpMyAdmin’s Operations tab is not a full conversion process. It can change the table charset without repairing bytes that were already wrong. If names looked right before that dropdown and wrong afterward, you recoded data that was already UTF-8. Restore the spare copy and use the binary round-trip instead.

Permissions you need for the ALTER

GRANTs are separate from charset work, except that the MySQL user running the ALTER needs ALTER on that schema. You do not need root for this. See GRANT USAGE vs ALL if you were about to run the change as root from a laptop.