Calculateur de taille de texte

Comment utiliser le calculateur

1. Collez du texte ou examinez un fichier local. L’éditeur démarre vide et conserve les fins de ligne d’origine.
2. Choisissez l’encodage, la conversion des fins de ligne et le BOM facultatif. Consultez les octets exacts et comparez les représentations sérialisées.
3. Définissez un budget facultatif pour la représentation attendue par votre API. Copiez explicitement l’original, le récapitulatif ou la sortie encodée complète.
4. Lisez la taille mise en évidence dans l’unité choisie automatiquement : octets, KB, MB ou GB (TB/PB pour les valeurs supérieures). Les octets exacts restent indiqués en dessous et à côté des autres grands résultats. Les tailles lisibles sont arrondies ; les budgets utilisent toujours les octets exacts.

Comprendre les octets, encodages et données

Un octet contient huit bits ; un caractère visible peut comprendre plusieurs points de code Unicode. 😀 est un graphème, un point et deux unités UTF-16 : 4 octets en UTF-8, UTF-16 et UTF-32. Les signes combinatoires et séquences ZWJ expliquent les différences de comptage.

UTF-8 utilise 1 à 4 octets par valeur scalaire Unicode ; UTF-16 en utilise 2 ou 4 et UTF-32 en utilise 4. A occupe respectivement 1/2/4 octets. Le cyrillique, l’arabe, le chinois et les emoji sont du texte valide, même s’ils prennent plus d’octets. Il s’agit du contenu encodé, pas de la mémoire JavaScript ni de l’espace disque alloué.

Aucune normalisation, suppression d’espaces ou de caractères invisibles n’est appliquée. é composé utilise 2 octets UTF-8 ; e + U+0301 en utilise 3. Les deux forment généralement un graphème. La source reste intacte : seule la conversion de fins de ligne choisie crée le texte effectif.

Le BOM ajouté occupe 3 octets en UTF-8, 2 en UTF-16 ou 4 en UTF-32, même pour un texte vide. Un U+FEFF initial littéral reste du contenu. LF utilise un octet ASCII ; CRLF en utilise deux. La conversion traite CRLF ensemble, puis CR/LF isolés, sans modifier NEL, U+2028 et U+2029.

Pour A espace B, UTF-8 occupe 3 octets, A%20B en URL en occupe 5 et A+B en formulaire en occupe 3. A suivi de CRLF puis B occupe 4 octets UTF-8, ou 3 après conversion LF ; sa chaîne JSON préservée en occupe 8. JSON inclut guillemets externes et échappements : l’entrée est sérialisée comme une chaîne, sans minifier un document JSON.

Base64 est un encodage, pas une compression ni un chiffrement. La sortie standard avec remplissage occupe 4 × ceil(byteLength / 3) octets ASCII, soit environ un tiers de plus pour les longues entrées. A en UTF-8 devient QQ== (4 octets). Une entrée vide sans BOM produit du Base64 vide ; une chaîne JSON vide occupe toujours 2 octets.

File.size est le nombre d’octets original immuable, signature incluse. L’import prend en charge UTF-8 et UTF-16LE/BE avec décodage strict. Un BOM reconnu choisit le décodeur et est retiré une seule fois ; tout U+FEFF supplémentaire est conservé. Sans signature, UTF-8 est supposé, pas détecté avec certitude. Le réencodage peut différer selon l’encodage, les fins de ligne, le BOM ou les modifications.

Pour un champ d’API, vérifiez si le service compte le texte brut, une chaîne JSON ou les données URL/formulaire. Le calculateur exclut noms de propriétés, objets englobants, noms de champs, signes égal et en-têtes HTTP. Un budget nul accepte uniquement une représentation vide ; l’égalité respecte exactement le budget. Les règles des bases et plateformes peuvent différer. Utilisez les outils associés pour les mots, réseaux sociaux et segments SMS.

Traitement local et périmètre

Le traitement est local. Cet outil ne téléverse ni le texte saisi ni les fichiers. Les services d’analyse et de publicité du site peuvent effectuer des requêtes réseau.