Byte-Zähler

So funktioniert's

1. Text eingeben oder einfügen: Geben Sie einen beliebigen Text in das Eingabefeld ein oder fügen Sie ihn ein.
2. Byte-Anzahl anzeigen: Das Tool zeigt sofort die Byte-Anzahl in UTF-8, UTF-16, ASCII und anderen Kodierungen nebeneinander an.
3. Limits prüfen: Vergleichen Sie die Byte-Anzahl mit gängigen Limits (SMS: 160 Zeichen, HTTP-Header: 8 KB, Datenbankfelder usw.), um zu sehen, ob Ihr Inhalt passt.

Warum Byte-Zähler verwenden?

Zeichenanzahl und Byte-Anzahl sind nicht dasselbe. Ein einzelnes Emoji kann in UTF-8 4 Bytes groß sein. Chinesische und arabische Zeichen benötigen jeweils 2-3 Bytes. Viele Systeme erzwingen Byte-Limits, keine Zeichen-Limits, darunter MySQL VARCHAR-Felder, Redis-Werte, HTTP-Header, SMS-Nachrichten und Cloud-Speicher-Objektnamen. Der Byte-Zähler zeigt die tatsächliche Byte-Größe Ihres Textes in jeder Kodierung an, damit Sie innerhalb der Systembeschränkungen bleiben.

Funktionen

• Mehrere Kodierungsgrößen: Zeigt Byte-Anzahl für UTF-8, UTF-16 LE/BE, UTF-32 und Latin-1 an.
• Zeichen-Aufschlüsselung: Zählt Gesamtzeichen, Unicode-Codepoints und Multi-Byte-Zeichen separat.
• Voreinstellungen für gängige Limits: Vergleichen Sie mit SMS (160), Tweet (280), Meta-Beschreibung (160), MySQL VARCHAR-Limits und mehr.
• Live-Updates: Die Byte-Anzahl wird in Echtzeit aktualisiert, während Sie tippen.
• Kodierungs-Vergleich: Sehen Sie, welche Kodierung für Ihren spezifischen Text am kompaktesten ist.

Häufig gestellte Fragen

Warum ist meine Byte-Anzahl größer als meine Zeichenanzahl?

Viele Zeichen benötigen in UTF-8 mehr als 1 Byte. ASCII-Zeichen (A-Z, 0-9, Satzzeichen) sind jeweils 1 Byte. Lateinisch erweiterte Zeichen (Buchstaben mit Akzent) sind 2 Bytes. Chinesische, japanische, koreanische und arabische Zeichen sind typischerweise 3 Bytes. Emojis sind normalerweise 4 Bytes.

Welche Kodierung verwenden die meisten Web-Systeme?

UTF-8 ist die dominierende Kodierung für Webinhalte, APIs, JSON und Datenbanken. MySQL und PostgreSQL verwenden standardmäßig UTF-8. Verwenden Sie beim Prüfen von Byte-Limits die UTF-8-Spalte, sofern Ihr System nichts anderes angibt.

Warum haben SMS-Nachrichten ein Limit von 160 Zeichen?

Traditionelle SMS verwenden die 7-Bit-GSM-Kodierung, die 160 Zeichen pro Segment erlaubt. Wenn Sie ein Nicht-GSM-Zeichen (wie ein typografisches Anführungszeichen, ein Emoji oder einen nicht-lateinischen Buchstaben) einfügen, wechselt die Nachricht zur UCS-2-Kodierung, wodurch das Limit auf 70 Zeichen pro Segment sinkt.

Was ist ein Byte eigentlich?

Ein Byte sind 8 Bit, die 256 verschiedene Werte aufnehmen können. In Text werden diese 256 Werte über eine Codierung Zeichen zugeordnet, ein Regelwerk, das sagt „diese Bytefolge entspricht diesem Zeichen“. Dieselbe Bytefolge kann unter verschiedenen Codierungen völlig unterschiedlichen Text bedeuten: das Byte 0xE9 ist „é“ in Latin-1, der Anfang einer 3-Byte-Sequenz in UTF-8 oder Teil einer UTF-16-Code-Einheit. Die Codierung ist die ganze Geschichte.

