Por que o acento da sua etiqueta vira caractere estranho

A etiqueta converte, o código de barras sai perfeito, e o nome do destinatário aparece assim:

endere□°o Jo□úo

Em vez de "endereço João". O ç virou um quadrado seguido de um símbolo, o ã virou outra coisa. Cada acento vira dois caracteres errados, sempre nos mesmos lugares.

Não é falha do conversor nem da impressora. É o arquivo dizendo uma coisa e querendo dizer outra.

Quando o sistema que gerou a etiqueta escreveu "endereço", ele gravou o ç como dois bytes, que é como o UTF-8 representa esse caractere. Até aí, tudo certo.

O problema é do outro lado. Sem instrução em contrário, o ZPL lê cada byte como um caractere de uma tabela antiga, de 256 posições, que não é UTF-8. Os dois bytes do ç são lidos como dois caracteres separados, e é exatamente isso que aparece impresso: dois símbolos onde deveria ter um.

Por isso o defeito é sempre o mesmo: todo acento vira dois caracteres, e texto sem acento nenhum sai perfeito. Se a sua etiqueta em inglês funciona e a em português não, é este o motivo.

O comando ^CI escolhe como o arquivo deve ser interpretado, e ^CI28 é o UTF-8. Ele vai uma vez por etiqueta, logo depois do ^XA:

^XA
^CI28
^FO50,50^A0N,30,30^FDendereço João^FS
^XZ

Com essa linha, a mesma etiqueta sai "endereço João". Testamos as duas versões contra o renderizador que o EasyZPL usa, e a diferença é essa linha só.

Precisa repetir em cada bloco ^XA … ^XZ. Num arquivo de cinquenta etiquetas, são cinquenta linhas, e é normal: cada etiqueta é independente das outras, de propósito.

Procurando pelo problema você vai achar gente recomendando ^CI13. Ele existe, é uma tabela de caracteres legítima, e não conserta este caso: testamos, e a etiqueta sai idêntica à que não tem ^CI nenhum.

A razão é simples. ^CI13 troca uma tabela de 256 posições por outra tabela de 256 posições, e o problema não é qual tabela: é que UTF-8 não cabe em 256 posições. Só ^CI28 muda a regra de leitura.

Sobra um caso, e ele é de origem: o ^CI28 diz como interpretar os bytes do arquivo, então ele não conserta um arquivo que foi gravado em outra codificação. Se o sistema que gerou a etiqueta salvou em Latin-1 ou Windows-1252, o acento já saiu errado de lá, e nenhum comando no arquivo desfaz isso.

Como saber qual dos dois casos é o seu: abra o arquivo num editor de texto que mostre a codificação (o Bloco de Notas mostra no canto, o VS Code também). Se o acento aparece certo no editor, o arquivo está em UTF-8 e falta o ^CI28. Se aparece errado já no editor, o problema está em quem gerou.

Nesse segundo caso a saída é pedir a correção a quem emite, ou, se for urgente, gerar a etiqueta sem acento. Endereço sem acento entrega; endereço com quadradinho às vezes não.