Ékezethibák (Ã, ű) költöztetés után: karakterkódolás javítása WordPressben

Scheo · 2026-09-14 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Tárhelyváltás után megnyitod az oldalt, és a „Szolgáltatások” menüpont helyén „Szolgáltatások” áll, a „győri” helyett „gyÅ‘ri”, a „műszaki” helyett „műszaki”. Az oldal betölt, a képek megvannak, csak a szöveg olvashatatlan. Ez szinte mindig ugyanoda vezet vissza: a lánc valamelyik pontján egy program rossz kódolással értelmezte ugyanazokat a byte-okat. Az esetek nagy része javítható, de ha rossz sorrendben nyúlsz hozzá, a javíthatót is véglegesen elrontod.

Miért lesz az á-ból á és az ű-ből ű költöztetés után?

Röviden: az UTF-8 a magyar ékezetes betűket két byte-on tárolja. Ha ezt a két byte-ot valami latin1 (Windows-1252) kódolásként olvassa, mindkettőből külön karakter lesz: az á (C3 A1) így „á”, az é (C3 A9) „é”, az ő (C5 91) „Å‘”, az ű (C5 B1) „ű” alakban jelenik meg.

A hibás karakterek alakjából már azelőtt sokat kiolvashatsz, hogy bármihez hozzányúlnál:

• á, é, Å‘, ű típusú hibák: UTF-8 byte-okat latin1-ként olvasott valami. Lehet csak megjelenítési hiba, de dupla kódolás is, amikor a hibás alak már az adatbázisban van.
• Fekete rombuszban kérdőjel (�): fordított eset, egybyte-os (latin1 vagy latin2) adatot jelenít meg a böngésző UTF-8-ként. A byte-ok ilyenkor általában épek.
• Sima kérdőjel az ékezetes betű helyén: egy konverzió már lecserélte a karaktert, mert a célkódolásban nem tudta ábrázolni. Ez adatvesztés, lekérdezéssel nem hozható vissza.
• õ és û az ő és ű helyett: latin1 és latin2 keveredése. Ez gyakran nem a költöztetéskor keletkezett, hanem már a régi oldalon is ott volt.

Saját tapasztalat: magyar WordPress oldalaknál a leggyakoribb forgatókönyv a dupla kódolás. A régi tárhelyen a táblák latin1-esek voltak, a WordPress viszont UTF-8 byte-okat írt beléjük latin1 kapcsolaton át. Mivel ugyanúgy olvasta vissza, évekig minden jól látszott. Exportnál a MySQL latin1-ből UTF-8-ra alakította ezeket a byte-okat, és onnantól a hibás alak tényleg bekerült a mentésbe, majd az új adatbázisba.

Hol dől el a karakterkódolás egy WordPress oldalon?

Röviden: öt ponton, és ezeknek egyezniük kell: a tábla és az oszlop karakterkészletén, az export és import kapcsolatán, a wp-config.php DB_CHARSET beállításán, a HTML meta charset jelölésen és a szerver által küldött Content-Type fejlécen.

1. Adatbázis-tábla és oszlop. A karakterkészlet (charset) azt határozza meg, hogyan tárolódnak a byte-ok, az összevetés (collation) azt, hogyan rendez és hasonlít össze a szerver. WordPresshez az utf8mb4 a helyes választás, jellemzően utf8mb4_unicode_520_ci vagy utf8mb4_unicode_ci összevetéssel. Hivatalosan igazolt: a MySQL régi utf8 nevű készlete legfeljebb három byte-os karaktereket tárol, az emojikhoz négy byte kell, ezért a WordPress a 4.2-es verzió óta utf8mb4-re állítja át a táblákat, ha a szerver támogatja.
2. Export és import. A mysqldump, a phpMyAdmin vagy egy migrációs bővítmény valamilyen kapcsolati karakterkészlettel olvas és ír. Ha ez eltér a tábláétól, a MySQL konvertál, és itt születik a legtöbb dupla kódolás.
3. wp-config.php. A define( 'DB_CHARSET', 'utf8mb4' ); sor határozza meg, milyen kódolással beszél a WordPress az adatbázissal. A DB_COLLATE maradhat üres, ilyenkor a szerver alapértelmezése érvényes.
4. HTML meta charset. A téma fejlécében lévő <meta charset=UTF-8> értéke a blog_charset opcióból jön, ami az admin felületen már nem látszik, de a wp_options táblában ott van.
5. Szerver-fejléc. A Content-Type: text/html; charset=UTF-8 fejléc. Hivatalosan igazolt: a W3C leírása szerint a böngésző a BOM után a HTTP fejlécet veszi figyelembe, és csak ezután a meta taget, vagyis egy rossz szerver-fejléc felülírja a helyes meta jelölést.

