Skip to content

Tutto per WordPress, lo sviluppo web — e non solo

🛠 Modifica della codifica MySQL in Laragon: da latin1_swedish_ci a utf8mb4_unicode_ci

🛠 Modifica della codifica MySQL in Laragon: da latin1_swedish_ci a utf8mb4_unicode_ci

Hai creato un database in phpMyAdmin, hai installato WordPress e una settimana dopo hai notato testo illeggibile invece di caratteri normali nelle tue tabelle. Apri le impostazioni e vedi latin1_swedish_ci. Chiunque lavori con Laragon su Windows prima o poi si imbatte in questa sorpresa.

Il problema è che la build di MySQL installata da Laragon di default eredita un'impostazione predefinita obsoleta: latin1 come set di caratteri e latin1_swedish_ci come collation. Per il russo è un disastro: i caratteri cirillici vengono scritti come punti interrogativi o sequenze senza senso, l'ordinamento delle stringhe si rompe e i plugin vanno in crash con errori.

Qui sotto trovi due modifiche in un unico file che risolvono il problema in modo definitivo. Servono tre minuti. Funziona su Laragon 6, 5 e persino sulla vecchia versione 4.

💡 Panoramica rapida:

  • Apri my.ini dal menu di Laragon e aggiungi due righe nella sezione [mysqld]
  • Scegli utf8mb4_unicode_ci come opzione ottimale per WordPress nel 2026 (e spieghiamo perché)
  • Salva il file, riavvia MySQL e verifica il risultato in phpMyAdmin
  • Extra: come cambiare la codifica di un database esistente senza perdere dati

Perché la codifica predefinita è importante

MySQL lavora con un sistema di ereditarietà a più livelli: server → database → tabella → colonna. Se a livello server è impostato latin1_swedish_ci, ogni nuovo database lo erediterà, a meno che non venga specificato diversamente in fase di creazione.

Per WordPress questo è critico perché:

  • Il core, i temi e la maggior parte dei plugin salvano i contenuti in utf8mb4
  • Quando crea automaticamente un database tramite wp-config.php, WordPress NON sovrascrive l'impostazione predefinita del server
  • Una codifica disallineata tra server e tabelle produce errori «poco chiari»: ??? nel pannello di amministrazione, caratteri corrotti nelle API REST JSON, crash durante l'esportazione

Secondo i dati W3Techs, WordPress alimenta il 43,5% di tutti i siti web e il CMS stesso richiede utf8mb4 dalla versione 4.2 per il supporto completo delle emoji. Laragon è uno dei server locali più diffusi per Windows, ma la sua build di MySQL viene distribuita con un default conservativo per retrocompatibilità. Da qui il conflitto.

Passo 1: apri my.ini dal menu di Laragon

Il modo più semplice per accedere al file di configurazione di MySQL è tramite il menu integrato di Laragon:

  • Clicca con il tasto destro sull'icona di Laragon nella barra delle applicazioni
  • Seleziona Menu → MySQL → my.ini
Menu di Laragon con opzione MySQL my.ini

Si aprirà Blocco note (o il tuo editor predefinito) con l'intera configurazione di MySQL. Il file è diviso in sezioni tra parentesi quadre: [client], [mysqld] e [mysqldump]. A noi interessa [mysqld] (la sezione delle impostazioni del demone MySQL).

Se per qualche motivo il menu non apre il file, cercalo manualmente: C:\laragon\bin\mysql\<version>\my.ini. Nelle build di Laragon 6, il percorso potrebbe essere C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini, a seconda della versione installata.

Passo 2: aggiungi due righe nella sezione [mysqld]

Scorri fino alla sezione [mysqld] e aggiungi le due righe seguenti alla fine (prima della sezione successiva, se presente):

1character_set_server = utf8mb4
2collation_server = utf8mb4_unicode_ci

Cosa succede qui:

  • character_set_server = utf8mb4 indica al server di usare la codifica UTF-8 Multilingual Version 4 come predefinita, che supporta TUTTI i caratteri Unicode, incluse emoji, cirillico e ideogrammi
  • collation_server = utf8mb4_unicode_ci imposta la regola di confronto tra stringhe: _unicode_ significa «secondo lo standard Unicode», _ci significa confronto case-insensitive

