Zeichenketten-Längenrechner

Den Zeichenketten-Längenrechner verwenden

1. Deine Zeichenkette einfügen oder eingeben in das Eingabe-Textarea. Einzelne Token, Code-Zeilen oder lange Absätze funktionieren alle.
2. Die Metriken in den Karten über der Ausgabe beobachten: .length, UTF-8-Bytes, UTF-16-Bytes, Grapheme, Codepunkte und Zeilen. Jede Metrik aktualisiert sich bei jedem Tastendruck.
3. Nach der Divergenzwarnung Ausschau halten. Wenn .length von der Graphemanzahl abweicht, erscheint ein gelber Hinweis - deine Zeichenkette enthält Zeichen, die naive Längenprüfungen brechen werden.
4. Die UTF-8-Byte-Anzahl verwenden beim Dimensionieren von Datenbankspalten, HTTP-Headern oder Dateigrößen. Die UTF-16-Byte-Anzahl verwenden, wenn du über In-Memory-Zeichenketten in Java, C# oder JavaScript nachdenkst.
5. Eine bestimmte Metrik kopieren, indem du die Zahl direkt aus der Karte markierst; das Eingabe-Textarea hält deine vollständige Zeichenkette für weitere Anpassungen verfügbar.

Was jede Metrik im Hintergrund bedeutet

.length liest die JavaScript-Zeichenketten-Eigenschaft, die die Anzahl der UTF-16-Code-Einheiten zurückgibt - 16-Bit-Chunks wie die Zeichenkette intern gespeichert wird. UTF-8-Bytes wird durch new TextEncoder().encode(str).length berechnet, das den WHATWG-UTF-8-Encoder ausführt und ein Uint8Array zurückgibt, dessen Byte-Länge das ist, was eine UTF-8-Datei hätte. UTF-16-Bytes ist einfach str.length * 2, weil jede UTF-16-Code-Einheit 2 Bytes ist. Codepunkte verwenden den Spread-Operator [...str].length, der nach Unicode-Skalar-Wert iteriert und Surrogate-Paare als eines zählt. Die Graphem-Anzahl beruht auf Intl.Segmenter mit granularity: "grapheme", der einzig korrekten Methode, um vom Benutzer wahrgenommene Zeichen in modernem JavaScript zu zählen. Die Zeilenanzahl teilt auf /\\r?\\n/ auf. Jede Metrik wird lokal ohne Netzwerkaufruf berechnet.

Wann diese Metriken wichtig sind

• Validieren eines Benutzernamens gegen ein 20-Zeichen-Limit, bei dem Nutzer "Zeichen" als Graphem, nicht als UTF-16-Code-Einheit bedeuten.
• Dimensionieren einer Datenbank-VARCHAR(255)-Spalte - PostgreSQL zählt Unicode-Codepunkte, MySQL mit utf8mb4 zählt Bytes und SQL Server NVARCHAR zählt UTF-16-Code-Einheiten.
• Berechnen genauer SMS-Payload-Gebühren, bei denen Netzbetreiber nach GSM-Septett-Anzahl für ASCII und UCS-2-Zeichen-Anzahl für alles andere abrechnen.
• Prüfen, ob ein Tweet unter 280 "Zeichen" passt, wie Twitter sie definiert, was Codepunkte mit gewichteter Lateinisch-vs.-CJK-Punktzahl mischt.
• Bestätigen, dass dein API-Antwort-Body unter einem in Bytes ausgedrückten Content-Length-Limit bleibt.
• Aufspüren eines Bugs, bei dem dein Formularvalidator "zu lang" für einen völlig normal aussehenden Namen meldet, weil das Backend Bytes und die UI Zeichen zählt.

Häufige Fallstricke und Randfälle

• Einzelnes Emoji umfasst 4 Bytes. Das grinsende Gesicht 😀 ist ein Graphem, ein Codepunkt (U+1F600), zwei UTF-16-Code-Einheiten und vier UTF-8-Bytes. Jeder Validator, der über welches davon "Länge" ist, uneinig ist, wird jemanden überraschen.
• Familien-Emoji mit ZWJ. Ein Viererfamilien-Emoji ist sieben Codepunkte, verbunden durch Zero-Width-Joiner - ein Graphem, aber bis zu 25 UTF-8-Bytes. Die Divergenz hier ist dramatisch und bricht routinemäßig mobile Eingabevalidatoren.
• Hangul-Silben-Blöcke. Koreanische Silben können vorkombiniert (ein Codepunkt) oder in Jamo zerlegt (mehrere Codepunkte) sein. Die zwei Formen rendern identisch, haben aber unterschiedliche Längen in jeder Metrik außer der Graphem-Anzahl.
• Kombinationsakzente. é als U+00E9 ist 1 Codepunkt und 2 UTF-8-Bytes; als e plus kombinierten Akut (U+0065 U+0301) ist es 2 Codepunkte und 3 UTF-8-Bytes. Immer mit str.normalize("NFC") vor dem Längenvergleich normalisieren.
• BOM und unsichtbare Zeichen. Ein führendes U+FEFF-Byte-Order-Mark fügt 3 UTF-8-Bytes hinzu, die der Benutzer nicht sehen kann. Verdächtige Eingaben durch den Unsichtbares-Zeichen-Detektor auf dieser Seite laufen lassen.
• Normalisierungsformen. NFC, NFD, NFKC und NFKD erzeugen unterschiedliche Byte-Längen für dieselbe visuelle Zeichenkette; konsistent eine wählen.

Warum es sechs verschiedene Antworten gibt

Der Unicode-Standard definiert abstrakte Zeichen und weist ihnen Codepunkte von U+0000 bis U+10FFFF zu. UTF-8 (RFC 3629) kodiert jeden Codepunkt als 1 bis 4 Bytes; UTF-16 (RFC 2781) als 1 oder 2 16-Bit-Code-Einheiten; UTF-32 als eine einzige 32-Bit-Einheit. JavaScript verwendet UTF-16 intern, sodass string.length Code-Einheiten zählt und ein Supplementary-Plane-Emoji als 2 zählt. Graphem-Cluster, definiert durch Unicode Standard Annex #29, gruppieren mehrere Codepunkte in das, was der Benutzer als ein Zeichen wahrnimmt - was auf dem Bildschirm erscheint, wenn du den Cursor nach links setzt und einmal die rechte Pfeiltaste drückst. Der Unterschied ist wichtig, weil Formularvalidierung, Datenbankgrenzen, SMS-Abrechnung und API-Längenlimits alle in verschiedenen Einheiten von verschiedenen Systemen definiert sind.

Vergleich mit Alternativen

In Node.js sind dieselben Metriken mit str.length, Buffer.byteLength(str, "utf8") und [...str].length erreichbar; für Grapheme brauchst du noch Intl.Segmenter oder das grapheme-splitter-npm-Paket. Pythons len() auf einem str zählt Codepunkte, str.encode("utf-8") plus len gibt Bytes und das grapheme-Paket gibt Graphem-Zahlen. Rubys string.length zählt Graphem-Cluster (seit 2.6 mit each_grapheme_cluster), weshalb Ruby-Web-Apps oft "einfach funktionieren", wo Node-Apps Nutzer überraschen. VS Code und JetBrains IDEs zeigen die Code-Einheiten-Anzahl in der Statusleiste; die Zeichenanzahl deines Editors bedeutet fast immer Code-Einheiten. Verwende dieses Tool, wenn du alle sechs Zahlen gleichzeitig brauchst, um einen Längenunstimmigkeits-Bug über einen vollständigen Stack zu debuggen.