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

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

Per accedere al terzo (C) da questa stringa utilizzando loperatore di accesso agli array che è presente in molti linguaggi di programmazione, faresti 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 carattere di uno o due byte, quindi dobbiamo eseguire lo stesso controllo sul secondo carattere e solo allora possiamo accedere al terzo carattere. La differenza nelle prestazioni sarà tanto maggiore quanto più lunga sarà la stringa.

Questo è un problema, ad esempio, in alcuni motori di database, dove trovare linizio di una colonna “dopo” un VARCHAR con codifica UTF-8 , il database non ha solo bisogno di controllare quanti caratteri sono presenti nel campo VARCHAR, ma anche quanti byte utilizza ciascuno di essi.

Commenti

• Se il database ‘ t memorizza entrambi i ” conteggio dei caratteri ” e il ” numero di byte “, poi ‘ dico ‘ ha dei problemi …
• TBH Non conosco database che possa archiviare neanche …
• @Mchl: how immagini che il database sappia quando ha raggiunto la fine della stringa?
• Di solito raggiungendo 0x00 o 0x0000
• @DeanHarding In che modo il conteggio dei caratteri ti dice dove inizia il secondo carattere ? O il database dovrebbe contenere anche un indice per ogni offset di carattere? Nota. Non sono ‘ solo 2 caratteri, ma potrebbero essere fino a 4 (a meno che non ‘ s 6) stackoverflow.com/questions/9533258/… . (Penso che ‘ sia lunico utf-16 ad avere gli abomini davvero lunghi che potrebbero distruggere il tuo sistema)

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

Se “stai andando oltre il set di caratteri US-ASCII e usi (ad esempio) caratteri con accenti, dieresi, ecc., che sono usati in tipico lingue dellEuropa occidentale, quindi cè una differenza: la maggior parte di queste può ancora essere codificata con un singolo byte in ISO 8859, ma richiederà due o più byte se codificata in UTF-8. Ci sono anche, ovviamente, degli svantaggi: ISO 8859 richiede che tu usi alcuni mezzi fuori banda per specificare la codifica usata e supporta solo uno di questi linguaggi alla volta. Ad esempio, puoi codificare tutti i caratteri del cirillico (russo, bielorusso, ecc.) utilizzando un solo byte ciascuno, ma se hai bisogno / vuoi mescolare quelli con caratteri francesi o spagnoli (diversi da quelli nel sottoinsieme US-ASCII / ISO 646) sei praticamente sfortunato – devi farlo completamente cambia i set di caratteri per farlo.

ISO 8859 è davvero utile solo per gli alfabeti europei. Per supportare la maggior parte degli alfabeti usati nella maggior parte degli alfabeti cinese, giapponese, coreano, arabo, ecc., devi usare alcune codifiche completamente diverse. Alcune di queste (ad esempio, Shift JIS per il giapponese) sono un vero dolore da affrontare. Se cè qualche possibilità che tu voglia mai supportarle, ritengo che valga la pena usare Unicode solo in caso.

ANSI può essere molte cose, la maggior parte essendo set di caratteri a 8 bit a questo proposito (come la tabella codici 1252 sotto Windows).

Forse stavi pensando ad ASCII che è a 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, dove in UTF -8 possono essere fino a 24 bit.

Commenti

• sì i ‘ sto parlando di il set ASCII a 7 bit. puoi pensare a 1 vantaggio che avremo mai bisogno di salvare qualcosa come ASCII invece di UTF-8? (poiché il 7 bit verrebbe salvato comunque come 8 bit, la dimensione del file sarebbe esattamente la stessa)
• Se hai caratteri più grandi del valore Unicode 127, non possono essere salvati in ASCII.
• @Pacerier: Qualsiasi stringa ASCII è una stringa UTF-8 , quindi non cè differenza . La routine di codifica potrebbe essere più veloce a seconda della rappresentazione di stringa della piattaforma che utilizzi, anche se ‘ non mi aspetto una velocità significativa, mentre tu hai una perdita significativa in flessibilità.
• @Thor questo è esattamente il motivo per cui ‘ sto chiedendo se salvare come ASCII ha dei vantaggi
• @Pacerier, se salvi XML come ASCII devi usare ad es & # 160; per uno spazio indistruttibile. Questo è più completo, ma rende i tuoi dati più resistenti agli errori di codifica ISO-Latin-1 e UTF-8. Questo è ciò che facciamo poiché la nostra piattaforma sottostante fa molta magia invisibile con i personaggi. Rimanere in ASCII rende i nostri dati più robusti.

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