Wenn Sie Text auf der Festplatte speichern, über das Netzwerk senden oder in einer Datenbank ablegen, wird tatsächlich in Bytes gespeichert, nicht in Zeichen. Die Zeichenzahl, die Sie in einem Texteditor sehen, wird zum Anzeigezeitpunkt berechnet, nachdem die Bytes decodiert wurden. Stimmt die Codierung auf beiden Seiten nicht überein, erhalten Sie Mojibake: Text, der mit der falschen Codierung decodiert wird, erscheint als Kauderwelsch (das klassische é statt é, wenn Windows-1252-Bytes als UTF-8 gelesen werden).

Byte-Zählung ist das, was Datenbankspaltenlimits, HTTP-Header-Puffer, SMS-Nutzlasten und Cloud-Storage-Objektschlüssel alle messen, unabhängig davon, wie der Text „aussieht“. Dieser Zähler meldet die Bytegröße in den vier Codierungen, die Sie am ehesten interessieren werden: UTF-8 (der moderne Standard), UTF-16 (das interne Format von Windows / Java / JavaScript), ASCII (nur gültig für englischen lateinischen Text) und Latin-1 (ein veraltetes Ein-Byte-Fallback). Die Zeichenzahl daneben dient als Referenz.

UTF-8: Die Geschichte

UTF-8 wurde von Ken Thompson und Rob Pike in den Bell Labs in der Nacht vom 2. September 1992 skizziert, angeblich auf einem Platzdeckchen in einem Diner in New Jersey, nachdem das Plan-9-Team eine ASCII-kompatible Codierung variabler Länge für Unicode benötigte. Das Design trägt drei Eigenschaften, die fast nichts anderes gleichzeitig hat: ASCII-Text ist auch gültiges UTF-8 (1 Byte pro Zeichen, identische Bytes), die Codierung ist selbstsynchronisierend (die hohen Bits jedes Bytes sagen Ihnen, ob es ein neues Zeichen beginnt oder ein bestehendes fortsetzt), und es gibt keine Byte-Reihenfolge-Mehrdeutigkeit. Diese drei Eigenschaften zusammen erklären, warum UTF-8 alle konkurrierenden Codierungen im Web verdrängt hat.

Es wurde zuerst als RFC 2044 im Oktober 1996 standardisiert, als RFC 2279 im Januar 1998 überarbeitet und durch das aktuelle RFC 3629 (November 2003) ersetzt, das UTF-8 auf 4 Bytes pro Zeichen beschränkte, um Unicodes endgültiger Codepunktobergrenze bei U+10FFFF zu entsprechen. W3Techs verfolgt die Nutzung von Codierungen im öffentlichen Web seit 2010 kontinuierlich; UTF-8 stieg von 56 % der Websites im Jahr 2011 auf etwa 98 % im Jahr 2026. Die HTML5-Spezifikation schreibt UTF-8 für neue Inhalte vor; HTTP/2 und HTTP/3 senden Header in UTF-8 über HPACK / QPACK; RFC 8259 schreibt UTF-8 für JSON-Austausch zwischen Systemen vor. Wenn Sie eine Codierung für alles wählen müssen, lautet die Antwort der letzten 15 Jahre UTF-8, und die Antwort für die nächsten 15 wird dieselbe sein.

UTF-8 hat variable Länge, 1 bis 4 Bytes pro Zeichen:

Praktische Konsequenz: Englischer Text in UTF-8 hat durchschnittlich ~1 Byte pro Zeichen; Chinesisch ~3 Bytes; eine emoji-lastige Nachricht kann 4 Bytes pro sichtbarem Zeichen erreichen, und kombinierte Emoji (ZWJ-Familiensequenzen) erreichen leicht 20-30 Bytes für das, was wie ein einziges Zeichen aussieht.