Devi aggiungere queste righe specificamente a [mysqld], non a [client] o [mysqldump]. Usare la sezione sbagliata è il motivo più comune per cui «non è cambiato nulla».

La sezione completa dopo la modifica dovrebbe apparire più o meno così:

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

Passo 3: salva il file e riavvia MySQL

Salva my.ini (Ctrl+S) e riavvia MySQL. In Laragon si fa dallo stesso menu:

  • Clicca con il tasto destro sull'icona di Laragon nella barra delle applicazioni
  • Menu → MySQL → Stop
  • Aspetta 3-5 secondi
  • Menu → MySQL → Start

In alternativa, clicca su Menu → Riavvia e Laragon fermerà e farà ripartire tutti i servizi in una volta sola.

Dopo il riavvio, i nuovi database verranno creati con utf8mb4_unicode_ci come impostazione predefinita. I database esistenti NON vengono modificati automaticamente. Leggi la sezione «Domande frequenti» qui sotto per sapere come convertire un database esistente.

Passo 4: verifica il risultato in phpMyAdmin

Apri phpMyAdmin dal menu di Laragon (Menu → MySQL → phpMyAdmin) e crea un database di test:

  • Clicca su «Crea database»
  • Inserisci un nome qualsiasi
  • Guarda il menu a tendina «Collation»: ora dovrebbe mostrare utf8mb4_unicode_ci come predefinito
Finestra di creazione database in phpMyAdmin con codifica utf8_general_ci

Se il menu a tendina mostra ancora latin1_swedish_ci, verifica che le righe character_set_server e collation_server siano state aggiunte alla sezione [mysqld] (non [client]) e che non ci siano spazi extra tra il nome del parametro e il segno =.

Verifica rapida tramite query SQL (da eseguire in phpMyAdmin nella scheda SQL):

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

Entrambe le variabili devono restituire rispettivamente utf8mb4 e utf8mb4_unicode_ci.

Quale codifica scegliere: confronto tra le opzioni

Sulle codifiche di MySQL si sono accumulati molti miti, perciò analizziamo tre opzioni attuali e una obsoleta:

Codifica

Versione MySQL

Emoji

Ordinamento

Compatibilità

Verdetto

utf8_general_ci

Qualsiasi

❌ No

Semplificato, veloce

Massima

Obsoleta, non usare

utf8mb4_unicode_ci

5.5.3+

✅ Sì

Standard Unicode (UCA 4.0)

Eccellente

Consigliata per Laragon

utf8mb4_0900_ai_ci

8.0+

✅ Sì

UCA 9.0, AI (accent-insensitive)

Solo MySQL 8+

Standard moderno, ma supporto limitato

utf8mb4_general_ci

5.5.3+

✅ Sì

Semplificato

Eccellente

Compromesso tra velocità e accuratezza

Perché consigliamo utf8mb4_unicode_ci per lo sviluppo locale in Laragon:

  • Laragon viene distribuito con diverse versioni di MySQL (dalla 5.7 alla 8.0+) e utf8mb4_0900_ai_ci è apparso solo in MySQL 8.0 ed è assente in MariaDB, che spesso si trova nelle build alternative
  • utf8mb4_unicode_ci funziona ovunque a partire da MySQL 5.5.3 (2010)
  • La differenza nella qualità dell'ordinamento tra unicode_ci e 0900_ai_ci è trascurabile per un tipico sito WordPress
  • I piani di hosting condiviso usano spesso MySQL 5.7. Se sviluppi in locale con 0900_ai_ci ma questo manca in produzione, otterrai un errore durante la migrazione

Se sai con certezza che il tuo server di produzione gira con MySQL 8.0+ e il tuo Laragon locale usa MySQL 8.0, scegli utf8mb4_0900_ai_ci. Questo è lo standard moderno raccomandato da Oracle, con un supporto migliore per l'ordinamento multilingue.

