WordPress och databasexporter: ä och ’ i stället för ä och ’

Visar dina inlägg plötsligt ä i stället för ä och ’ i stället för ’ efter en flytt, uppdatering eller databasexport? Datan finns nästan alltid kvar – den läses bara med fel teckenkodning. Mojibuster lagar exporten, sedan åtgärdar du orsaken i databasen.

Fungerar med text och med de här filerna:

  • CSV
  • TXT
  • JSON
  • XML
  • SRT
  • VTT
  • SMI
  • TSV
  • MD
  • HTML
  • SQL
  • LOG

Till exempel exporter från Excel, databasbackuper, undertexter eller webbplatskod.

Fixa

  1. Dra hit en fil eller klistra in text
  2. Fixen sker automatiskt
  3. Kopiera eller ladda ner
eller dra hit en fil

Så ser problemet ut

En rad ur en SQL-dump efter flytt till ny server

Före

INSERT INTO wp_posts (post_title) VALUES ('Smörgåsar på kaféet – räksmörgås');

Efter

INSERT INTO wp_posts (post_title) VALUES ('Smörgåsar på kaféet – räksmörgås');

Varifrån det kommer

WordPress lagrar text som UTF-8. Många äldre installationer skapade dock sina tabeller som latin1 eller anslöt med latin1. Så länge skrivning och läsning gör samma fel märker ingen något. Efter en flytt till ny server, en export med phpMyAdmin eller ett byte av anslutningens teckenuppsättning blir varje å, ä och ö plötsligt två tecken.

  • DB_CHARSET i wp-config.php är latin1 eller stämmer inte med tabellerna.
  • Dumpen exporterades som latin1 och importerades som utf8mb4 – eller tvärtom.
  • Ett tillägg eller importskript konverterade redan trasig text en gång till. Då uppstår dubbelkodad text som ä.

Laga exporten

  1. Ta en säkerhetskopia av databasen innan du ändrar något.
  2. Exportera de drabbade tabellerna som .sql-fil, till exempel med phpMyAdmin eller mysqldump --default-character-set=utf8mb4.
  3. Släpp filen i rutan ovan. Mojibuster lagar bara de trasiga ställena och visar varje ändring.
  4. Ladda ner den lagade filen och importera den med utf8mb4 i en ny testdatabas.
  5. Kontrollera webbplatsen. Ser allt rätt ut importerar du till den skarpa databasen.

Dumpen laddas aldrig upp – vilket är viktigt, eftersom den oftast innehåller användarkonton, e-postadresser och kommentarer. Mer om det för företag och dataskyddsombud.

Se upp med serialiserad data

WordPress lagrar vissa inställningar i wp_options och wp_postmeta som serialiserade PHP-värden, till exempel s:5:"Café";. Talet är längden i byte. Blir é till é igen stämmer det inte längre, och WordPress kastar värdet. Laga därför innehållstabeller som wp_posts, wp_comments och wp_terms först. För inställningar är wp search-replace från WP-CLI det bättre verktyget, eftersom det uppdaterar längderna.

Åtgärda orsaken i MySQL

  • Byt tabeller och anslutning till utf8mb4 och sätt define('DB_CHARSET', 'utf8mb4'); i wp-config.php.
  • Innehåller en latin1-kolumn UTF-8-byte ska du inte konvertera den direkt – då kodas den en andra gång. Den vanliga vägen går via en binär typ: först MODIFY … LONGBLOB, sedan MODIFY … LONGTEXT CHARACTER SET utf8mb4.
  • Testa varje ändring på en kopia av databasen först.

Vanliga frågor

Kan jag laga en hel WordPress-databas på en gång?

Ja, även stora SQL-dumpar. Tänk dock på serialiserad data i wp_options och wp_postmeta – WP-CLI hanterar det bättre.

Ändras korrekta tecken i dumpen?

Nej. Mojibuster lagar bara sekvenser som tydligt är trasiga. Korrekt text förblir som den är.

Vad är skillnaden mellan utf8 och utf8mb4?

I MySQL lagrar utf8 bara tecken på upp till tre byte, så emojis går förlorade. utf8mb4 är riktig UTF-8 och rätt val för WordPress.

Fungerar det för andra system än WordPress?

Ja. Joomla, Drupal, Magento eller ditt eget program på MySQL eller MariaDB har samma problem och samma lösning.

Mer att läsa