Qual è il vantaggio di scegliere la codifica ASCII su UTF-8?

In alcuni casi può accelerare l'accesso ai singoli personaggi. Immagina stringa str='ABC' codificata in UTF8 e in ASCII (e supponendo che il linguaggio / compilatore / database conosca la codifica)

Per accedere al terzo carattere ( C ) da questa stringa usando l'operatore di accesso alla matrice, che è presente in molti linguaggi di programmazione, farebbe qualcosa come c = str[2] .

Ora, se la stringa è codificata ASCII, tutto ciò che dobbiamo fare è recuperare il terzo byte dalla stringa.

Se, tuttavia, la stringa è codificata in UTF-8, dobbiamo prima controllare se il primo carattere è un char di uno o due byte, quindi dobbiamo eseguire lo stesso controllo sul secondo carattere, e solo allora possiamo accedere al terzo carattere. La differenza di prestazioni sarà maggiore, più lunga sarà la stringa.

Questo è un problema, ad esempio, in alcuni motori di database, in cui trovare l'inizio di una colonna posizionata "dopo" un VARCHAR codificato in UTF-8, il database non deve solo controllare quanti caratteri ci sono nel campo VARCHAR, ma anche quanti byte utilizza ognuno di essi.

Se intendi utilizzare solo il sottoinsieme US-ASCII (o ISO 646) di UTF-8, non c'è alcun reale vantaggio per l'uno o l'altro; in effetti, tutto è codificato in modo identico.

Se vuoi andare oltre il set di caratteri US-ASCII e usare (per esempio) i caratteri con accenti, dieresi, ecc. che sono usati nelle tipiche lingue dell'Europa occidentale, allora c'è una differenza - la maggior parte questi possono ancora essere codificati con un singolo byte in ISO 8859, ma richiederanno due o più byte quando codificati in UTF-8. Ci sono anche, ovviamente, degli svantaggi: ISO 8859 richiede che si utilizzino mezzi fuori banda per specificare la codifica utilizzata, e supporta solo uno di queste lingue alla volta. Ad esempio, puoi codificare tutti i caratteri dell'alfabeto cirillico (russo, bielorusso, ecc.) Usando solo un byte a testa, ma se hai bisogno / vuoi mischiare quelli con caratteri francesi o spagnoli (diversi da quelli negli Stati Uniti-ASCII / ISO 646 sottoinsieme) siete praticamente sfortunati: dovete assolutamente cambiare set di caratteri per farlo.

ISO 8859 è davvero utile solo per alfabeti europei. Per supportare la maggior parte degli alfabeti utilizzati nella maggior parte degli alfabeti cinesi, giapponesi, coreani, arabi, ecc., È necessario utilizzare una codifica completamente diversa. Alcuni di questi (es. Shift JIS per il giapponese) sono un dolore assoluto da affrontare. Se c'è qualche possibilità che tu voglia mai supportarli, ritengo utile utilizzare Unicode per ogni evenienza.

ANSI può essere molte cose, la maggior parte essendo set di caratteri a 8 bit in questo senso (come la code page 1252 sotto Windows).

Forse stavi pensando ad ASCII che è 7 bit e un sottoinsieme appropriato di UTF-8. Cioè qualsiasi flusso ASCII valido è anche un flusso UTF-8 valido.

Se stavi pensando a set di caratteri a 8 bit, un vantaggio molto importante sarebbe che tutti i caratteri rappresentabili sono esattamente 8 bit, mentre in UTF-8 possono essere fino a 24 bit.

Sì, ci sono ancora alcuni casi d'uso in cui l'ASCII ha senso: formati di file e protocolli di rete . In particolare, per gli usi in cui:

• Hai dati generati e consumati dai programmi per computer, mai presentati agli utenti finali
• Ma che è utile per i programmatori essere in grado di leggere, per facilità di sviluppo e debug.

Usando ASCII come codifica eviti la complessità della codifica multi-byte pur conservando almeno una certa leggibilità umana.

Un paio di esempi:

• HTTP è un protocollo di rete definito in termini di sequenze di ottetti, ma è molto utile (almeno per i programmatori di lingua inglese) che questi corrispondono alla codifica ASCII di parole come "GET", "POST", "Accept-Language" e così via.
• I tipi di chunk nel formato immagine PNG sono composti da quattro ottetti, ma è utile se si ' re programmare un codificatore o decodificatore PNG che IDAT significa "dati immagine" e PLTE significa "tavolozza".

Ovviamente devi stare attento che i dati non saranno presentati agli utenti finali, perché se finiscono per essere visibili (come è successo nel caso degli URL), allora gli utenti si aspettano giustamente che i dati siano in una lingua che possono leggere.

Prima di tutto: il tuo titolo usa / d ANSI, mentre nel testo fai riferimento a ASCII. Si noti che ANSI non è uguale a ASCII. ANSI incorpora il set ASCII. Ma il set ASCII è limitato ai primi 128 valori numerici (0 - 127).

Se tutti i dati sono limitati a ASCII (7 bit), non importa se si utilizza UTF-8, ANSI o ASCII, poiché sia ANSI che UTF-8 incorperano il set ASCII completo. In altre parole: i valori numerici da 0 a 127 inclusi rappresentano esattamente gli stessi caratteri in ASCII, ANSI e UTF-8.

Se hai bisogno di caratteri al di fuori del set ASCII, dovrai scegliere una codifica. Potresti usare ANSI, ma poi ti imbatti nei problemi di tutte le diverse code page. Creare un file sulla macchina A e leggerlo sulla macchina B può produrre / produrrà testi dall'aspetto divertente se queste macchine sono configurate per utilizzare diverse code page, semplice perché il valore numerico nnn rappresenta caratteri diversi in queste code page.

Questo "codice pagina infernale" è la ragione per cui è stato definito lo standard Unicode . UTF-8 è solo una singola codifica di quello standard, ce ne sono molti altri. UTF-16 è il più usato in quanto è la codifica nativa per Windows.

Quindi, se devi supportare qualcosa oltre i 128 caratteri del set ASCII, il mio consiglio è di andare con UTF-8 . In questo modo non ha importanza e non devi preoccuparti di quale tabella codici i tuoi utenti hanno configurato i loro sistemi.