E utf8_general_ci? Era rilevante una decina di anni fa, quando utf8mb4 non era ancora ampiamente supportato. Oggi ha due difetti fatali: non può memorizzare le emoji (WordPress le usa attivamente nel pannello di amministrazione) e ordina in modo errato i caratteri estesi. Non c'è motivo di usarla nel 2026.

Video: come cambiare la codifica del database MySQL tramite phpMyAdmin

Le istruzioni testuali sono ottime, ma a volte è più facile vedere una volta come si fa. Questo video di 4 minuti mostra il processo completo per cambiare la codifica di un database esistente tramite l'interfaccia di phpMyAdmin, dalla selezione delle tabelle alla verifica finale:

⁉️🤔 Domande frequenti

Ho già un database con latin1_swedish_ci. Come cambio la sua codifica?

Il modo più sicuro è tramite phpMyAdmin. Seleziona il database a sinistra, vai nella scheda «Operazioni», scegli utf8mb4_unicode_ci nel blocco «Collation» e clicca su «Esegui». phpMyAdmin genererà le query ALTER per ogni tabella. Prima di questa operazione, assicurati di creare un backup: scheda «Esporta» → formato SQL → «Esegui».

Ho modificato my.ini, riavviato MySQL, ma phpMyAdmin mostra ancora latin1_swedish_ci. Cosa c'è che non va?

Tre cause più comuni: (1) le righe sono state aggiunte a [client] invece che a [mysqld]. Controlla sotto quale sezione tra parentesi quadre si trovano. (2) MySQL non si è riavviato. Apri Task Manager di Windows e verifica che il processo mysqld.exe sia scomparso e riapparso. (3) Ci sono più sezioni [mysqld] in my.ini. Questo a volte succede dopo diversi aggiornamenti di Laragon. Tienine solo una.

Cosa è meglio per WordPress: utf8mb4_unicode_ci o utf8mb4_general_ci?

Per WordPress la differenza è minima. utf8mb4_unicode_ci ordina i contenuti multilingue in modo più accurato (ad esempio, il tedesco «ß» = «ss»), mentre utf8mb4_general_ci è leggermente più veloce su grandi volumi, ma la differenza è nell'ordine dei millisecondi. Scegli unicode_ci e non pensarci più.

Posso semplicemente specificare la codifica in wp-config.php?

define('DB_CHARSET', 'utf8mb4') e define('DB_COLLATE', 'utf8mb4_unicode_ci') in wp-config.php influenzano SOLO le tabelle che WordPress stesso crea durante l'installazione. L'impostazione predefinita del server rimane invariata e qualsiasi database creato manualmente tramite phpMyAdmin riceverà latin1_swedish_ci. Ecco perché modificare my.ini è comunque necessario.

Dopo aver cambiato la codifica, alcuni testi sul sito sono diventati punti interrogativi. È reversibile?

Sì, ma bisogna procedere con cautela. I punti interrogativi compaiono quando i dati sono stati scritti in latin1 ma vengono letti come utf8. La soluzione: esporta il database con il flag --default-character-set=latin1, poi importa con --default-character-set=utf8mb4. Il comando esatto dipende dalla tua versione di MySQL, quindi consulta la documentazione ufficiale.

Riepilogo: cosa aggiungere subito a my.ini

Se usi Laragon per lo sviluppo locale di WordPress, le due righe qui sotto risolveranno il problema di codifica una volta per tutte:

1character_set_server = utf8mb4
2collation_server = utf8mb4_unicode_ci

Questa opzione funziona su qualsiasi versione di MySQL dalla 5.5 alla 8.4 e su tutte le build attuali di MariaDB. Memorizza correttamente il cirillico, le emoji e non crea sorprese quando si migra il database dal locale alla produzione, indipendentemente dall'hosting su cui gira il server di produzione.

Hai domande su una versione specifica di Laragon o su una configurazione non standard? Dai un'occhiata al thread sul forum di Laragon, dove gli sviluppatori discutono le sfumature della configurazione della codifica, incluse le build Docker e le porte personalizzate. E se questo articolo ti ha risparmiato una serata di lavoro, condividilo con i colleghi che stanno ancora lottando con latin1_swedish_ci.