Du skapade en databas i phpMyAdmin, installerade WordPress och en vecka senare ser du förvrängd text istället för läsbara tecken i dina tabeller. Du öppnar inställningarna och ser latin1_swedish_ci. Alla som jobbar med Laragon på Windows stöter förr eller senare på den här överraskningen.

Problemet är att MySQL-bygget som Laragon installerar som standard ärver en uråldrig standard: latin1 som teckenuppsättning och latin1_swedish_ci som kollationering. För svenska är detta oftast inget problem, men för ryska är det en katastrof: kyrilliska tecken skrivs som frågetecken eller nonsens, strängsortering går sönder och plugins kraschar med felmeddelanden.

Nedan följer två ändringar i en fil som permanent löser problemet. Det tar tre minuter. Fungerar på Laragon 6, 5 och till och med den gamla version 4.

💡 Snabb översikt:

• Öppna my.ini via Laragon-menyn och lägg till två rader i sektionen [mysqld]
• Välj utf8mb4_unicode_ci som det optimala valet för WordPress 2026 (och vi förklarar varför)
• Spara filen, starta om MySQL och verifiera resultatet i phpMyAdmin
• Bonus: hur du ändrar teckenkodning för en befintlig databas utan att förlora data

Varför standardkodningen överhuvudtaget spelar roll

MySQL arbetar med ett arvssystem i flera nivåer: server → databas → tabell → kolumn. Om latin1_swedish_ci är satt på servernivå kommer varje ny databas att ärva det om inget annat anges vid skapandet.

För WordPress är detta kritiskt eftersom:

• Kärnan, teman och de flesta plugins lagrar innehåll i utf8mb4
• När WordPress automatiskt skapar en databas via wp-config.php åsidosätter det INTE serverns standard
• Teckenuppsättningskonflikt mellan server och tabeller ger "oklara" fel: ??? i adminpanelen, trasiga tecken i JSON REST API, krascher vid export

Enligt data från W3Techs driver WordPress 43,5% av alla webbplatser på internet, och CMS:et har krävt utf8mb4 sedan version 4.2 för fullt emoji-stöd. Laragon är en av de mest populära lokala servrarna för Windows, men dess MySQL-bygge levereras med en konservativ standard för bakåtkompatibilitet. Därav konflikten.

Steg 1: Öppna my.ini via Laragon-menyn

Det enklaste sättet att komma åt MySQL:s konfigurationsfil är via Laragons inbyggda meny:

• Högerklicka på Laragon-ikonen i systemfältet
• Välj Meny → MySQL → my.ini

Anteckningar (eller din standardredigerare) öppnas med hela MySQL-konfigurationen. Filen är indelad i sektioner inom hakparenteser: [client], [mysqld] och [mysqldump]. Vi är intresserade av [mysqld] (sektionen för MySQL-demonens inställningar).

Om menyn av någon anledning inte öppnar filen, hitta den manuellt: C:\laragon\bin\mysql\<version>\my.ini. I Laragon 6-byggen kan sökvägen vara C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini, beroende på installerad version.

Steg 2: Lägg till två rader i sektionen [mysqld]

Bläddra till sektionen [mysqld] och lägg till följande två rader i slutet (före nästa sektion, om det finns någon):

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Vad som händer här:

• character_set_server = utf8mb4 talar om för servern att som standard använda UTF-8 Multilingual Version 4-kodning, vilket stöder ALLA Unicode-tecken inklusive emoji, kyrilliska och hieroglyfer
• collation_server = utf8mb4_unicode_ci sätter regeln för strängjämförelse: _unicode_ betyder "enligt Unicode-standarden", _ci betyder skiftlägesokänslig jämförelse

Du måste lägga till dessa rader specifikt i [mysqld], inte i [client] eller [mysqldump]. Att använda fel sektion är den vanligaste orsaken till att "ingenting förändrades".

Hela sektionen efter redigering bör se ut ungefär så här:

1
[mysqld]
2
port=3306
3
socket=/tmp/mysql.sock
4
key_buffer_size=256M
5
max_allowed_packet=512M
6
character_set_server = utf8mb4
7
collation_server = utf8mb4_unicode_ci

Steg 3: Spara filen och starta om MySQL

Spara my.ini (Ctrl+S) och starta om MySQL. I Laragon görs detta via samma meny:

• Högerklicka på Laragon-ikonen i systemfältet
• Meny → MySQL → Stopp
• Vänta 3-5 sekunder
• Meny → MySQL → Start

Alternativt, klicka på Meny → Starta om så stoppar och startar Laragon alla tjänster på en gång.

Efter omstarten kommer nya databaser att skapas med utf8mb4_unicode_ci som standard. Befintliga databaser ändras INTE automatiskt. Läs avsnittet "Vanliga frågor" nedan för att lära dig hur du konverterar en befintlig databas.

Steg 4: Verifiera resultatet i phpMyAdmin

Öppna phpMyAdmin via Laragon-menyn (Meny → MySQL → phpMyAdmin) och skapa en testdatabas:

• Klicka på "Skapa databas"
• Ange valfritt namn
• Titta på rullgardinsmenyn "Kollationering": den bör nu ha utf8mb4_unicode_ci som standard

Om rullgardinsmenyn fortfarande visar latin1_swedish_ci, kontrollera att raderna character_set_server och collation_server lades till i sektionen [mysqld] (inte [client]) och att det inte finns några extra mellanslag mellan parameternamnet och =-tecknet.