• Si dispone di dati generati e consumati da programmi per computer, mai presentati agli utenti finali;
• Ma per i quali è utile programmatori per essere in grado di leggere, per facilità di sviluppo e debug.

Usando ASCII come codifica eviti la complessità della codifica multibyte 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 anglofoni) che corrispondano alla codifica ASCII di parole come “GET”, “POST”, “Accept-Language” e così via.
• I blocchi nel formato immagine PNG sono costituiti da quattro ottetti, ma è utile se “riprogrammi un codificatore o un decodificatore PNG che IDAT significa” dati immagine “e PLTE significa” tavolozza “.

Ovviamente devi fai attenzione che i dati non siano realmente presentati agli utenti finali, perché se finiscono per essere visibili (come è successo nel caso degli URL), allora gli utenti si aspettano giustamente quei dati essere in una lingua in grado di leggere.

Commenti

• Ben detto. ‘ è un po ironico che HTTP, il protocollo che trasmette il maggior numero di Unicode del pianeta, deve supportare solo ASCII. (In realtà, suppongo che lo stesso valga per TCP e IP, supporto binario, supporto ASCII … che ‘ è tutto ciò di cui hai bisogno a quel livello dello stack)

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

Se tutti i tuoi dati sono limitati ad ASCII (7 bit), non importa se utilizzi UTF-8 , ANSI o ASCII, poiché sia ANSI che UTF-8 integrano il set ASCII completo. In altre parole: i valori numerici da 0 fino 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. È possibile utilizzare ANSI, ma poi si verificano i problemi di tutte le diverse tabelle di codici.Creare un file sulla macchina A e leggerlo sulla macchina B può / produrrà testi dallaspetto divertente se queste macchine sono impostate per utilizzare diverse tabelle codici, semplice perché il valore numerico nnn rappresenta caratteri differenti in queste pagine codici.

Questo “inferno della code page” è il motivo per cui è stato definito lo standard Unicode . UTF-8 non è che una singola codifica di quello standard, ce ne sono molti altri. UTF-16 è il più utilizzato in quanto è la codifica nativa per Windows.

Quindi, se hai bisogno di supportare qualcosa oltre i 128 caratteri del set ASCII, il mio consiglio è di andare con UTF-8 . In questo modo non importa e non devi preoccuparti di quale code page i tuoi utenti hanno impostato i loro sistemi.

Commenti

• se non ho bisogno di supportare oltre 128 caratteri, qual è il vantaggio di scegliere la codifica ACSII rispetto alla codifica UTF8?
• Oltre a limitarti a quei 128 caratteri? Non tanto. UTF-8 è stato progettato specificamente per soddisfare ASCII e la maggior parte dei linguaggi occidentali che ” solo ” necessita di ANSI. Scoprirai che UTF-8 codificherà solo un numero relativamente piccolo di caratteri ANSI superiori con più di un byte. Cè una ragione per cui la maggior parte delle pagine HTML utilizza UTF-8 come predefinito …
• @Pacerier, se ‘ non è necessario codificare oltre 127, scegliere ASCII può valere la pena quando si utilizzano alcune API per codificare / decodificare, poiché UTF richiede una verifica aggiuntiva dei bit per considerare byte aggiuntivi come lo stesso carattere, può richiedere calcoli aggiuntivi anziché ASCII puro che legge solo 8 bit senza verifica. Ma ti consiglio di usare ASCII solo se hai davvero bisogno di un alto livello di ottimizzazione in calcoli grandi (grandi grandi) e sai cosa ‘ stai facendo in tale ottimizzazione. In caso contrario, usa UTF-8.