Perché UTF-8 spreca diversi bit nella sua codifica

Secondo l' articolo di Wikipedia , UTF-8 ha questo formato:

Primo codice Ultimo codice Byte Byte 1 Byte 2 Byte 3 Byte 4
punto punto Usato
U + 0000 U + 007F 1 0xxxxxxx
U + 0080 U + 07FF 2 110xxxxx 10xxxxxx
U + 0800 U + FFFF 3 1110xxxx 10xxxxxx 10xxxxxx
U + 10000 U + 1FFFFF 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
x indica che questo bit viene utilizzato per selezionare il punto di codice.

In questo modo si sprecano due bit per ogni byte di continuazione e un bit nel primo byte. Perché UTF-8 non è codificato come il seguente?

Primo codice Ultimo codice Byte Byte 1 Byte 2 Byte 3
punto punto Usato
U + 0000 U + 007F 1 0xxxxxxx
U + 0080 U + 3FFF 2 10xxxxxx xxxxxxxx
U + 0800 U + 1FFFFF 3 110xxxxx xxxxxxxx xxxxxxxx

Si risparmia un byte quando il punto di codice è fuori dal piano multilingue di base o se il punto di codice è compreso nell'intervallo [U + 800, U + 3FFF].

Perché UTF-8 non è codificato in modo più efficiente?

Questo viene fatto in modo che tu possa rilevare quando ti trovi nel mezzo di una sequenza multi-byte. Quando guardi i dati UTF-8, sai che se vedi 10xxxxxx, sei nel mezzo di un carattere multibyte e dovresti eseguire il backup nello stream finché non vedi uno 0xxxxxxo 11xxxxxx. Usando il tuo schema, i byte 2 o 3 potrebbero facilmente finire con schemi come o 0xxxxxxxo11xxxxxx

Inoltre, tieni presente che la quantità di dati salvati varia completamente in base al tipo di dati stringa che stai codificando. Per la maggior parte del testo, anche asiatico, vedrai raramente, se mai, caratteri a quattro byte con testo normale. Inoltre, le stime ingenue della gente su come apparirà il testo sono spesso sbagliate. Ho testo localizzato per UTF-8 che include stringhe giapponesi, cinesi e coreane, ma in realtà è il russo a occupare più spazio. (Perché le nostre stringhe asiatiche hanno spesso caratteri romani intervallati da nomi propri, punteggiatura e simili e perché la parola cinese media è 1-3 caratteri mentre la parola russa media è molte, molte altre.)

Il modo ufficiale fa sapere al decoder quando si trova nel mezzo della tupla e sa saltare i byte (o tornare indietro) fino a quando il byte inizia con 0o 11; questo impedisce i valori di garbage quando un singolo byte viene danneggiato.

Risposta breve, la proposta non distingue tra il primo byte e i byte di continuazione.

Il modello di bit all'estremità superiore del primo byte indica con quanti byte viene creato il carattere effettivo. Questi schemi forniscono anche un certo riconoscimento degli errori durante l'analisi di una stringa. Se stai leggendo (apparentemente) il primo byte di un personaggio e ottieni 10xxxxxx, sai che non sei sincronizzato.

Ciò che non è stato menzionato è che se hai una sequenza corretta di punti di codice e un puntatore che è garantito per puntare al primo byte di un punto di codice, con UTF-8 puoi trovare facilmente il puntatore al primo byte del punto di codice precedente (salta tutti i byte che iniziano con 01xx xxxx). Con la tua codifica, è impossibile senza esaminare potenzialmente tutti i byte fino all'inizio della stringa.

Considera le sequenze di (2n + 2) byte

0xxxxxxx
n times (10xxxxxx, 10xxxxxx)
0xxxxxxx

e

n times (10xxxxxx, 10xxxxxx)
(10xxxxxx, 0xxxxxxx)

Se si dispone di un puntatore al primo byte del primo punto di codice dopo questa sequenza, è necessario esaminare tutti i byte per scoprire se l'ultimo punto di codice è 0xxxxxxx o (10xxxxxx, 0xxxxxxx).

Esistono in realtà schemi di codifica più efficienti, in cui è possibile passare al punto di codice precedente in tempo costante e è possibile correggere i puntatori al centro di un punto di codice. Consenti i seguenti codici:

X where X < 128
YX where 128 ≤ Y < 236, X < 128
ZYY where 236 ≤ Z < 256, 0 ≤ Y < 236. 

Se uno dei tre byte precedenti è ≥ 236, allora è l'inizio di una sequenza di 3 byte, poiché non possono esserci due byte di questo tipo all'interno di una sequenza valida di 3 byte. Altrimenti, se uno dei due byte precedenti è ≥ 128, allora è l'inizio di una sequenza di due byte. Altrimenti, il byte precedente è un singolo byte <128.

La ricerca di una sottostringa diventa leggermente più difficile. È possibile che si desideri escludere zero byte in modo che una stringa contenga un byte zero solo se contiene un punto di codice zero.