Perché ci sono più codifiche Unicode?

Ho pensato che Unicode fosse progettato per aggirare l'intero problema di avere molte codifiche diverse a causa di un piccolo spazio di indirizzi (8 bit) nella maggior parte dei tentativi precedenti (ASCII, ecc.).

Perché allora ci sono così tante codifiche Unicode? Anche più versioni di (essenzialmente) la 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 usare tre byte per carattere, che è tre volte più di quello a cui erano abituate le persone, quindi non erano disposti ad adottare Unicode. È stato necessario trovare un compromesso: ad esempio UTF-8 è ottimo per il testo 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 una singola tabella di caratteri universali, ma il mercato non l'avrebbe accettata.

Unicode è un carattere a 21 bit che codifica per descrivere in modo univoco "CodePoints" ogni punto di codice rappresentato da un glifo (una rappresentazione grafica).

• 16 bit utilizzati per identificare un punto di codice in un piano (la maggior parte dei punti di codice si trova sul piano 0).
• 5 bit per identificare il piano.

Le codifiche supportate sono:

• UTF-8 (per codificare ciascun punto usando valori a 8 bit)
• UTF-16 (per codificare ogni punto usando valori a 16 bit)
• UTF-32 (per codificare ogni punto usando valori a 32 bit)

Ma non importa quale sia la codifica quando decodifichi tutti mappano indietro a un punto di codice specifico che ha lo stesso significato (motivo per cui è bello).

• 'A' (U + 65)
  UTF-32 => 0x00000041 UTF-16 => 0x0041 UTF-8 => 0x41
• LIGATURE LATIN SMALL OE '(U + 0153)
  UTF-32 => 0x00000153 UTF-16 => 0x0153 UTF-8 => 0xC5 0x93
• Non assegnato (U + 11153)
  UTF-32 => 0x00011153 UTF-16 => 0xD804 0xDD53 UTF-8 => 0xF0 0x91 0x85 0x93

UTF-8

Questo è un formato di dimensioni variabili. Dove ogni punto di codice è rappresentato da 1 a 4 byte.

UTF-16

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 di codice su altri piani sono rappresentati da una coppia surrogata (2 valori a 16 bit).

UTF-32

Questo è un formato a dimensione fissa. Tutti i punti di codice sono rappresentati da un singolo valore a 32 bit.

Penso che sia utile separare le 2 idee:

1. Unicode - mappatura di caratteri provenienti da tutto il mondo per codificare punti.
2. Codifica: mappatura di punti di codice su schemi di bit (UTF-8, UTF-16, ecc.).

UTF-8, UTF-16 e altre codifiche ha i propri vantaggi e svantaggi. Meglio consultare Wikipedia a riguardo.

UTF-7, UTF-8, UTF-16 e UTF-32 sono semplicemente formati di trasformazione algoritmica della stessa codifica (codepoints) di caratteri. Sono codifiche di un sistema di codificazione dei caratteri.

Sono inoltre algoritmicamente più facili da navigare avanti e indietro rispetto alla maggior parte degli schemi precedenti per gestire set di caratteri di dimensioni superiori a 256 caratteri.

Questo è molto diverso dalla codifica dei glifi generalmente specifica per paese e talvolta specifica per il fornitore. Solo nel giapponese, ci sono state molte variazioni di JIS da solo, per non parlare dell'EUC-JP e della trasformazione orientata alla codepage di JIS che le macchine DOS / Windows usavano chiamata Shift-JIS. (In una certa misura, ci sono state trasformazioni algoritmiche di queste, ma non erano particolarmente semplici e c'erano differenze specifiche nei fornitori disponibili per i caratteri. Moltiplicalo per duecento paesi e l'evoluzione graduale di sistemi di font più sofisticati (post greenscreen era), e hai avuto un vero incubo.

