Criou uma base de dados no phpMyAdmin, instalou o WordPress e, uma semana depois, reparou que as tabelas mostravam texto ilegível em vez de caracteres normais. Abre as definições e vê latin1_swedish_ci. Quem trabalha com o Laragon no Windows acaba sempre por se deparar com esta surpresa.

O problema é que a versão do MySQL que o Laragon instala de origem herda um padrão antigo: latin1 como conjunto de caracteres e latin1_swedish_ci como collation. Para português, isto é um desastre: os caracteres acentuados aparecem como pontos de interrogação ou algaraviada, a ordenação de texto falha e os plugins rebentam com erros.

Abaixo estão duas alterações num único ficheiro que resolvem este problema de vez. Demora três minutos. Funciona no Laragon 6, 5 e até na antiga versão 4.

💡 Resumo rápido:

• Abra o my.ini pelo menu do Laragon e adicione duas linhas à secção [mysqld]
• Escolha utf8mb4_unicode_ci como a opção ideal para WordPress em 2026 (e explicamos porquê)
• Guarde o ficheiro, reinicie o MySQL e verifique o resultado no phpMyAdmin
• Bónus: como alterar a codificação de uma base de dados existente sem perder dados

Porque é que a codificação padrão é importante

O MySQL funciona com um sistema de herança a vários níveis: servidor → base de dados → tabela → coluna. Se latin1_swedish_ci estiver definido ao nível do servidor, cada nova base de dados herdará esse valor, a menos que seja especificado outro durante a criação.

Para o WordPress, isto é crítico porque:

• O core, os temas e a maioria dos plugins armazenam conteúdo em utf8mb4
• Ao criar automaticamente uma base de dados através do wp-config.php, o WordPress NÃO substitui o padrão do servidor
• Codificações desencontradas entre o servidor e as tabelas produzem erros «pouco claros»: ??? no painel de administração, caracteres partidos no JSON da REST API, falhas durante a exportação

De acordo com os dados da W3Techs, o WordPress alimenta 43,5% de todos os sites na internet, e o próprio CMS exige utf8mb4 desde a versão 4.2 para suporte completo a emojis. O Laragon é um dos servidores locais mais populares para Windows, mas a sua versão do MySQL vem com um padrão conservador para compatibilidade retroativa. Daí o conflito.

Passo 1: Abrir o my.ini pelo menu do Laragon

A forma mais fácil de aceder ao ficheiro de configuração do MySQL é através do menu integrado do Laragon:

• Clique com o botão direito no ícone do Laragon na bandeja do sistema
• Selecione Menu → MySQL → my.ini

O Notepad (ou o seu editor padrão) abrirá com a configuração completa do MySQL. O ficheiro está dividido em secções entre parêntesis retos: [client], [mysqld] e [mysqldump]. O que nos interessa é o [mysqld] (a secção de definições do daemon do MySQL).

Se, por algum motivo, o menu não abrir o ficheiro, localize-o manualmente: C:\laragon\bin\mysql\<version>\my.ini. Nas versões do Laragon 6, o caminho pode ser C:\laragon\bin\mysql\mysql-8.0.30-winx64\my.ini, dependendo da versão instalada.

Passo 2: Adicionar duas linhas à secção [mysqld]

Percorra até à secção [mysqld] e adicione as duas linhas seguintes no final (antes da próxima secção, se existir):

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

O que está a acontecer aqui:

• character_set_server = utf8mb4 indica ao servidor para usar a codificação UTF-8 Multilingual Version 4 por padrão, que suporta TODOS os caracteres Unicode, incluindo emojis, cirílico e hieróglifos
• collation_server = utf8mb4_unicode_ci define a regra de comparação de texto: _unicode_ significa «de acordo com o padrão Unicode», _ci significa comparação sem distinção entre maiúsculas e minúsculas (case-insensitive)

Tem de adicionar estas linhas especificamente ao [mysqld], não ao [client] ou ao [mysqldump]. Usar a secção errada é o motivo mais comum para «não ter mudado nada».

A secção completa após a edição deverá ficar mais ou menos assim:

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

Passo 3: Guardar o ficheiro e reiniciar o MySQL

Guarde o my.ini (Ctrl+S) e reinicie o MySQL. No Laragon, isto faz-se através do mesmo menu:

• Clique com o botão direito no ícone do Laragon na bandeja do sistema
• Menu → MySQL → Stop
• Aguarde 3 a 5 segundos
• Menu → MySQL → Start

Em alternativa, clique em Menu → Restart e o Laragon irá parar e iniciar todos os serviços de uma vez.

Após o reinício, as novas bases de dados serão criadas com utf8mb4_unicode_ci por padrão. As bases de dados existentes NÃO são alteradas automaticamente. Leia a secção «Perguntas frequentes» abaixo para saber como converter uma base de dados existente.

Passo 4: Verificar o resultado no phpMyAdmin

Abra o phpMyAdmin através do menu do Laragon (Menu → MySQL → phpMyAdmin) e crie uma base de dados de teste:

• Clique em «Criar base de dados»
• Introduza um nome qualquer
• Observe o menu suspenso «Collation»: deverá agora apresentar utf8mb4_unicode_ci por padrão

Se o menu suspenso ainda mostrar latin1_swedish_ci, verifique se as linhas character_set_server e collation_server foram adicionadas à secção [mysqld] (não à [client]) e se não existem espaços extra entre o nome do parâmetro e o sinal =.