Van egy hatodik pont is: a téma és a bővítmények fájljai. Ha egy egyedi sablonba beégetett magyar szöveget Windows-1250 kódolással vagy BOM-mal mentettek el, az adatbázistól függetlenül hibásan jelenik meg.

Hogyan döntsd el, hogy a tárolt adat romlott el, vagy csak a megjelenítés?

Röviden: nézd meg a nyers byte-okat a HEX() függvénnyel. Ha az á helyén C3A1 áll, az adat ép, és a megjelenítéssel van baj. Ha C383C2A1, az adat dupla kódolt, vagyis maga a tárolt tartalom romlott el.

1. Hasonlítsd össze a sablonszöveget és a tartalmat. Ha a téma fix feliratai is hibásak, valószínűleg a fejléc vagy a fájlkódolás a gond. Ha csak a bejegyzések, oldalak és menük szövege, az adatbázis felé kell nézni.
2. Nézd meg a fejlécet. Terminálban: curl -sI https://domain.hu/ | grep -i content-type. Böngészőben a fejlesztői eszközök Network fülén, vagy a konzolban a document.characterSet értékével.
3. Nyiss meg egy hibás bejegyzést a szerkesztőben. Ha az admin felületen is „á” látszik, szinte biztos, hogy a tárolt adat sérült.
4. Kérdezd le a byte-okat egy ismert, ékezetes című bejegyzésre: SELECT ID, post_title, HEX(post_title) FROM wp_posts WHERE ID = 123;
5. Nézd meg a táblák kódolását: SELECT table_name, table_collation FROM information_schema.tables WHERE table_schema = DATABASE(); A vegyes eredmény (néhány tábla latin1, a többi utf8mb4) gyakori, és árulkodó.

A HEX-kimenet értelmezése az á betűre: C3A1 ép UTF-8; C383C2A1 dupla kódolt; E1 egybyte-os latin1 tárolás, ami latin1 oszlopban önmagában nem hiba, csak konverziót igényel; 3F a kérdőjel, vagyis az eredeti karakter elveszett.

Mit tegyél először, mielőtt bármit javítanál?

Röviden: ments. A hibás állapotról is készíts teljes adatbázis-mentést, a régi tárhely eredeti adatbázisát pedig hagyd érintetlenül, mert az a legértékesebb forrásod.

• Mentés WP-CLI-vel: wp db export elotte-$(date +%F).sql, és ezt a fájlt ne írd felül.
• A javítást másolaton (staging környezetben) próbáld ki, ne az éles oldalon.
• Amíg dolgozol, ne kerüljön be új tartalom: rendelés, hozzászólás, űrlapbeküldés.

Saját tapasztalat: az utolsó pontot sokan kihagyják, pedig a költöztetés után bekerülő rekordok már helyesen kódoltak. Ha egy sorban vegyesen van hibás és helyes szöveg, a tömeges javító lekérdezés a helyes részt rontja el. Minél tovább fut élesben a hibás oldal, annál nehezebb tisztán javítani.

Mikor elég egy beállítást átírni?

Röviden: akkor, ha a HEX-lekérdezés ép UTF-8 byte-okat mutat, és csak a megjelenítés hibás. Ilyenkor az adatbázishoz nem kell nyúlnod.