Perché dovresti aver bisogno di queste forme di trasformazione di Unicode? Poiché molti sistemi legacy presupponevano sequenze di caratteri a 7 bit dell'intervallo ASCII, quindi era necessaria una soluzione pulita a 7 bit che passasse in modo sicuro i dati non corrotti attraverso tali sistemi, quindi era necessario UTF-7. Quindi c'erano sistemi più moderni in grado di gestire set di caratteri a 8 bit, ma i null generalmente avevano significati speciali per loro, quindi UTF-16 non funzionava per loro. 2 byte potevano codificare l'intero piano multilingue di base di Unicode nella sua prima incarnazione, quindi UCS-2 sembrava un approccio ragionevole per i sistemi che sarebbero stati "Unicode consapevoli da zero" (come Windows NT e Java VM); quindi le estensioni oltre quella necessitavano di caratteri aggiuntivi, che ha portato alla trasformazione algoritmica delle codifiche di 21 bit riservate dallo standard Unicode e sono nate coppie surrogate; che necessitava di UTF-16. Se avevi qualche applicazione in cui la coerenza della larghezza dei caratteri era più importante dell'efficienza della memoria, UTF-32 (una volta chiamata UCS-4) era un'opzione.

UTF-16 è l'unica cosa che è lontanamente complessa da gestire, e che è facilmente mitigata dalla piccola gamma di caratteri che sono interessati da questa trasformazione e dal fatto che le sequenze di piombo a 16 bit sono ordinatamente in una gamma completamente distinta dal finale Sequenze a 16 bit. È anche più semplice dei mondi che cercare di avanzare e retrocedere in molte prime codifiche dell'Asia orientale, dove avevi bisogno di una macchina statale (JIS ed EUC) per gestire le sequenze di fuga, o potenzialmente di spostare indietro di diversi personaggi fino a quando non hai trovato qualcosa che era garantito essere solo un byte iniziale (Shift-JIS). UTF-16 aveva alcuni vantaggi su sistemi che potevano anche eseguire in modo efficiente sequenze a 16 bit.

A meno che tu non debba sopravvivere a dozzine (centinaia, in realtà) di codifiche diverse, o costruire sistemi che supportano più lingue in codifiche diverse a volte anche nello stesso documento (come WorldScript nelle versioni precedenti di MacOs), potresti pensare dei formati di trasformazione unicode come complessità non necessaria. Ma è una drastica riduzione della complessità rispetto alle alternative precedenti e ogni formato risolve un vero vincolo tecnico. Sono inoltre convertibili in modo efficiente tra loro, senza richiedere tabelle di ricerca complesse.

Unicode non è stato progettato per aggirare l'intero problema di avere molte codifiche diverse.

Unicode è stato progettato per aggirare l'intero numero di un numero che rappresenta molte cose diverse a seconda della tabella codici 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 pagine codici Ansi, che consentono 256 caratteri, i numeri 128 - 255 rappresentano caratteri diversi in pagine codici diverse.

Per esempio

• Il numero $ 57 rappresenta una W maiuscola in tutte le pagine di codice, ma
• Il numero $ EC rappresenta il simbolo di inifinità nella tabella codici 437 (US), ma una "LETTERA LATINA PICCOLA N CON CEDILLA" nella tabella codici 775 (Baltico)
• Il segno Cent è il numero $ 9 miliardi nella tabella codici 437, ma il numero 96 nella tabella codici 775

Quello che ha fatto Unicode è stato capovolgerlo. In Unicode non c'è "riutilizzo". Ogni numero rappresenta un singolo carattere unico. Il numero $ 00A2 in Unicode è il segno di centesimo e il segno di centesimo non appare da nessun'altra parte nella definizione Unicode.

Perché allora ci sono così tante codifiche Unicode? Anche più versioni di (essenzialmente) la stessa, come UTF-8, UTF-16, ecc.

Non ci sono più versioni della stessa codifica. Esistono 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 si desidera mapparli alla memoria su disco / memoria senza effettuare conversioni algoritmiche, sono necessari 4 byte per carattere. Se hai bisogno di memorizzare testi con caratteri di tutti i piani linguali, allora UTF-32 (che è fondamentalmente un semplice carattere 1 - codifica di archiviazione a 4 byte della definizione unicode) è probabilmente quello che ti serve.

Ma quasi nessun testo usa caratteri di tutti i piani linguali. E poi usare 4 byte per personaggio sembra un grande spreco. Soprattutto quando si tiene conto del fatto che la maggior parte delle lingue sulla terra sono definite all'interno del cosiddetto piano multilingue di base (BMP): i primi 65536 numeri della definizione Unicode.