UTF-16 und die Surrogate-Falle

UTF-16 war die Codierung der Wahl für Windows NT (1993), Java 1.0 (1996), JavaScript (1995), .NET und Mac OS X Cocoa NSString. Es verwendet 2 Bytes für jedes Zeichen in der Basic Multilingual Plane (U+0000 – U+FFFF) und Surrogate-Paare für alles außerhalb davon: ein High-Surrogate (D800–DBFF) plus ein Low-Surrogate (DC00–DFFF), insgesamt 4 Bytes. UTF-16 benötigt auf der Festplatte eine Byte-Reihenfolge-Markierung (BOM), um Big-Endian (UTF-16BE, FE FF) von Little-Endian (UTF-16LE, FF FE) zu unterscheiden; Windows verwendet standardmäßig Little-Endian.

Die Falle: in JavaScript ist "😀".length === 2. MDN sagt es direkt: die Eigenschaft length „enthält die Länge der Zeichenkette in UTF-16-Code-Einheiten“. Deshalb meldet ein einzelnes Emoji wie 😄 eine Länge von 2 (es lebt in der ergänzenden Ebene und braucht ein Surrogate-Paar), und die ZWJ-Familiensequenz 👨‍👩‍👧‍👦 meldet eine Länge von 11 (vier 2-Code-Einheiten-Emoji plus drei Nullbreiten-Verbinder). Dasselbe Ein-Zeichen-Familienemoji zählt als 11 in JavaScript, 5 in Python 3 und 1 in Swift, je nach dem Zeichenkettenmodell jeder Sprache. Für korrekte sichtbare Zeichenzählungen in JavaScript verwenden Sie Intl.Segmenter mit Grapheme-Granularität (jeder Evergreen-Browser seit 2021).

ASCII, Latin-1 und das Vor-Unicode-Durcheinander

ASCII (American Standard Code for Information Interchange) wurde als ASA X3.4-1963 standardisiert, als X3.4-1968 überarbeitet und erneut als ANSI X3.4-1986. Ein 7-Bit-Code, 128 Zeichen: 95 druckbare plus 33 Steuerzeichen. Die 33 Steuerzeichen umfassen Fernschreiber-Erbe wie BEL, BS, CR, LF, DEL und einige, die in modernen Protokollen überleben (NUL, TAB, LF, CR, ESC). ASCII funktioniert immer noch als strikte Teilmenge von UTF-8, weshalb „reiner ASCII-Text“ auch gültiges UTF-8 ist und warum die Migration zu UTF-8 für nur englischsprachige Systeme schmerzlos war.

Latin-1 / ISO-8859-1 (1987) war eine 256-Zeichen-Ein-Byte-Erweiterung, die akzentuierte westeuropäische Buchstaben, Währungssymbole und gängige Satzzeichen hinzufügte. Es war die De-facto-Codierung für westliche Web-Inhalte von 1995 bis UTF-8 sie um 2008 verdrängte. Windows-1252 ist Microsofts Obermenge von Latin-1, die „typografische Anführungszeichen“, Geviertstriche und das Euro-Symbol im C1-Steuerbereich (0x80-0x9F) hinzufügt; wenn CSV-Dateien per E-Mail zwischen Mac und Windows verschickt werden, ist dies die Quelle des klassischen é-Mojibakes, wenn eine Seite Windows-1252-Bytes als UTF-8 liest.

Die MySQL-„utf8“-Falle