• Ellenőrizd, hogy a wp-config.php-ben a DB_CHARSET értéke utf8mb4 vagy utf8 (utóbbit a WordPress támogatott szerveren magától utf8mb4-re emeli).
• Nézd meg a blog_charset opciót: wp option get blog_charset. Az elvárt érték UTF-8.
• Ha a szerver rossz fejlécet küld, Apache alatt az AddDefaultCharset UTF-8, nginx alatt a charset utf-8; direktíva segíthet. Nézd meg azt is, hogy CDN vagy proxy nem írja-e át a fejlécet.
• Egyedi sablonfájlnál mentsd újra a fájlt UTF-8 kódolással, BOM nélkül.

Szakmai feltételezés: dupla kódolásnál csábító a DB_CHARSET visszaállítása latin1-re, mert a régi tartalom attól azonnal jól látszhat. Ez tüneti kezelés: az emojik, az újabb bővítmények és a következő költöztetés ugyanúgy elhasalhatnak rajta. Legfeljebb átmeneti vészmegoldás, amíg a valódi javítást előkészíted.

Mikor javítható lekérdezéssel, és mikor kell újraimportálni?

Röviden: ha a régi adatbázis még elérhető, az újraimportálás a tisztább út. Lekérdezéssel akkor javíts, ha csak a hibás másolat maradt, és a byte-ok dupla kódoltak. Kérdőjeles adatvesztésnél kizárólag egy korábbi mentés segít.

Újraimportálás a régi adatbázisból

Ha a forrás táblák latin1-esek, de UTF-8 byte-ok vannak bennük, exportálj latin1 kapcsolattal, így a MySQL nem konvertál: mysqldump --default-character-set=latin1 regi_db > nyers.sql. A dumpban cseréld a SET NAMES latin1, a CHARSET=latin1 és a latin1-es COLLATE értékeket utf8mb4-es megfelelőre, majd importálj: mysql --default-character-set=utf8mb4 uj_db < nyers.sql. Csere előtt keress rá a fájlban minden latin1 előfordulásra, mert oszlopszinten is lehet CHARACTER SET latin1 jelölés.

Javítás lekérdezéssel

Dupla kódolt szövegoszlopnál ez a minta visszafordítja az utolsó, hibás konverziót:

UPDATE wp_posts SET post_content = CONVERT(CAST(CONVERT(post_content USING latin1) AS BINARY) USING utf8mb4) WHERE post_content LIKE BINARY '%Ã%' OR post_content LIKE BINARY '%Å%';

Három csapda, amibe érdemes nem belesétálni:

• A BINARY nem díszítés. Az utf8mb4_unicode_ci összevetés nem különbözteti meg az ékezeteket, így egy sima LIKE '%Ã%' minden „a” betűt tartalmazó sorra illeszkedne.
• A vegyes sorok sérülnek. Ha egy sorban helyes ő vagy ű is van, az a latin1 konverziónál kérdőjellé válik. Előtte és utána is számold meg a kérdőjelet tartalmazó sorokat, és vesd össze.
• A szerializált adat eltörik. A wp_options és a wp_postmeta táblában a PHP-szerializált értékek rögzítik a szöveg byte-hosszát. Közvetlen javítás után ez nem egyezik, és widgetek, sablonbeállítások tűnhetnek el. Ide a WP-CLI alkalmasabb, mert újraszámolja a hosszakat: wp search-replace 'á' 'á' --all-tables --dry-run, betűnként, mindig próbafuttatással kezdve.

A wp_posts mellett nézd át a wp_terms, wp_comments, wp_postmeta és wp_options táblát is: a SEO-bővítmények címei, a képek alt szövegei és a menüfeliratok itt vannak.

Importhibák, amelyek kódolási eltérést jeleznek

• Unknown collation: 'utf8mb4_0900_ai_ci': MySQL 8-ból exportált adatbázist régebbi MySQL-be vagy MariaDB-be importálsz. A dumpban ezt az összevetést cseréld utf8mb4_unicode_520_ci-re.
• Specified key was too long; max key length is 767 bytes: régebbi adatbázismotor az utf8mb4 indexeknél. A WordPress emiatt bizonyos indexeket 191 karakterre korlátoz; tartós megoldás az újabb szerververzió.