Ed è qui che è entrato UTF-16. Se usi solo caratteri del BMP, UTF-16 lo memorizzerà in modo molto efficiente usando solo due byte per carattere. Utilizzerà solo più byte per i caratteri al di fuori del BMP. La distinzione tra UTF-16LE (Little Endian) e UTF-16BE (Big Endian) ha davvero a che fare con il modo in cui i numeri sono rappresentati nella memoria del computer (modello di byte che A0significa hex $ A0 o $ 0A).

Se il tuo testo usa ancora meno caratteri diversi, come la maggior parte dei testi nelle lingue dell'Europa occidentale, vorrai limitare ancora di più i requisiti di archiviazione per i tuoi testi. Da qui 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 tabelle codici). Utilizzerà solo più byte per i caratteri al di fuori di questo set di "caratteri più utilizzati".

Quindi, per ricapitolare:

• Unicode è una mappatura dei personaggi in tutte le lingue sulla terra (e alcuni Klingon per l'avvio) e poi alcuni (matematici, musicali, ecc.) Su un numero univoco.
• Le codifiche sono algoritmi definiti per memorizzare i testi utilizzando i numeri di questa mappa di caratteri univoca nel modo più efficiente possibile, dato l '"utilizzo medio" dei caratteri all'interno dei testi.

Unicode definisce la mappa tra numeri e caratteri. Tuttavia, quando si invia un numero a un destinatario, è comunque necessario definire come rappresentare quel numero. Ecco a cosa serve UTF. Definisce come rappresentare un numero in un flusso di byte.

La logica alla base di UTF-32 è semplice: è la rappresentazione più semplice dei punti di codice Unicode. Quindi perché non è tutto in UTF-32? Due ragioni principali:

Uno è di dimensioni . UTF-32 richiede 4 byte per ogni carattere. Per il testo che utilizza solo caratteri nella posizione multilingue di base, questo è il doppio dello spazio rispetto a UTF-16. Per il testo inglese, è 4 volte più spazio di US-ASCII.

Il motivo principale è la compatibilità con le versioni precedenti . Ogni codifica Unicode diversa dall'UTF-32 "non codificato" è stata progettata per la compatibilità all'indietro con uno standard precedente.

• UTF-8: compatibilità all'indietro con US-ASCII.
• UTF-16: compatibilità all'indietro con UCS-2 (Unicode a 16 bit prima che fosse espanso oltre il BMP).
• UTF-7: compatibilità all'indietro con server di posta non puliti a 8 bit.
• GB18030: compatibilità all'indietro con le codifiche GB2312 e GBK per il cinese.
• UTF-EBCDIC: compatibilità all'indietro con il sottoinsieme latino di base di EBCDIC.

Ho pensato che Unicode fosse progettato per aggirare l'intero problema di avere molte codifiche diverse

Lo era e lo ha fatto. È molto più facile convertire tra UTF-8, -16 e -32 che gestire il vecchio sistema di centinaia di codifiche di caratteri diverse per lingue e sistemi operativi diversi.

Sai che un file zip può comprimere un file in modo che sia molto più piccolo (specialmente testo) e quindi decomprimerlo in una copia identica del file originale.

L'algoritmo zippato in realtà ha diversi algoritmi con diverse caratteristiche tra cui scegliere: memorizzato (nessuna compressione), Ridotto, Ridotto (metodi 1-4), Imploded, Tokenizing, Deflated, Deflate64, BZIP2, LZMA (EFS), WavPack, PPMd, dove teoricamente potrebbe provarli tutti e scegliere il risultato migliore, ma di solito basta andare con Deflated.

UTF funziona più o meno allo stesso modo. Esistono diversi algoritmi di codifica ciascuno con caratteristiche diverse, ma di solito scegli UTF-8 perché è ampiamente supportato rispetto alle altre varianti UTF, che a sua volta è perché è bitally compatibile con ASCII a 7 bit che lo rende facile da utilizzare sulla maggior parte delle piattaforme di computer moderne che di solito utilizzano un'estensione a 8 bit di ASCII.