MySQL hat seit Version 4.1 eine berüchtigte Zeichensatz-Warze: Der Zeichensatz-Alias utf8 ist nicht wirklich UTF-8. Es ist eine 3-Byte-maximale Teilmenge, die keine Zeichen über U+FFFF darstellen kann, was bedeutet, dass sie keine Emoji oder Zeichen aus der ergänzenden Ebene speichern kann. Das Einfügen von „🎉“ in eine utf8-Spalte erzeugt je nach sql_mode „?“ oder einen Fehler. Die Lösung ist utf8mb4, hinzugefügt in MySQL 5.5.3 (März 2010); MySQL 8.0 (April 2018) machte utf8mb4 zum neuen Standard. Aber vor 8.0 erstellte Schemas verwenden oft immer noch die 3-Byte-Version. Wenn Sie sehen, dass Emoji stillschweigend aus Benutzereingaben verschwinden, ist dies fast immer die Ursache. PostgreSQL hat keine entsprechende Falle, es akzeptiert echtes UTF-8 nativ.

SMS, GSM-7 und die 160-Byte-Nutzlast

Das 160-Zeichen-SMS-Limit geht auf eine Berechnung von Friedhelm Hillebrand aus dem Jahr 1985 zurück, einem Ingenieur der GSM-Arbeitsgruppe, der sich angeblich an seine Schreibmaschine setzte, zufällige Sätze tippte und zählte, dass „die meisten Nachrichten in 160 Zeichen oder weniger ausgedrückt werden können“. Die 160 wurden dann rückwärts abgeleitet, um in eine 140-Byte-Nutzlast mit einem 7-Bit-Alphabet zu passen (140 × 8 ÷ 7 = 160). Die Codierungsdetails sind in 3GPP TS 23.038 (ursprünglich GSM 03.38) formalisiert und regeln noch heute die SMS-Abrechnung.

In Bytes: Eine einzelne SMS sind 140 Bytes auf der Leitung. Mit GSM-7 sind das 160 Zeichen; mit UCS-2 (eine 2-Byte-Codierung fester Breite, die für alles außerhalb des GSM-7-Alphabets verwendet wird) sind es 70. Mehrteilige Nachrichten verlieren 7 GSM-7-Zeichen oder 3 UCS-2-Zeichen pro Segment an einen Benutzerdaten-Header (User Data Header), der für die Wiederzusammensetzung verwendet wird, sodass lange Nachrichten bei 153 GSM-7-Zeichen pro Segment oder 67 UCS-2-Zeichen pro Segment begrenzt sind. Ein einziges typografisches Anführungszeichen, ein Geviertstrich oder ein Emoji stuft die gesamte Nachricht auf UCS-2 herab und halbiert das Limit pro Segment. Twilios „Smart Encoding“ ersetzt automatisch geschwungene Anführungszeichen durch gerade, um Marketingkampagnen in der billigeren Codierung zu halten.

Wo Byte-Limits wirklich zubeißen

Drei Kategorien, in denen Byte- (nicht Zeichen-) Limits Sie erwischen:

HTTP-Request-Header. Kein formales Spezifikationsmaximum, jeder Server setzt eines durch. Apaches LimitRequestFieldSize ist standardmäßig 8 KB pro Header; Nginx' large_client_header_buffers sind standardmäßig 4 × 8 KB; IIS ist 16 KB; der AWS Application Load Balancer akzeptiert 16 KB pro Header und 60 KB insgesamt; Cloudflare erlaubt 32 KB. JWTs mit aufgeblähten Claim-Sets überschreiten routinemäßig den Apache-Standard von 8 KB, was der häufigste Produktionsfehler-Modus für tokenbasierte Authentifizierung ist.

Cloud-Objekt-Storage-Schlüssel. S3 und GCS begrenzen Objektschlüssel beide auf 1024 Bytes UTF-8. Azure Blob Storage begrenzt Blobnamen auf 1024 Zeichen (intern UTF-16). Für S3 erreicht ein CJK-lastiger Dateiname (3 Bytes pro Zeichen) ~341 Zeichen; ein emoji-lastiger (4 Bytes pro Zeichen) ~256, weit bevor der Entwickler es erwartet.

