WordPress- og databaseeksporter: ø og ’ i stedet for ø og ’

Viser innleggene dine plutselig ø i stedet for ø og ’ i stedet for ’ etter flytting, oppdatering eller databaseeksport? Dataene er nesten alltid fortsatt der – de leses bare med feil koding. Mojibuster retter opp eksporten, og så fikser du årsaken i databasen.

Fungerer med tekst og med disse filene:

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

For eksempel eksporter fra Excel, databasesikkerhetskopier, undertekster eller kode fra nettsider.

Fiks

  1. Dra en fil hit eller lim inn tekst
  2. Fiksingen skjer automatisk
  3. Kopier eller last ned
eller dra en fil hit

Slik ser problemet ut

En linje fra en SQL-dump etter flytting til ny server

Før

INSERT INTO wp_posts (post_title) VALUES ('Blåbærsyltetøy – årets sesong på Ålesund');

Etter

INSERT INTO wp_posts (post_title) VALUES ('Blåbærsyltetøy – årets sesong på Ålesund');

Hvor det kommer fra

WordPress lagrer tekst som UTF-8. Mange eldre installasjoner opprettet imidlertid tabellene som latin1 eller koblet til med latin1. Så lenge skriving og lesing gjør samme feil, merker ingen noe. Etter flytting til en ny server, eksport med phpMyAdmin eller endring av tegnsettet for tilkoblingen blir plutselig hver æ, ø og å til to tegn.

  • DB_CHARSET i wp-config.php er latin1 eller samsvarer ikke med tabellene.
  • Dumpen ble eksportert som latin1 og importert som utf8mb4 – eller omvendt.
  • Et tillegg eller et importskript konverterte allerede ødelagt tekst én gang til. Da oppstår dobbelt kodet tekst som ø.

Rett opp eksporten

  1. Ta sikkerhetskopi av databasen før du endrer noe.
  2. Eksporter de berørte tabellene som .sql-fil, for eksempel med phpMyAdmin eller mysqldump --default-character-set=utf8mb4.
  3. Slipp filen i feltet ovenfor. Mojibuster retter bare de ødelagte stedene og viser deg hver endring.
  4. Last ned den reparerte filen og importer den med utf8mb4 i en ny testdatabase.
  5. Sjekk nettstedet. Ser alt riktig ut, importerer du den i den ordinære databasen.

Dumpen lastes aldri opp – det er viktig, siden den som regel inneholder brukerkontoer, e-postadresser og kommentarer. Mer om det for bedrifter og personvernombud.

Pass på serialiserte data

WordPress lagrer noen innstillinger i wp_options og wp_postmeta som serialiserte PHP-verdier, for eksempel s:8:"Blåbær";. Tallet er lengden i byte. Når ø blir til ø igjen, stemmer det ikke lenger, og WordPress forkaster verdien. Reparer derfor innholdstabeller som wp_posts, wp_comments og wp_terms først. For innstillinger er wp search-replace fra WP-CLI det bedre verktøyet, fordi det oppdaterer lengdene.

Fiks årsaken i MySQL

  • Bytt tabeller og tilkobling til utf8mb4 og sett define('DB_CHARSET', 'utf8mb4'); i wp-config.php.
  • Inneholder en latin1-kolonne UTF-8-byte, må du ikke konvertere den direkte – da kodes den en gang til. Vanlig fremgangsmåte går via en binær type: først MODIFY … LONGBLOB, deretter MODIFY … LONGTEXT CHARACTER SET utf8mb4.
  • Test hver endring på en kopi av databasen først.

Ofte stilte spørsmål

Kan jeg reparere en hel WordPress-database på én gang?

Ja, selv store SQL-dumper. Pass likevel på serialiserte data i wp_options og wp_postmeta – WP-CLI håndterer dem bedre.

Blir riktige tegn i dumpen endret?

Nei. Mojibuster retter bare sekvenser som er tydelig ødelagt. Riktig tekst blir som den er.

Hva er forskjellen på utf8 og utf8mb4?

I MySQL lagrer utf8 bare tegn på opptil tre byte, så emojier går tapt. utf8mb4 er ekte UTF-8 og det riktige valget for WordPress.

Fungerer dette også for andre systemer enn WordPress?

Ja. Joomla, Drupal, Magento eller ditt eget program på MySQL eller MariaDB har samme problem og samme løsning.

Les mer