Por qué las tildes de tu etiqueta salen como caracteres raros
Una dirección con ñ o á sale como un cuadradito y un símbolo suelto. La causa es una línea que falta en el archivo, y la corrección ocupa cinco caracteres.
El síntoma
La etiqueta se convierte, el código de barras sale perfecto, y el nombre del destinatario aparece así:
endere□°o Jo□úoEn lugar de "endereço João". La ç se convirtió en un cuadrado seguido de un símbolo, la ã en otra cosa. Cada carácter con tilde se convierte en dos caracteres equivocados, siempre en los mismos sitios.
No es culpa del conversor ni de la impresora. Es el archivo diciendo una cosa y queriendo decir otra.
La causa: ZPL no da por hecho que el archivo es UTF-8
Cuando el sistema que generó la etiqueta escribió "endereço", guardó la ç como dos bytes, que es como UTF-8 representa ese carácter. Hasta ahí, todo bien.
El problema está en el otro lado. Sin instrucción en contra, ZPL lee cada byte como un carácter de una tabla antigua de 256 posiciones que no es UTF-8. Los dos bytes de la ç se leen como dos caracteres separados, y eso es justo lo que se imprime: dos símbolos donde debería haber uno.
Por eso el defecto tiene siempre la misma forma: cada carácter acentuado se convierte en dos, y el texto sin tildes sale perfecto. Si tus etiquetas en inglés funcionan y las que llevan ñ o tilde no, este es el motivo.
La corrección: ^CI28 justo después del ^XA
El comando ^CI elige cómo debe interpretarse el archivo, y ^CI28 es UTF-8. Va una vez por etiqueta, justo después del ^XA:
^XA
^CI28
^FO50,50^A0N,30,30^FDendereço João^FS
^XZCon esa línea, la misma etiqueta sale "endereço João". Renderizamos las dos versiones contra el renderizador que usa EasyZPL, y esa única línea es toda la diferencia.
Hay que repetirlo en cada bloque ^XA … ^XZ. En un archivo de cincuenta etiquetas son cincuenta líneas, y es lo normal: cada etiqueta es independiente de las demás, a propósito.
^CI13 no lo arregla, digan lo que digan los foros
Al buscar este problema aparece gente recomendando ^CI13. Existe, es una tabla de caracteres legítima, y no arregla este caso: lo probamos, y la etiqueta sale idéntica a una sin ningún ^CI.
La razón es sencilla. ^CI13 cambia una tabla de 256 posiciones por otra tabla de 256 posiciones, y el problema no es qué tabla: es que UTF-8 no cabe en 256 posiciones. Solo ^CI28 cambia la regla de lectura.
Si el ^CI28 no lo resolvió
Queda un caso, y viene de origen: el ^CI28 dice cómo interpretar los bytes del archivo, así que no repara un archivo guardado en otra codificación. Si el sistema que generó la etiqueta la guardó en Latin-1 o Windows-1252, la tilde ya salió mal de allí, y ningún comando dentro del archivo deshace eso.
Cómo saber cuál de los dos casos es el tuyo: abre el archivo en un editor que muestre la codificación (VS Code la muestra en la barra de estado). Si las tildes se ven bien en el editor, el archivo es UTF-8 y solo falta el ^CI28. Si se ven mal también ahí, el problema es de quien lo generó.
En ese segundo caso la salida es pedir la corrección a quien emite o, si corre prisa, generar la etiqueta sin tildes. Una dirección sin tildes se entrega; una dirección llena de cuadraditos a veces no.