Byte-Längen-Zähler nach Kodierung

Misst, wie viele Bytes Ihr Text in UTF-8, Shift_JIS, EUC-JP, UTF-16 und JIS (ISO-2022-JP) belegt. Nützlich zur Überprüfung von Datenbankspaltenlimits und Grenzwerten alter Formulare.

Tipps

  • In UTF-8 belegen halbbreite alphanumerische Zeichen jeweils 1 Byte, während japanische Zeichen (Hiragana, Katakana, Kanji) meist 3 Bytes belegen. Dieselbe Zeichenanzahl kann daher bei englischem und japanischem Text sehr unterschiedliche Byte-Zahlen ergeben.
  • Ältere Systeme mit byte-basierten Limits auf Spalten wie VARCHAR(255) erreichen ihre Obergrenze bei japanischem Text viel schneller als bei englischem Text gleicher Zeichenlänge.
  • Die meisten Emojis werden durch ein Surrogatpaar aus zwei Codeeinheiten dargestellt und belegen sowohl in UTF-8 als auch in UTF-16 jeweils 4 Bytes — deshalb erreichen Zeichenzähler in sozialen Netzwerken ihr Limit manchmal früher als erwartet.
  • Wenn Sie bereits eine Byte-Zahl kennen und diese in KB, MB oder andere Einheiten umrechnen möchten, nutzen Sie unser Schwestertool „Byte-Einheiten-Umrechner" — dieses Tool übernimmt die umgekehrte Berechnung von Text zu Byte-Zahl.

Häufig gestellte Fragen

Die Zeichenlänge zählt, wie viele sichtbare Zeichen in einer Zeichenkette stehen, während die Byte-Länge angibt, wie viele Bytes (Oktette) zum Speichern oder Übertragen dieser Zeichenkette als Computerdaten nötig sind. Bei reinem ASCII-Text stimmen beide Werte überein, bei Text mit Mehrbyte-Zeichen wie Japanisch kann die Byte-Länge jedoch um ein Vielfaches größer sein als die Zeichenlänge.

UTF-8 verwendet eine variable Kodierung von 1 bis 4 Bytes pro Zeichen, wobei die meisten japanischen Zeichen (Hiragana, Katakana, gebräuchliche Kanji) 3 Bytes belegen. Shift_JIS hingegen kodiert die meisten japanischen Zeichen mit 2 Bytes, sodass derselbe japanische Text in UTF-8 in der Regel mehr Platz benötigt als in Shift_JIS.

Das hängt von der Datenbank-Engine und den Zeichensatzeinstellungen der Spalte ab. MySQLs VARCHAR(n) ist grundsätzlich auf „n Zeichen" begrenzt, es gibt aber auch separate interne byte-basierte Grenzwerte (z. B. die maximale indizierbare Schlüssellänge), weshalb Text mit Emojis manchmal Fehler auslösen kann. Prüfen Sie das genaue Verhalten in der Dokumentation Ihres jeweiligen DBMS.

Halbbreite alphanumerische Zeichen und Symbole belegen in UTF-8, Shift_JIS und EUC-JP gleichermaßen nur 1 Byte, während vollbreite Zeichen (Hiragana, Katakana, Kanji, vollbreite Symbole) je nach Kodierung 2 bis 3 Bytes belegen. Eine Zeichenkette mit 10 Zeichen kann nur 10 Bytes benötigen, wenn alle halbbreit sind, oder 20 bis 30 Bytes, wenn alle vollbreit sind.

Dieses Tool nimmt eine Textzeichenkette als Eingabe und berechnet deren Byte-Länge für jede Kodierung. Das Tool „Byte-Einheiten-Umrechner" nimmt hingegen eine bereits bekannte Byte-Zahl (z. B. 1.500.000 Bytes) und rechnet sie in Einheiten wie KB, MB oder GB um. Verwenden Sie dieses Tool, wenn Sie von „Text zu Byte-Zahl" möchten, und das andere Tool, wenn Sie von „Byte-Zahl zu anderen Einheiten" möchten.
ツールくん

Übrigens – Der versteckte Zusammenhang zwischen Zeichenlimits in sozialen Netzwerken und Byte-Zahlen

Ältere Versionen des MySQL-Zeichensatzes „utf8" hatten eine überraschende Einschränkung: Sie konnten eigentlich keine Unicode-Emojis speichern (ergänzende Zeichen ab U+10000). UTF-8 selbst ist eine variable Kodierung, die bis zu 4 Bytes pro Zeichen unterstützt, aber das MySQL-„utf8" war historisch auf 3 Bytes pro Zeichen begrenzt, was beim Speichern von Text mit Emojis zu INSERT-Fehlern führte. Die Migration zu „utf8mb4", das den vollen 4-Byte-Bereich korrekt unterstützt, gilt heute als empfohlene Lösung — ein bekanntes Beispiel dafür, warum das Verständnis der Beziehung zwischen Zeichenkodierung und Byte-Zahl in der Praxis tatsächlich wichtig ist.

Als Twitter (heute X) sein berühmtes 140-Zeichen-Limit durchsetzte, gab es eine lange Debatte über die Fairness zwischen Sprachen: Japanische Nutzer konnten mit 140 Zeichen einen recht vollständigen Gedanken ausdrücken, während englischsprachige Nutzer im selben Limit kaum 20 bis 30 Wörter unterbrachten. Das liegt daran, dass ein einzelnes japanisches Kanji-Zeichen weitaus mehr Information trägt als ein einzelner englischer Buchstabe. Twitter führte schließlich ein gewichtetes Zählsystem ein, bei dem Sprachen wie Japanisch als „1 Zeichen = 1 Zähleinheit" galten, während bei anderen Sprachen bestimmte Zeichen als „2 Bytes = 1 Zähleinheit" gezählt wurden, um die Waage zwischen den Sprachen auszugleichen.

Auch bei SMS auf Mobiltelefonen gibt es eine ähnliche Eigenheit. Eine im GSM-Standard kodierte SMS erlaubt bis zu 160 Zeichen pro Nachricht, doch sobald auch nur ein einziges Zeichen außerhalb des 7-Bit-GSM-Zeichensatzes enthalten ist — etwa ein Emoji oder ein japanisches Zeichen —, wechselt die Kodierung zu UCS-2 (ungefähr gleichwertig mit UTF-16), und das Limit sinkt schlagartig auf nur noch 70 Zeichen. Dass ein einziges japanisches Zeichen die verfügbare Nachrichtenlänge auf weniger als die Hälfte reduzieren kann, ist ein perfektes reales Beispiel für genau den Zusammenhang zwischen Zeichenkodierung und Byte-Zahl, den dieses Tool messen soll.