Datenbankzeilen- und Index-Limits. MySQL InnoDB hat eine Zeilengröße von 65.535 Bytes und ein Index-Schlüssel-Präfix-Limit von 3072 Bytes im DYNAMIC-Zeilenformat (767 im älteren COMPACT). Eine VARCHAR(255) utf8mb4-Spalte benötigt 1020 Bytes (255 × 4) Indexplatz, OK auf DYNAMIC, kaputt auf COMPACT. MongoDB-BSON-Dokumente sind auf 16 MB begrenzt. DynamoDB-Elemente sind auf 400 KB begrenzt (einschließlich Attributnamen). Redis-Werte sind auf 512 MB begrenzt.

Häufige Anwendungsfälle

• Datenbankfeldvalidierung, bestätigen, dass ein vom Benutzer übermittelter Name vor dem INSERT passt, besonders wenn die Spalte VARCHAR(255) utf8mb4 ist und die Eingabe CJK.
• SMS-Marketing-Text, bestätigen, dass die Nachricht in GSM-7 bleibt (~1 Byte pro sichtbarem Zeichen in der Nutzlast), statt versehentlich wegen eines geschwungenen Anführungszeichens auf UCS-2 zu kippen.
• API-Nutzlast-Budgetierung, bestätigen, dass ein JSON-Body unter einem bekannten Limit passt (DynamoDB 400 KB, AWS Lambda Nutzlast 6 MB synchron, 256 KB asynchron).
• Cloud-Objektschlüssel, bestätigen, dass ein S3- / GCS-Schlüssel nach Nicht-ASCII-Übersetzung unter 1024 Bytes bleibt.
• Emoji-Offenlegung, sehen genau, wie viel „Gewicht“ ein Emoji oder eine ZWJ-Familiensequenz einer Zeichenkette hinzufügt.
• Codierungsauswahl, UTF-8 vs UTF-16 Bytegrößen vergleichen; für überwiegend CJK-Inhalte kann UTF-16 kompakter sein (2 Bytes pro CJK-Zeichen vs 3 in UTF-8).

Häufige Fehler

1. JavaScripts .length für Bytegröße vertrauen. .length gibt UTF-16-Code-Einheiten zurück, keine Bytes und keine Zeichen. Für UTF-8-Bytes verwenden Sie new TextEncoder().encode(text).length; für sichtbare Zeichen Intl.Segmenter.
2. Annehmen, dass MySQL utf8 wirklich UTF-8 ist. Es ist eine 3-Byte-Teilmenge, die Emoji stillschweigend verwirft. Verwenden Sie immer utf8mb4 (und utf8mb4_unicode_ci für die Kollation) in jeder Spalte, die mit vom Benutzer übermitteltem Text in Berührung kommt.
3. Annehmen, dass ein Emoji einem Byte entspricht. Ein einzelnes Emoji sind 4 Bytes in UTF-8, 4 Bytes in UTF-16 (Surrogate-Paar). Eine ZWJ-Familiensequenz kann 30 Bytes überschreiten für das, was wie ein einziges Zeichen aussieht.
4. Ein UTF-8-BOM als Inhalt zählen. Das Drei-Byte-UTF-8-BOM EF BB BF am Anfang einer Datei ist Metadaten, kein Text. Die meisten CLI-Tools (awk, head, sed) behandeln es als Teil des ersten Felds, was die Quelle vieler Fehler vom Typ „Warum hat mein erster Spaltenname ein seltsames Zeichen?“ ist.
5. Eine „ASCII-Bytes“-Zählung für Nicht-ASCII-Text melden. ASCII kann keine Zeichen über U+007F darstellen. Dieser Zähler warnt, wenn die Eingabe Nicht-ASCII enthält, damit Sie wissen, dass die ASCII-Spalte nicht aussagekräftig ist.

Weitere häufig gestellte Fragen