Miért rontják az elrontott ékezetek a keresési és AI-láthatóságot?

Röviden: mert a kereső és a nyelvi modell számára a „gyÅ‘ri” nem a „győri” rossz írásmódja, hanem egy másik, értelmetlen karaktersor. A romlott szó nehezebben egyezik a keresési kifejezéssel, és egy olvashatatlan mondatot egy válaszmotor jó eséllyel nem idéz szó szerint.

Hivatalosan igazolt: a WHATWG Encoding szabvány és a W3C ajánlása szerint weboldalakhoz UTF-8 kódolást kell használni, és a kódolást egyértelműen jelölni kell. A Google Search Central dokumentálja, hogy a találati oldalon megjelenő cím és leírás a title elemből és a meta leírásból is származhat, ezek pedig ugyanúgy az adatbázisból jönnek, mint a törzsszöveg.

Saját tapasztalat: költöztetés után a hiba ritkán marad csak a látható szövegben. Ott van a title tagben, a SEO-bővítmény meta leírásában, a képek alt szövegében, az Open Graph címben és a strukturált adatban (JSON-LD) is, például a GYIK-blokkokban. Ezeket a szerkesztőben könnyű nem észrevenni, a forráskódban viszont egy Ã keresés azonnal kiadja őket.

Szakmai feltételezés: a keresők részben kezelik az ékezet nélküli írásmódot, de a mojibake nem ékezetelhagyás, hanem egészen más karakterek sorozata, így ott ez az egyeztetés várhatóan nem működik. Az AI-alapú válaszmotorok a kinyert szöveget darabolják és értelmezik, a torz szavak ezért gyengébben kötődnek a témához. Erről nincs nyilvános mérés, és a javítás sem garantál jobb helyezést, de az ép szöveg az alapfeltétele az egyezésnek és az idézésnek.

Mit ellenőrizz a költöztetés előtti percekben?

Röviden: rögzítsd a forrás kódolását, exportálj és importálj kifejezetten megadott karakterkészlettel, és ugyanazon a rekordon ellenőrizd a byte-okat előtte és utána.

1. Kérdezd le a forrás táblák összevetését az information_schema lekérdezéssel, és mentsd el az eredményt.
2. Válassz egy ékezetes című bejegyzést (ha van, mind a kilenc magyar ékezetes kisbetűvel), és jegyezd fel a HEX(post_title) értékét.
3. Írd fel a forrás wp-config.php DB_CHARSET és DB_COLLATE értékét.
4. Nézd meg a forrás és a cél MySQL vagy MariaDB verzióját, és hogy a cél ismeri-e a forrás összevetéseit.
5. A cél adatbázist kifejezetten így hozd létre: CREATE DATABASE uj_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
6. Exportnál add meg a karakterkészletet (mysqldump kapcsolóval, phpMyAdminban a fájl karakterkészletének beállításával), ne bízd az alapértelmezésre.
7. A kész dumpot nyisd meg UTF-8-at kezelő szövegszerkesztőben, és keress rá egy ékezetes szóra.
8. Kapcsold ki átmenetileg a rendelést, a hozzászólást és az űrlapokat, vagy tegyél ki karbantartási oldalt.
9. Import után futtasd le ugyanazt a HEX-lekérdezést ugyanarra a bejegyzésre, és vesd össze a feljegyzett értékkel.
10. Ellenőrizd a Content-Type fejlécet, és keress rá a forráskódban a Ã és Å karakterekre.
11. A régi tárhelyet és az eredeti mentést addig tartsd meg, amíg minden fenti pont rendben van.

Források és további olvasnivalók

• WordPress Developer Resources: Editing wp-config.php
• Make WordPress Core: The utf8mb4 Upgrade (WordPress 4.2)
• MySQL Reference Manual: Character Sets, Collations, Unicode; mysqldump
• MariaDB Knowledge Base: Character Sets and Collations
• W3C Internationalization: Declaring character encodings in HTML
• WHATWG Encoding Standard
• WP-CLI Commands: wp db export, wp search-replace
• Google Search Central: Title links és snippetek dokumentációja