Contatore di byte

Come funziona

1. Inserisci o incolla il testo: Digita o incolla qualsiasi testo nel campo di input.
2. Visualizza il conteggio dei byte: Lo strumento mostra istantaneamente il conteggio dei byte in UTF-8, UTF-16, ASCII e altre codifiche affiancate.
3. Controlla i limiti: Confronta il conteggio dei byte con i limiti comuni (SMS: 160 caratteri, header HTTP: 8 KB, campi di database, ecc.) per vedere se il tuo contenuto rientra.

Perché usare il Contatore di byte?

Il conteggio dei caratteri e il conteggio dei byte non sono la stessa cosa. Una singola emoji può essere di 4 byte in UTF-8. I caratteri cinesi e arabi occupano 2-3 byte ciascuno. Molti sistemi impongono limiti di byte, non limiti di caratteri, inclusi i campi VARCHAR di MySQL, i valori Redis, gli header HTTP, i messaggi SMS e i nomi degli oggetti di archiviazione cloud. Il Contatore di byte rivela la dimensione effettiva in byte del tuo testo in ogni codifica in modo che tu possa rimanere entro i vincoli del sistema.

Funzionalità

• Dimensioni multiple di codifica: Mostra il conteggio dei byte per UTF-8, UTF-16 LE/BE, UTF-32 e Latin-1.
• Ripartizione dei caratteri: Conta separatamente i caratteri totali, i punti di codice Unicode e i caratteri multi-byte.
• Preset per limiti comuni: Confronta con SMS (160), tweet (280), meta description (160), limiti VARCHAR di MySQL e altro.
• Aggiornamenti in tempo reale: Il conteggio dei byte si aggiorna in tempo reale mentre digiti.
• Confronto delle codifiche: Vedi quale codifica è più compatta per il tuo testo specifico.

Domande frequenti

Perché il mio conteggio dei byte è maggiore del mio conteggio dei caratteri?

Molti caratteri occupano più di 1 byte in UTF-8. I caratteri ASCII (A-Z, 0-9, punteggiatura) sono di 1 byte ciascuno. I caratteri latini estesi (lettere accentate) sono di 2 byte. I caratteri cinesi, giapponesi, coreani e arabi sono tipicamente di 3 byte. Le emoji sono solitamente di 4 byte.

Quale codifica usano la maggior parte dei sistemi web?

UTF-8 è la codifica dominante per i contenuti web, APIs, JSON e database. MySQL e PostgreSQL usano UTF-8 per impostazione predefinita. Quando verifichi i limiti di byte, usa la colonna UTF-8 a meno che il tuo sistema non specifichi diversamente.

Perché i messaggi SMS hanno un limite di 160 caratteri?

