Pensavo che Unicode fosse stato progettato per aggirare l'intero problema di avere molta codifica diversa a causa di un piccolo spazio di indirizzamento (8 bit) nella maggior parte dei tentativi precedenti (ASCII, ecc.).
Perché allora ci sono così tante codifiche Unicode? Anche più versioni della (essenzialmente) stessa, come UTF-8, UTF-16, ecc.
Perché le persone non vogliono spendere 21 bit per ogni personaggio. Su tutti i sistemi moderni, ciò significherebbe essenzialmente l'utilizzo di tre byte per carattere, che è tre volte più di quello a cui le persone erano abituate, quindi non erano disposti ad adottare Unicode. Dovevano essere trovati compromessi: ad es. UTF-8 è ottimo per il testo in inglese perché i file ASCII legacy non devono essere convertiti affatto, ma è meno utile per le lingue europee e di scarsa utilità per le lingue asiatiche.
Quindi, in sostanza, sì, avremmo potuto definire una singola codifica universale e un singolo grafico a caratteri universali, ma il mercato non l'avrebbe accettato.
Unicode è un carattere a 21 bit che codifica l'univoco descrive "CodePoint" ogni punto codice rappresentato da un glifo (una rappresentazione grafica).
Le codifiche supportate sono:
Ma non importa quale sia la codifica al momento della decodifica, tutti riconducono a un punto di codice specifico che ha lo stesso significato (motivo per cui è interessante).
Questo è un formato di dimensioni variabili. Dove ciascun punto di codice è rappresentato da 1 a 4 byte.
Questo è un formato di dimensioni variabili. I punti di codice sul "Piano multilingue di base" (BMP o Piano 0) possono essere rappresentati da 1 singolo valore a 16 bit. I punti codice su altri piani sono rappresentati da una coppia surrogata (2 valori a 16 bit).
Questo è un formato di dimensioni fisse. Tutti i punti di codice sono rappresentati da un singolo valore a 32 bit.
Penso che sia utile separare le 2 idee:
UTF-8, UTF-16 e altre codifiche presentano vantaggi e svantaggi. Meglio consultare Wikipedia a riguardo.
UTF-7, UTF-8, UTF-16 e UTF-32 sono semplicemente formati di trasformazione algoritmica dello stesso coding (codepoint) di caratteri. Sono codifiche di un sistema di codifica dei caratteri.
Sono anche algoritmicamente più facili da navigare in avanti e indietro rispetto alla maggior parte degli schemi precedenti per gestire set di caratteri più grandi di 256 caratteri.
Questo è molto diverso rispetto alla codifica dei glifi, in genere nazionale e talvolta specifica del fornitore. Solo in giapponese c'erano un sacco di varianti di JIS da solo, per non parlare della EUC-JP e della trasformazione orientata alla codepage di JIS che le macchine DOS / Windows utilizzavano chiamate Shift-JIS. (In una certa misura, ci sono state trasformazioni algoritmiche di questi, ma non erano particolarmente semplici e c'erano differenze specifiche dei vendor nei personaggi disponibili. Moltiplicate questo per un paio di centinaia di paesi e l'evoluzione graduale di sistemi di font più sofisticati (post greenscreen era), e hai avuto un vero incubo.
Perché avresti bisogno di queste forme di trasformazione di Unicode? Poiché molti sistemi legacy assumevano sequenze di caratteri a 7 bit di intervallo ASCII, quindi era necessaria una soluzione pulita a 7 bit che trasmettesse in modo sicuro i dati non corretti attraverso tali sistemi, quindi era necessario UTF-7. Poi c'erano sistemi più moderni che potevano gestire set di caratteri a 8 bit, ma in genere i valori null avevano significati speciali, quindi UTF-16 non funzionava per loro. 2 byte potevano codificare l'intero piano multilingue multilingue di Unicode nella sua prima incarnazione, quindi UCS-2 sembrava un approccio ragionevole per i sistemi che sarebbero stati "Unicode aware da zero" (come Windows NT e Java VM); quindi le estensioni oltre a ciò richiedevano caratteri aggiuntivi, che portavano alla trasformazione algoritmica dei 21 bit di codifica che erano riservati dallo standard Unicode, e nacquero coppie surrogate; che ha richiesto UTF-16. Se avevi qualche applicazione in cui la consistenza della larghezza dei caratteri era più importante dell'efficienza di archiviazione, UTF-32 (una volta chiamato UCS-4) era un'opzione.
UTF-16 è l'unica cosa che è remota da gestire, e che è facilmente mitigata dalla piccola gamma di caratteri che sono interessati da questa trasformazione e dal fatto che le sequenze principali a 16 bit sono ordinatamente in una gamma completamente distinta dalle sequenze finali a 16 bit. È anche più facile mondi che cercare di andare avanti e indietro in molte prime codifiche dell'Asia orientale, dove o hai bisogno di una macchina di stato (JIS e EUC) per gestire le sequenze di escape, o potenzialmente tornare indietro di diversi personaggi finché non hai trovato qualcosa che era garantito essere solo un byte guida (Shift-JIS). UTF-16 ha avuto alcuni vantaggi sui sistemi che potrebbero eseguire il chug attraverso sequenze a 16 bit in modo efficiente.
A meno che non si debbano vivere le dozzine (centinaia, in realtà) di diverse codifiche là fuori, o si debbano costruire sistemi che supportano più lingue in codifiche diverse a volte anche nello stesso documento (come WorldScript nelle vecchie versioni di MacOs), potreste pensare ai formati di trasformazione unicode come a una complessità inutile. Ma è una drammatica riduzione della complessità rispetto alle alternative precedenti e ogni formato risolve un reale vincolo tecnico. Sono anche davvero convertibili in modo efficiente tra loro, senza richiedere tabelle di ricerca complesse.
Unicode non è stato progettato per risolvere l'intero problema di avere molte codifiche differenti.
Unicode è stato progettato per risolvere l'intero problema di un numero che rappresenta molte cose diverse a seconda della code page in uso. I numeri 0 - 127 rappresentano gli stessi caratteri in qualsiasi tabella codici Ansi. Questo è anche noto come grafico ASCII o set di caratteri. Nelle tabelle codici Ansi, che consentono 256 caratteri, i numeri da 128 a 255 rappresentano caratteri diversi in diverse code page.
Ad esempio
Ciò che Unicode ha fatto, è stato girare tutto sottosopra. In Unicode non c'è "riutilizzo". Ogni numero rappresenta un singolo carattere unico. Il numero $ 00A2 in Unicode è il segno del centesimo e il segno del centesimo non appare in nessun altro punto nella definizione Unicode.
Why then are there so many Unicode encodings? Even multiple versions of the (essentially) same one, like UTF-8, UTF-16, etc.
Non ci sono più versioni della stessa codifica. Vi sono più codifiche della stessa mappa di definizione dei caratteri Unicode e queste sono state "inventate" per amministrare i requisiti di archiviazione per usi diversi dei vari piani linguali esistenti in Unicode.
Unicode definisce (o ha lo spazio per definire) 4.294.967.295 caratteri univoci. Se vuoi mapparli su disco / memoria senza effettuare conversioni algoritmiche, hai bisogno di 4 byte per carattere. Se hai bisogno di memorizzare testi con caratteri da tutti i piani linguali, allora UTF-32 (che è fondamentalmente una codifica di archiviazione 1 carattere - 4 byte di default della definizione Unicode) è probabilmente quello che ti serve.
Ma quasi nessun testo usa caratteri di tutti gli aerei linguali. E poi usare 4 byte per personaggio sembra un grande spreco. Soprattutto se si tiene conto del fatto che la maggior parte delle lingue sulla terra sono definite all'interno del cosiddetto piano multi-lingue di base (BMP): i primi 65536 numeri della definizione Unicode.
E quello in cui è entrato UTF-16. Se usi solo caratteri dal BMP, UTF-16 lo memorizzerà in modo molto efficiente usando solo due byte per carattere. Userà solo più byte per i caratteri al di fuori del BMP. La distinzione tra UTF-16 (Little Endian) e UTF-16 BE (Big Endian) in realtà ha solo a che fare con come i numeri sono rappresentati all'interno della memoria del computer (schema di byte A0 significa esadecimale $ A0 o significato $ 0A).
Se il testo utilizza ancora meno caratteri diversi, come la maggior parte dei testi nelle lingue dell'Europa occidentale, è necessario limitare ulteriormente i requisiti di archiviazione per i tuoi testi. Quindi UTF-8, che utilizza un singolo byte per memorizzare i caratteri presenti nel grafico ASCII (i primi 128 numeri) e una selezione dai caratteri Ansi (i secondi 128 numeri delle varie code page). Utilizzerà solo più byte per i caratteri al di fuori di questo set di "caratteri più usati".
Quindi per riassumere:
Unicode definisce la mappa tra numeri e caratteri. Tuttavia, quando si invia un numero a un destinatario, è ancora necessario definire come rappresentare tale numero. Ecco a cosa serve UTF. Definisce come rappresentare un numero in un flusso di byte.
La logica dietro UTF-32 è semplice: è la rappresentazione più semplice dei punti di codice Unicode. Quindi, perché non è tutto in UTF-32? Due ragioni principali:
Uno è taglia . UTF-32 richiede 4 byte per ogni carattere. Per il testo che utilizza solo caratteri in Basic Multilingual Place, questo è il doppio di UTF-16. Per il testo in inglese, è 4 volte più spazio di US-ASCII.
La ragione più grande è retrocompatibilità . Ogni codifica Unicode diversa dall'UTF-32 "non codificata" è stata progettata per la compatibilità all'indietro con uno standard precedente.
I thought Unicode was designed to get around the whole issue of having lots of different encoding
Lo era, e lo è stato. È molto più facile convertire tra UTF-8, -16 e -32 che gestire il vecchio sistema di centinaia di codifiche di caratteri diversi per lingue e sistemi operativi diversi.
Sai che un file zip può comprimere un file per essere molto più piccolo (specialmente il testo) e quindi decomprimerlo su una copia identica del file originale.
L'algoritmo di zipping in realtà ha diversi algoritmi diversi con caratteristiche diverse tra cui scegliere: memorizzati (senza compressione), Ridotti, Ridotti (metodi 1-4), Imploded, Tokenizing, Deflated, Deflate64, BZIP2 , LZMA (EFS), WavPack, PPMd, dove teoricamente potrebbe provarli tutti e scegliere il miglior risultato, ma di solito basta andare su Deflazionato.
UTF funziona allo stesso modo. Esistono diversi algoritmi di codifica ciascuno con caratteristiche diverse, ma di solito si sceglie UTF-8 perché è ampiamente supportato rispetto alle altre varianti UTF, che a sua volta è perché è bitwise compatibile con ASCII a 7 bit che semplifica utilizzare sulla maggior parte delle moderne piattaforme di computer che di solito utilizzano un'estensione di ASCII a 8 bit.
Leggi altre domande sui tag unicode text-encoding