Snabb verifiering via SQL-fråga (kör i phpMyAdmin på SQL-fliken):

1
SHOW VARIABLES LIKE 'character_set_server';
2
SHOW VARIABLES LIKE 'collation_server';

Båda variablerna bör returnera utf8mb4 respektive utf8mb4_unicode_ci.

Vilken kodning ska man välja: jämförelse av alternativ

MySQL-kodning har samlat på sig många myter, så låt oss bryta ner tre aktuella alternativ och ett föråldrat:

Varför vi rekommenderar utf8mb4_unicode_ci för lokal utveckling i Laragon:

• Laragon levereras med olika MySQL-versioner (från 5.7 till 8.0+), och utf8mb4_0900_ai_ci dök upp först i MySQL 8.0 och saknas i MariaDB, som ofta finns i alternativa byggen
• utf8mb4_unicode_ci fungerar överallt från och med MySQL 5.5.3 (2010)
• Skillnaden i sorteringskvalitet mellan unicode_ci och 0900_ai_ci är försumbar för en typisk WordPress-sajt
• Delade webbhotell använder ofta MySQL 5.7. Om du utvecklar lokalt med 0900_ai_ci men det saknas i produktion får du ett fel vid migrering

Om du med säkerhet vet att din produktionsserver kör MySQL 8.0+ och din lokala Laragon använder MySQL 8.0, kör på utf8mb4_0900_ai_ci. Detta är den moderna standard som rekommenderas av Oracle, med bättre stöd för flerspråkig sortering.

Hur är det med utf8_general_ci? Det var relevant för ungefär tio år sedan när utf8mb4 ännu inte hade brett stöd. Idag har det två fatala brister: det kan inte lagra emoji (WordPress använder dem aktivt i adminpanelen) och det sorterar utökade tecken felaktigt. Det finns ingen anledning att använda det 2026.

Video: hur du ändrar MySQL-databasens teckenkodning via phpMyAdmin

Textinstruktioner är bra, men ibland är det enklare att se det en gång. Den här 4-minutersvideon visar hela processen för att ändra teckenkodning för en befintlig databas via phpMyAdmin-gränssnittet, från att välja tabeller till den slutliga verifieringen:

⁉️🤔 Vanliga frågor

Jag har redan en databas med latin1_swedish_ci. Hur ändrar jag dess teckenkodning?

Det säkraste sättet är via phpMyAdmin. Välj databasen till vänster, gå till fliken "Operationer", välj utf8mb4_unicode_ci i blocket "Kollationering" och klicka på "Kör". phpMyAdmin genererar ALTER-frågor för varje tabell. Se till att skapa en säkerhetskopia före denna operation: fliken "Exportera" → SQL-format → "Kör".

Jag ändrade my.ini, startade om MySQL, men phpMyAdmin visar fortfarande latin1_swedish_ci. Vad är fel?

Tre vanligaste orsakerna: (1) raderna lades till i [client] istället för [mysqld]. Kontrollera under vilken hakparentessektion de ligger. (2) MySQL startade inte om. Öppna Windows Aktivitetshanteraren och verifiera att processen mysqld.exe försvann och dök upp igen. (3) Det finns flera [mysqld]-sektioner i my.ini. Detta händer ibland efter flera Laragon-uppdateringar. Behåll bara en.

Vad är bäst för WordPress: utf8mb4_unicode_ci eller utf8mb4_general_ci?

För WordPress är skillnaden minimal. utf8mb4_unicode_ci sorterar flerspråkigt innehåll mer exakt (till exempel tyska "ß" = "ss"), medan utf8mb4_general_ci är något snabbare på stora volymer, men skillnaden är i millisekunder. Välj unicode_ci och oroa dig inte mer.

Kan jag bara ange teckenkodningen i wp-config.php?

define('DB_CHARSET', 'utf8mb4') och define('DB_COLLATE', 'utf8mb4_unicode_ci') i wp-config.php påverkar ENDAST de tabeller som WordPress själv skapar under installationen. Serverns standard förblir oförändrad, och varje databas som skapas manuellt via phpMyAdmin kommer att få latin1_swedish_ci. Därför är det fortfarande nödvändigt att redigera my.ini.

Efter att ha ändrat teckenkodning blev en del text på sajten frågetecken. Går detta att ångra?

Ja, men du måste gå försiktigt fram. Frågetecken uppstår när data skrevs i latin1 men läses som utf8. Lösningen: exportera databasen med flaggan --default-character-set=latin1, importera sedan med --default-character-set=utf8mb4. Det exakta kommandot beror på din MySQL-version, så se den officiella dokumentationen.

Sammanfattning: vad du ska lägga till i my.ini just nu

Om du använder Laragon för lokal WordPress-utveckling kommer de två raderna nedan att lösa teckenkodningsproblemet en gång för alla:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Det här alternativet fungerar på alla MySQL-versioner från 5.5 till 8.4 och på alla aktuella MariaDB-byggen. Det lagrar kyrilliska tecken och emoji korrekt och skapar inga överraskningar när du migrerar databasen från lokal till produktion, oavsett vilket webbhotell som kör din produktionsserver.

Har du frågor om en specifik Laragon-version eller icke-standardkonfiguration? Kolla in tråden på Laragon-forumet, där utvecklare diskuterar nyanser kring teckenkodningskonfiguration, inklusive Docker-byggen och anpassade portar. Och om den här artikeln sparade dig en kväll, dela den med kollegor som också kämpar med latin1_swedish_ci.