ZPL druckt Sonderzeichen falsch

Veröffentlicht: 2026-08-26 · Aktualisiert: 2026-10-08

Aus Ö wird Ö, aus ü wird ü, ein ß zerfällt in zwei Müllzeichen. Die Daten sind im System richtig, in der Datei richtig — und auf dem Etikett falsch. Das ist keine Beschädigung; zwei Seiten dekodieren dieselben Bytes mit verschiedenen Tabellen.

Was mit den Bytes tatsächlich passiert

Moderne Systeme schreiben Text als UTF-8; ein Ö sind dort zwei Bytes. Ein Zebra-Drucker ohne Anweisung dekodiert ^FD-Daten mit seiner alten Standard-Codepage — jedes Byte ein Zeichen — und druckt die zwei Bytes als zwei falsche Zeichen. Die Signatur ist eindeutig: Jeder Umlaut wird zu einem Zweierpärchen, das nackte ASCII drumherum bleibt perfekt.

Die Lösung: UTF-8 mit ^CI28 deklarieren

Setzen Sie ^CI28 einmal an den Anfang des Formats, vor das erste ^FD. Es weist den Drucker an, Felddaten als UTF-8 zu dekodieren — dieselbe Annahme, die Ihr System längst trifft. Andere numerische ^CI-Werte wählen Ein-Byte-Tabellen und ändern nur einzelne Positionen; für echten mehrsprachigen Text ist 28 der Wert, der zu dem passt, was Sie senden.

^XA
^CI28
^FO50,50^A0N,40,40^FDGrößenprüfung — Müllerstraße^FS
^XZ

Dieses Etikett im ZPL-Viewer öffnen →

Warum die Vorschau stimmt und der Drucker nicht

Ein ehrliches Detail zum Testen am Bildschirm: Eine Browser-Vorschau (unsere eingeschlossen) nimmt durchgehend UTF-8 an — eine Datei ohne ^CI28 kann in der Vorschau perfekt aussehen und auf einem Drucker mit alter Standard-Codepage trotzdem Zeichensalat drucken. Die Strukturprüfung warnt deshalb bei numerischem ^CI ungleich 28; das Fehlen von ^CI28 prüft man vor dem Senden mehrsprachigen Texts mit bloßem Auge.

Zweite Ebene: die Schrift braucht die Glyphe

Das Encoding liefert den richtigen Zeichencode; die Schrift muss dann die Form des Zeichens enthalten. Eingebaute Druckerschriften decken lateinische Alphabete gut ab, aber nicht alles. Druckt ein korrekt kodiertes Zeichen als Lücke oder Kästchen, laden Sie eine TTF mit der Glyphe (~DU) und rufen sie mit ^A@ auf — das Etikett trägt dann seine eigene Schrift, statt auf den Drucker zu hoffen.

Steuerzeichen: ^FH

Für Bytes, die sich nicht tippen lassen — oder wenn eine Integration rohe High-Bit-Bytes unterwegs verstümmelt — schaltet ^FH das Feld auf Hex-Escapes: ^FH^FD_C3_96^FS druckt Ö per Wert. Das ist der robuste Weg für generierte Dateien, wenn ein Zwischensystem UTF-8-Bytes nicht verlässlich bewahrt.

Dritte Ebene: Treiber und Werkzeugkette

Steht ^CI28 in der Datei und hat die Schrift die Glyphe, kann das Zeichen trotzdem zwischen Ihrem Programm und dem Kopf sterben. Drei Stellen, in der Reihenfolge, in der man sie meist findet:

• Ein generischer Windows-Treiber. Zebras eigener Support-Hinweis sagt, der generische Texttreiber reicht ^CI nicht durch und ist nicht UTF-8-sicher; Fragezeichen nach ^CI28 in einem über den Treiber gedruckten Job sind genau das. Senden Sie das ZPL stattdessen roh — an Port 9100 (ZPL an einen Netzwerkdrucker senden), über die Zebra Setup Utilities oder den ZPL-Treiber im Durchreichmodus — oder weichen Sie auf ^FH-Hex-Escapes aus, die jeden Treiber überleben, weil jedes Byte reines ASCII ist.
• Eine geladene Schrift, die der Text nie benutzt. ^CW weist der TTF einen Buchstaben zu (^CWR,E:ARIAL.TTF); sagen die Felder weiter ^A0N, zeichnet der Drucker mit Schrift 0 und deren fehlenden Glyphen, nicht mit der geladenen. Das Feld muss dieselbe Kennung aufrufen (^ARN,40,40) — der Ratgeber zu eigenen Schriften führt durch Laden und Aufrufen, der Schriftinspektor listet, auf welche Schrift jedes Feld tatsächlich aufgelöst wird.
• Eine Datei, die kein UTF-8 ist. Ein Editor, der als ANSI oder Windows-1252 speichert, schreibt für ö, ü, ß einzelne Bytes; ^CI28 dekodiert sie als kaputte Mehrbyte-Folgen. Als UTF-8 ohne BOM speichern und die Bytes prüfen (ö muss C3 B6 sein), bevor Sie den Drucker beschuldigen.

Passende Prüfregel

Die Vorschau setzt UTF-8 voraus; der Bildschirm kann stimmen, während das Papier falsch ist. Unser Linter markiert Nicht-ASCII-Text in einem Etikett ganz ohne ^CI-Befehl: Die Regel ZPL5004 zeigt ein Beispiel und die Lösung.

Häufig gestellte Fragen

Warum drucken Umlaute als zwei Müllzeichen?

Ihr System sendet UTF-8; ein Umlaut sind dort zwei Bytes. Ein Drucker ohne Anweisung dekodiert sie mit einer Ein-Byte-Codepage und druckt zwei falsche Zeichen. Setzen Sie ^CI28 an den Formatanfang, vor das erste ^FD.

Warum stimmt die Vorschau, aber der Drucker nicht?

Eine Browser-Vorschau nimmt durchgehend UTF-8 an; eine Datei ohne ^CI28 kann am Bildschirm perfekt aussehen und auf Hardware mit alter Standard-Codepage trotzdem Zeichensalat drucken. Vor dem Senden mehrsprachigen Texts auf ^CI28 prüfen.

^CI28 ist gesetzt, ein Zeichen druckt trotzdem als Kästchen?

Das Encoding liefert den Zeichencode; die Schrift muss die Glyphe enthalten. Eine TTF mit der Glyphe per ~DU laden und mit ^A@ aufrufen — das Etikett trägt seine eigene Schrift, statt sich auf die eingebauten zu verlassen.

Ich habe ^CI28 eingefügt und bekomme trotzdem Fragezeichen — warum?

Drei übliche Gründe: Der Job läuft über einen generischen Windows-Treiber, der ^CI nicht durchreicht (ZPL roh senden oder ^FH-Hex-Escapes verwenden); der Text ruft weiter Schrift 0 auf, während der geladenen Schrift per ^CW ein anderer Buchstabe zugewiesen wurde; oder die Datei wurde als ANSI/Windows-1252 statt UTF-8 gespeichert.

Verwandte Ratgeber

Eigenen ZPL-Code testen →