Gli SMS tradizionali usano la codifica GSM a 7 bit, che consente 160 caratteri per segmento. Quando includi un carattere non-GSM (come una virgoletta tipografica, un'emoji o una lettera non latina), il messaggio passa alla codifica UCS-2, che riduce il limite a 70 caratteri per segmento.

Cos'è davvero un byte?

Un byte è 8 bit, che possono contenere 256 valori distinti. Nel testo, quei 256 valori si mappano a caratteri tramite una codifica, un libro di regole che dice «questa sequenza di byte equivale a questo carattere». La stessa stringa di byte può significare testo completamente diverso sotto codifiche diverse: il byte 0xE9 è «é» in Latin-1, l'inizio di una sequenza di 3 byte in UTF-8, o parte di un'unità di codice UTF-16. La codifica è tutta la storia.

Quando salvi del testo su disco, lo invii in rete o lo memorizzi in un database, ciò che viene effettivamente persistito sono byte, non caratteri. Il conteggio caratteri che vedi in un editor di testo viene calcolato al momento della visualizzazione, dopo la decodifica dei byte. Sbaglia la codifica da una parte o dall'altra e ottieni mojibake: testo decodificato con la codifica sbagliata appare come incomprensibile (il classico é invece di é quando i byte Windows-1252 vengono letti come UTF-8).

Il conteggio dei byte è ciò che misurano i limiti delle colonne dei database, i buffer degli header HTTP, i payload SMS e le chiavi degli oggetti di storage cloud, indipendentemente da come «sembra» il testo. Questo contatore riporta la dimensione in byte nelle quattro codifiche che probabilmente ti interesseranno di più: UTF-8 (lo standard moderno), UTF-16 (il formato interno di Windows / Java / JavaScript), ASCII (valido solo per testo latino inglese) e Latin-1 (un ripiego ereditato a singolo byte). Il conteggio caratteri accanto è dato come riferimento.

UTF-8: la storia

UTF-8 è stato abbozzato da Ken Thompson e Rob Pike ai Bell Labs nella notte del 2 settembre 1992, presumibilmente su una tovaglietta in un diner del New Jersey, dopo che il team di Plan 9 ebbe bisogno di una codifica a lunghezza variabile compatibile con ASCII per Unicode. Il design porta tre proprietà che quasi nient'altro ha contemporaneamente: il testo ASCII è anche UTF-8 valido (1 byte per carattere, byte identici), la codifica è auto-sincronizzante (i bit alti di qualsiasi byte ti dicono se inizia un nuovo carattere o continua uno esistente), e non c'è ambiguità di ordine dei byte. Queste tre proprietà insieme spiegano perché UTF-8 ha soppiantato ogni codifica concorrente sul web.

È stato standardizzato per la prima volta come RFC 2044 nell'ottobre 1996, revisionato come RFC 2279 nel gennaio 1998, e sostituito dall'attuale RFC 3629 (novembre 2003), che ha limitato UTF-8 a 4 byte per carattere per corrispondere al tetto finale dei punti di codice Unicode a U+10FFFF. W3Techs traccia l'uso delle codifiche sul web pubblico continuamente dal 2010; UTF-8 è passato dal 56% dei siti web nel 2011 a circa il 98% nel 2026. La specifica HTML5 impone UTF-8 per i nuovi contenuti; HTTP/2 e HTTP/3 inviano header in UTF-8 via HPACK / QPACK; RFC 8259 impone UTF-8 per lo scambio JSON tra sistemi. Se devi scegliere una codifica per tutto, la risposta degli ultimi 15 anni è stata UTF-8 e la risposta per i prossimi 15 sarà la stessa.

UTF-8 è a lunghezza variabile, da 1 a 4 byte per carattere:

Conseguenza pratica: il testo inglese in UTF-8 ha in media ~1 byte per carattere; il cinese ~3 byte; un messaggio ricco di emoji può raggiungere 4 byte per carattere visibile, e gli emoji combinati (sequenze ZWJ di famiglia) raggiungono facilmente 20-30 byte per ciò che sembra un singolo carattere.

UTF-16 e la trappola dei surrogati

UTF-16 è stata la codifica di scelta per Windows NT (1993), Java 1.0 (1996), JavaScript (1995), .NET e Cocoa NSString di Mac OS X. Usa 2 byte per ogni carattere nel Basic Multilingual Plane (U+0000 – U+FFFF), e coppie surrogate per qualsiasi cosa al di fuori: un surrogato alto (D800–DBFF) più un surrogato basso (DC00–DFFF), 4 byte in totale. UTF-16 ha bisogno di una marca dell'ordine dei byte (BOM) su disco per distinguere big-endian (UTF-16BE, FE FF) da little-endian (UTF-16LE, FF FE); Windows usa little-endian per impostazione predefinita.

La trappola: in JavaScript, "😀".length === 2. MDN lo dice direttamente: la proprietà length «contiene la lunghezza della stringa in unità di codice UTF-16». Ecco perché un singolo emoji come 😄 riporta una lunghezza di 2 (vive nel piano supplementare e necessita di una coppia surrogata), e la sequenza ZWJ famiglia 👨‍👩‍👧‍👦 riporta una lunghezza di 11 (quattro emoji a 2 unità di codice più tre giunzioni a larghezza zero). Lo stesso emoji famiglia a un carattere conta come 11 in JavaScript, 5 in Python 3 e 1 in Swift, a seconda del modello di stringa di ogni linguaggio. Per conteggi corretti dei caratteri visibili in JavaScript, usa Intl.Segmenter con granularità grapheme (ogni browser evergreen dal 2021).

ASCII, Latin-1 e il caos pre-Unicode

ASCII (American Standard Code for Information Interchange) è stato standardizzato come ASA X3.4-1963, revisionato come X3.4-1968 e nuovamente come ANSI X3.4-1986. Un codice a 7 bit, 128 caratteri: 95 stampabili più 33 di controllo. I 33 caratteri di controllo includono eredità di telescriventi come BEL, BS, CR, LF, DEL, e alcuni che sopravvivono nei protocolli moderni (NUL, TAB, LF, CR, ESC). ASCII funziona ancora come sottoinsieme stretto di UTF-8, motivo per cui «il testo ASCII puro» è anche UTF-8 valido e perché la migrazione a UTF-8 è stata indolore per i sistemi solo in inglese.

Latin-1 / ISO-8859-1 (1987) era un'estensione a singolo byte da 256 caratteri che aggiungeva lettere accentate dell'Europa occidentale, simboli monetari e punteggiatura comune. Era la codifica de facto dei contenuti web occidentali dal 1995 fino a quando UTF-8 l'ha soppiantata intorno al 2008. Windows-1252 è il superset Microsoft di Latin-1, che aggiunge «virgolette tipografiche», trattini em e il simbolo dell'euro nell'intervallo di controllo C1 (0x80-0x9F); quando file CSV vengono scambiati via email tra Mac e Windows, questa è la sorgente del classico mojibake é quando un lato legge i byte Windows-1252 come UTF-8.

La trappola «utf8» di MySQL

MySQL si porta dietro una notoria verruca dei set di caratteri dalla versione 4.1: l'alias del set di caratteri utf8 non è realmente UTF-8. È un sottoinsieme a 3 byte massimo che non può rappresentare caratteri sopra U+FFFF, il che significa che non può memorizzare emoji o caratteri del piano supplementare. Inserire «🎉» in una colonna utf8 produce «?» o un errore a seconda di sql_mode. La soluzione è utf8mb4, aggiunto in MySQL 5.5.3 (marzo 2010); MySQL 8.0 (aprile 2018) ha reso utf8mb4 il nuovo predefinito. Ma gli schemi creati prima di 8.0 usano spesso ancora la versione a 3 byte per impostazione predefinita. Se vedi emoji sparire silenziosamente dall'input utente, questa è quasi sempre la causa. PostgreSQL non ha una trappola equivalente, accetta UTF-8 vero nativamente.

SMS, GSM-7 e il payload da 160 byte

Il limite di 160 caratteri SMS risale a un calcolo di Friedhelm Hillebrand nel 1985, un ingegnere del Working Party GSM che presumibilmente si sedette alla sua macchina da scrivere, batté frasi casuali e contò che «la maggior parte dei messaggi può essere espressa in 160 caratteri o meno». I 160 sono stati poi derivati a ritroso per stare in un payload di 140 byte usando un alfabeto a 7 bit (140 × 8 ÷ 7 = 160). I dettagli della codifica sono formalizzati in 3GPP TS 23.038 (originariamente GSM 03.38), e governano ancora la fatturazione SMS oggi.

In byte: un singolo SMS è 140 byte sul filo. Con GSM-7 sono 160 caratteri; con UCS-2 (una codifica a larghezza fissa di 2 byte usata per qualsiasi cosa al di fuori dell'alfabeto GSM-7) sono 70. I messaggi multi-segmento perdono 7 caratteri GSM-7 o 3 caratteri UCS-2 per segmento a favore di un User Data Header usato per il riassemblaggio, quindi i messaggi lunghi sono limitati a 153 caratteri GSM-7 per segmento o 67 caratteri UCS-2 per segmento. Una sola virgoletta tipografica, un trattino em o un emoji declassa l'intero messaggio a UCS-2 e dimezza il limite per segmento. Lo «Smart Encoding» di Twilio sostituisce automaticamente le virgolette curve con quelle dritte per tenere le campagne di marketing nella codifica più economica.

Dove i limiti in byte mordono davvero

Tre categorie in cui i limiti in byte (e non in caratteri) ti prendono:

Header delle richieste HTTP. Nessun massimo nella spec formale, ogni server ne impone uno. Il LimitRequestFieldSize di Apache è 8 KB per header per impostazione predefinita; i large_client_header_buffers di Nginx sono 4 × 8 KB per impostazione predefinita; IIS è 16 KB; l'AWS Application Load Balancer accetta 16 KB per header e 60 KB in totale; Cloudflare permette 32 KB. I JWT con set di claim gonfi superano regolarmente il default di 8 KB di Apache, che è la modalità di fallimento in produzione più comune per l'autenticazione basata su token.

Chiavi di storage di oggetti cloud. S3 e GCS limitano entrambi le chiavi degli oggetti a 1024 byte di UTF-8. Azure Blob Storage limita i nomi dei blob a 1024 caratteri (UTF-16 interno). Per S3, un nome file ricco di CJK (3 byte per carattere) si limita a ~341 caratteri; uno ricco di emoji (4 byte per carattere) a ~256, molto prima di quanto il sviluppatore si aspetti.

Limiti di riga e indice di database. MySQL InnoDB ha una dimensione di riga di 65.535 byte e un limite di prefisso di chiave di indice di 3072 byte sul formato di riga DYNAMIC (767 sul vecchio COMPACT). Una colonna VARCHAR(255) utf8mb4 necessita di 1020 byte (255 × 4) di spazio indice, OK su DYNAMIC, rotto su COMPACT. I documenti BSON di MongoDB si limitano a 16 MB. Gli elementi DynamoDB si limitano a 400 KB (includendo i nomi degli attributi). I valori Redis si limitano a 512 MB.

Casi d'uso comuni

• Validazione di campi di database, confermare che un nome inviato dall'utente entrerà prima dell'INSERT, specialmente quando la colonna è VARCHAR(255) utf8mb4 e l'input è CJK.
• Copy di marketing SMS, confermare che il messaggio rimanga in GSM-7 (~1 byte per carattere visibile nel payload) invece di cadere accidentalmente in UCS-2 per una virgoletta tipografica.
• Budget del payload API, confermare che un corpo JSON entri sotto un limite noto (DynamoDB 400 KB, payload AWS Lambda 6 MB sincrono, 256 KB asincrono).
• Chiavi di oggetti cloud, confermare che una chiave S3 / GCS rimanga sotto i 1024 byte dopo la transcodifica non-ASCII.
• Divulgazione emoji, vedere esattamente quanto «peso» un emoji o una sequenza ZWJ famiglia aggiunge a una stringa.
• Selezione della codifica, confrontare le dimensioni in byte UTF-8 vs UTF-16; per contenuto prevalentemente CJK, UTF-16 può essere più compatto (2 byte per carattere CJK vs 3 in UTF-8).

Errori comuni

1. Fidarsi di .length di JavaScript per la dimensione in byte. .length ritorna unità di codice UTF-16, non byte e non caratteri. Per i byte UTF-8, usa new TextEncoder().encode(text).length; per i caratteri visibili, usa Intl.Segmenter.
2. Supporre che MySQL utf8 sia realmente UTF-8. È un sottoinsieme a 3 byte che scarta silenziosamente gli emoji. Usa sempre utf8mb4 (e utf8mb4_unicode_ci per la collation) su qualsiasi colonna che tocchi testo inviato dall'utente.
3. Supporre che un emoji equivalga a un byte. Un singolo emoji è 4 byte in UTF-8, 4 byte in UTF-16 (coppia surrogata). Una sequenza ZWJ famiglia può superare i 30 byte per ciò che sembra un singolo carattere.
4. Contare un BOM UTF-8 come contenuto. Il BOM UTF-8 a tre byte EF BB BF all'inizio di un file è metadato, non testo. La maggior parte degli strumenti CLI (awk, head, sed) lo tratta come parte del primo campo, che è la fonte di molti bug «perché il mio primo nome di colonna ha un carattere strano».
5. Riportare un conteggio di «byte ASCII» per testo non-ASCII. ASCII non può rappresentare caratteri sopra U+007F. Questo contatore avvisa quando l'input contiene non-ASCII così sai che la colonna ASCII non è significativa.

Altre domande frequenti

Perché un emoji è 4 byte quando i caratteri di testo sono solo 1?

UTF-8 usa 1 byte per ASCII (U+0000 a U+007F), 2 byte per latino esteso / greco / cirillico / arabo / ebraico (U+0080 a U+07FF), 3 byte per la maggior parte degli script CJK e indici (U+0800 a U+FFFF), e 4 byte per emoji e caratteri del piano supplementare (U+10000 a U+10FFFF). Un emoji tipico come 😀 (U+1F600) è nel piano supplementare e costa 4 byte. Gli emoji combinati (per esempio famiglia 👨‍👩‍👧‍👦) sono costruiti da diversi emoji base incollati insieme con giunzioni a larghezza zero; ogni emoji base è 4 byte, ogni giunzione è 3 byte, quindi una famiglia di 4 prende 4×4 + 3×3 = 25 byte per ciò che sembra un carattere.

Cosa significa realmente MySQL utf8?

In MySQL, l'alias del set di caratteri utf8 è un sottoinsieme a 3 byte massimo del vero UTF-8. Può codificare ogni carattere nel Basic Multilingual Plane di Unicode ma non può memorizzare emoji o qualsiasi carattere sopra U+FFFF. Il vero UTF-8 a 4 byte in MySQL è utf8mb4, disponibile da MySQL 5.5.3 (marzo 2010), predefinito da MySQL 8.0 (aprile 2018). Se puoi cambiare lo schema, usa sempre utf8mb4 con la collation utf8mb4_0900_ai_ci (o utf8mb4_unicode_ci sui server più vecchi).

Questo contatore include una marca dell'ordine dei byte UTF-8?

No. La marca dell'ordine dei byte UTF-8 è la sequenza di tre byte EF BB BF che Excel su Windows richiede all'inizio di un file per rilevare UTF-8. Il contatore misura i byte del testo che incolli; se il tuo testo inizia con un BOM, quei tre byte sono contati come contenuto. Se vuoi sapere se i byte del tuo file raggiungeranno un limite, incolla solo il corpo del file, non il BOM.

Perché il mio testo cinese mostra 3 byte per carattere in UTF-8?

Quasi tutti gli ideogrammi CJK si trovano nell'intervallo Unicode U+4E00 a U+9FFF (il blocco CJK Unified Ideographs), che UTF-8 codifica come 3 byte ciascuno. Una frase cinese di 100 caratteri è quindi 300 byte UTF-8. In UTF-16 lo stesso testo è 200 byte (2 byte per carattere), quindi UTF-16 è più compatto per contenuto prevalentemente CJK. UTF-8 vince per contenuto misto latino-e-CJK perché i caratteri latini costano 1 byte ciascuno invece di 2.

Il mio testo viene caricato da qualche parte?

No. Il contatore di byte funziona interamente nel tuo browser. I conteggi di byte UTF-8 vengono dall'API standard TextEncoder (ogni browser moderno la supporta), i conteggi UTF-16 e Latin-1 vengono da semplici loop. Non c'è richiesta di rete, non c'è chiamata al server, non c'è logging. Una volta caricata la pagina, lo strumento funziona offline. Sicuro per ispezionare token API, dati interni o qualsiasi cosa che non incolleresti in un contatore di testo di terze parti.