Textgrößenrechner

So verwenden Sie den Rechner

1. Text einfügen oder eine lokale Textdatei untersuchen. Der Editor beginnt leer und behält die ursprünglichen Zeilenenden bei.
2. Kodierung, Zeilenumwandlung und optionale BOM wählen. Exakte Bytezahl ablesen und serialisierte Darstellungen vergleichen.
3. Optional ein Byte-Limit für die von Ihrer API erwartete Darstellung festlegen. Original, Zusammenfassung oder vollständige kodierte Ausgabe gezielt kopieren.
4. Lesen Sie die hervorgehobene Größe in der automatisch gewählten Einheit: Bytes, KB, MB oder GB (TB/PB bei größeren Werten). Die genaue Bytezahl steht darunter und neben anderen großen Ergebnissen. Lesbare Größen werden gerundet; Limits werden immer anhand der exakten Bytezahl geprüft.

Bytes, Kodierungen und Nutzdaten verstehen

Ein Byte besteht aus acht Bits; ein sichtbares Zeichen kann mehrere Unicode-Codepunkte enthalten. 😀 ist ein Graphem, ein Codepunkt und zwei UTF-16-Einheiten: je 4 Bytes in UTF-8, UTF-16 und UTF-32. Kombinierende Zeichen und ZWJ-Sequenzen führen zu unterschiedlichen Zeichen- und Bytezahlen.

UTF-8 verwendet 1–4 Bytes pro Unicode-Skalarwert, UTF-16 2 oder 4 und UTF-32 4. A belegt entsprechend 1/2/4 Bytes. Kyrillisch, Arabisch, Chinesisch und Emoji sind gültiger Text, auch bei höherem Bytebedarf. Gemessen wird kodierter Inhalt, kein JavaScript-Heap oder zugewiesener Plattenspeicher.

Es erfolgt keine Normalisierung, Leerraumbereinigung oder Entfernung unsichtbarer Zeichen. Zusammengesetztes é nutzt 2 UTF-8-Bytes, e + U+0301 nutzt 3. Beide sind gewöhnlich ein Graphem. Die Quelle bleibt erhalten; nur die gewählte Zeilenumwandlung erzeugt den effektiven Text.

Eine zusätzliche BOM kostet 3 Bytes in UTF-8, 2 in UTF-16 oder 4 in UTF-32, auch bei leerem Text. Ein vorhandenes führendes U+FEFF bleibt Inhalt. LF nutzt ein ASCII-Byte, CRLF zwei. Die Umwandlung behandelt CRLF gemeinsam, dann einzelne CR/LF; NEL, U+2028 und U+2029 bleiben erhalten.

Bei A Leerzeichen B benötigt UTF-8 3 Bytes, die URL-Ausgabe A%20B 5 und der Formularwert A+B 3. A mit CRLF und B belegt 4 UTF-8-Bytes, nach LF-Umwandlung 3; die JSON-Zeichenfolge mit CRLF belegt 8. JSON enthält äußere Anführungszeichen und Escape-Sequenzen: Die Eingabe wird als eine Zeichenfolge serialisiert, kein JSON-Dokument minimiert.

Base64 ist Kodierung, keine Komprimierung oder Verschlüsselung. Standardausgabe mit Auffüllzeichen belegt 4 × ceil(byteLength / 3) ASCII-Bytes, bei langen Eingaben etwa ein Drittel mehr. UTF-8-A wird zu QQ== (4 Bytes). Leere Eingabe ohne BOM ergibt leeres Base64; eine leere JSON-Zeichenfolge belegt dennoch 2 Bytes.

File.size ist die unveränderliche Originalbytezahl samt Signatur. Der Import unterstützt UTF-8 und UTF-16LE/BE mit strikter Dekodierung. Eine erkannte BOM wählt den Decoder und wird genau einmal entfernt; zusätzliche U+FEFF bleiben erhalten. Ohne Signatur wird UTF-8 angenommen, nicht zuverlässig erkannt. Neukodierung kann durch Kodierung, Zeilenenden, BOM oder Bearbeitungen abweichen.

Prüfen Sie bei API-Feldlimits, ob der Dienst Rohtext, eine JSON-Zeichenfolge oder URL-/Formulardaten zählt. Der Rechner schließt Eigenschaftsnamen, umschließende Objekte, Feldnamen, Gleichheitszeichen und HTTP-Header aus. Ein Null-Limit akzeptiert nur eine leere Darstellung; Gleichheit passt genau. Datenbanken und Plattformen können andere Regeln haben. Nutzen Sie verwandte Werkzeuge für Wörter, soziale Medien und SMS-Segmente.

Lokale Verarbeitung und Umfang

Die Verarbeitung erfolgt lokal. Dieses Werkzeug lädt eingegebene Texte und Dateien nicht hoch. Die Analyse- und Werbedienste der Website können Netzwerkanfragen senden.