Warum sind 4 Bytes für ein Emoji, wenn Textzeichen nur 1 Byte sind?

UTF-8 verwendet 1 Byte für ASCII (U+0000 bis U+007F), 2 Bytes für Lateinisch-erweitert / Griechisch / Kyrillisch / Arabisch / Hebräisch (U+0080 bis U+07FF), 3 Bytes für die meisten CJK- und indischen Schriften (U+0800 bis U+FFFF) und 4 Bytes für Emoji und Zeichen der ergänzenden Ebene (U+10000 bis U+10FFFF). Ein typisches Emoji wie 😀 (U+1F600) ist in der ergänzenden Ebene und kostet 4 Bytes. Kombinierte Emoji (z. B. Familie 👨‍👩‍👧‍👦) sind aus mehreren Basis-Emojis aufgebaut, die durch Nullbreiten-Verbinder zusammengeklebt sind; jedes Basis-Emoji sind 4 Bytes, jeder Verbinder 3 Bytes, also benötigt eine Familie von 4 4×4 + 3×3 = 25 Bytes für das, was wie ein Zeichen aussieht.

Was bedeutet MySQL utf8 wirklich?

In MySQL ist der Zeichensatz-Alias utf8 eine 3-Byte-maximale Teilmenge des echten UTF-8. Er kann jedes Zeichen der Unicode Basic Multilingual Plane codieren, aber keine Emoji oder Zeichen über U+FFFF speichern. Echtes 4-Byte-UTF-8 in MySQL heißt utf8mb4, verfügbar seit MySQL 5.5.3 (März 2010), Standard seit MySQL 8.0 (April 2018). Wenn Sie das Schema ändern können, verwenden Sie immer utf8mb4 mit der Kollation utf8mb4_0900_ai_ci (oder utf8mb4_unicode_ci auf älteren Servern).

Enthält dieser Zähler eine UTF-8-Byte-Reihenfolge-Markierung?

Nein. Die UTF-8-Byte-Reihenfolge-Markierung sind die drei Bytes EF BB BF, die Excel unter Windows am Anfang einer Datei verlangt, um UTF-8 zu erkennen. Der Zähler misst die Bytes des Textes, den Sie einfügen; wenn Ihr Text mit einem BOM beginnt, werden diese drei Bytes als Inhalt gezählt. Wenn Sie wissen wollen, ob die Bytes Ihrer Datei ein Limit erreichen, fügen Sie nur den Inhalt der Datei ein, nicht das BOM.

Warum zeigt mein chinesischer Text 3 Bytes pro Zeichen in UTF-8?

Fast alle CJK-Ideogramme liegen im Unicode-Bereich U+4E00 bis U+9FFF (dem CJK-Unified-Ideographs-Block), den UTF-8 als je 3 Bytes codiert. Ein 100-Zeichen-Chinesischer Satz ist daher 300 UTF-8-Bytes. In UTF-16 sind dieselben Texte 200 Bytes (2 Bytes pro Zeichen), sodass UTF-16 für überwiegend CJK-Inhalte kompakter ist. UTF-8 gewinnt für gemischten lateinisch-und-CJK-Inhalt, weil lateinische Zeichen je 1 Byte statt 2 kosten.

Wird mein Text irgendwo hochgeladen?

Nein. Der Byte-Zähler läuft vollständig in Ihrem Browser. UTF-8-Byte-Zählungen kommen von der Standard-TextEncoder-API (jeder moderne Browser unterstützt sie), UTF-16- und Latin-1-Zählungen kommen von einfachen Schleifen. Es gibt keine Netzwerk-Anfrage, keinen Server-Aufruf, keine Protokollierung. Sobald die Seite geladen ist, funktioniert das Werkzeug offline. Sicher für die Inspektion von API-Token, internen Daten oder allem, was Sie nicht in einen Dritten-Text-Zähler einfügen würden.