Verificação rápida via consulta SQL (executar no phpMyAdmin no separador SQL):

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

Ambas as variáveis devem devolver utf8mb4 e utf8mb4_unicode_ci, respetivamente.

Que codificação escolher: comparação de opções

A codificação no MySQL acumulou muitos mitos, por isso vamos analisar três opções atuais e uma desatualizada:

Porque recomendamos utf8mb4_unicode_ci para desenvolvimento local no Laragon:

• O Laragon é distribuído com diferentes versões do MySQL (da 5.7 à 8.0+), e o utf8mb4_0900_ai_ci só apareceu no MySQL 8.0 e está ausente no MariaDB, que frequentemente vem em compilações alternativas
• O utf8mb4_unicode_ci funciona em todo o lado a partir do MySQL 5.5.3 (2010)
• A diferença na qualidade da ordenação entre unicode_ci e 0900_ai_ci é insignificante para um site WordPress típico
• Os planos de alojamento partilhado usam frequentemente MySQL 5.7. Se desenvolver localmente com 0900_ai_ci, mas este não existir em produção, terá um erro durante a migração

Se tiver a certeza de que o seu servidor de produção corre MySQL 8.0+ e o seu Laragon local usa MySQL 8.0, opte por utf8mb4_0900_ai_ci. Este é o padrão moderno recomendado pela Oracle, com melhor suporte para ordenação multilingue.

E quanto ao utf8_general_ci? Era relevante há cerca de dez anos, quando o utf8mb4 ainda não era amplamente suportado. Hoje tem duas falhas fatais: não consegue armazenar emojis (o WordPress usa-os ativamente no painel de administração) e ordena incorretamente caracteres especiais. Não há razão para o usar em 2026.

Vídeo: como alterar a codificação da base de dados MySQL através do phpMyAdmin

Instruções em texto são ótimas, mas às vezes é mais fácil ver uma vez. Este vídeo de 4 minutos mostra o processo completo de alteração da codificação de uma base de dados existente através da interface do phpMyAdmin, desde a seleção das tabelas até à verificação final:

⁉️🤔 Perguntas frequentes

Já tenho uma base de dados com latin1_swedish_ci. Como altero a codificação?

A forma mais segura é através do phpMyAdmin. Selecione a base de dados à esquerda, vá ao separador «Operações», escolha utf8mb4_unicode_ci no bloco «Collation» e clique em «Executar». O phpMyAdmin irá gerar consultas ALTER para cada tabela. Antes desta operação, certifique-se de que cria uma cópia de segurança: separador «Exportar» → formato SQL → «Executar».

Alterei o my.ini, reiniciei o MySQL, mas o phpMyAdmin ainda mostra latin1_swedish_ci. O que está errado?

Três causas mais comuns: (1) as linhas foram adicionadas ao [client] em vez do [mysqld]. Verifique em que secção de parêntesis retos estão. (2) O MySQL não reiniciou. Abra o Gestor de Tarefas do Windows e verifique se o processo mysqld.exe desapareceu e reapareceu. (3) Existem várias secções [mysqld] no my.ini. Isto acontece por vezes após várias atualizações do Laragon. Mantenha apenas uma.

O que é melhor para o WordPress: utf8mb4_unicode_ci ou utf8mb4_general_ci?

Para o WordPress, a diferença é mínima. O utf8mb4_unicode_ci ordena conteúdo multilingue com mais precisão (por exemplo, em alemão «ß» = «ss»), enquanto o utf8mb4_general_ci é ligeiramente mais rápido em grandes volumes, mas a diferença é de milissegundos. Escolha unicode_ci e não se preocupe mais com isso.

Posso simplesmente especificar a codificação no wp-config.php?

define('DB_CHARSET', 'utf8mb4') e define('DB_COLLATE', 'utf8mb4_unicode_ci') no wp-config.php afetam APENAS as tabelas que o próprio WordPress cria durante a instalação. O padrão do servidor permanece inalterado e qualquer base de dados criada manualmente através do phpMyAdmin receberá latin1_swedish_ci. É por isso que editar o my.ini continua a ser necessário.

Depois de alterar a codificação, algum texto no site transformou-se em pontos de interrogação. Isto é reversível?

Sim, mas é preciso proceder com cuidado. Os pontos de interrogação aparecem quando os dados foram escritos em latin1, mas estão a ser lidos como utf8. A solução: exportar a base de dados com a flag --default-character-set=latin1 e depois importar com --default-character-set=utf8mb4. O comando exato depende da sua versão do MySQL, por isso consulte a documentação oficial.

Resumo: o que adicionar ao my.ini agora mesmo

Se usa o Laragon para desenvolvimento local de WordPress, as duas linhas abaixo resolvem o problema de codificação de uma vez por todas:

1
character_set_server = utf8mb4
2
collation_server = utf8mb4_unicode_ci

Esta opção funciona em qualquer versão do MySQL, da 5.5 à 8.4, e em todas as compilações atuais do MariaDB. Armazena corretamente caracteres acentuados, emojis e não cria surpresas ao migrar a base de dados do ambiente local para produção, independentemente do alojamento onde o seu servidor de produção corre.

Tem dúvidas sobre uma versão específica do Laragon ou uma configuração não padrão? Consulte o tópico no fórum do Laragon, onde os programadores discutem nuances de configuração de codificação, incluindo compilações Docker e portas personalizadas. E se este artigo lhe poupou uma noite, partilhe-o com colegas que também estejam a lutar contra o latin1_swedish_ci.