Differenze di formato Unicode, UTF, ASCII, ANSI

470

Scendendo l'elenco:

" Unicode " non è una codifica, anche se sfortunatamente molta documentazione la utilizza in modo impreciso per fare riferimento a qualsiasi codifica Unicode utilizzata da quel determinato sistema per impostazione predefinita. Su Windows e Java, questo spesso significa UTF-16; in molti altri posti, significa UTF-8. Correttamente, Unicode si riferisce al set di caratteri astratto stesso, non a una particolare codifica.
UTF-16 : 2 byte per "unità di codice". Questo è il formato nativo delle stringhe in .NET e generalmente in Windows e Java. I valori al di fuori del piano multilingue di base (BMP) sono codificati come coppie surrogate. Questi venivano usati relativamente raramente, ma ora molte applicazioni per i consumatori dovranno essere consapevoli dei caratteri non BMP per supportare gli emoji.
UTF-8 : codifica a lunghezza variabile, 1-4 byte per punto di codice. I valori ASCII sono codificati come ASCII usando 1 byte.
UTF-7 : solitamente utilizzato per la codifica della posta. Le probabilità sono che se pensi di averne bisogno e non stai facendo posta, ti sbagli. (Questa è solo la mia esperienza di persone che pubblicano post in newsgroup ecc.
UTF-32 : codifica a larghezza fissa usando 4 byte per punto di codice. Questo non è molto efficiente, ma semplifica la vita al di fuori del BMP. Ho una Utf32Stringclasse .NET come parte della mia libreria MiscUtil , se mai lo desideri. (Non è stato testato a fondo, intendiamoci.)
ASCII : codifica a byte singolo utilizzando solo i 7 bit inferiori. (Codice Unicode punti 0-127.) Nessun accento ecc.
ANSI: Non esiste una codifica ANSI fissa, ce ne sono molte. Di solito quando la gente dice "ANSI" intendono "la localizzazione / codepage predefinita per il mio sistema" che si ottiene tramite Encoding.Default , ed è spesso Windows-1252 ma può essere anche in altre lingue.

C'è di più sulla mia pagina Unicode e suggerimenti per il debug dei problemi Unicode .

L'altra grande risorsa di codice è unicode.org che contiene più informazioni di quante tu riuscirai mai ad affrontare - probabilmente il bit più utile sono i grafici di codice .

— Jon Skeet
fonte

Il termine "ANSI" quando applicato alle code page di Microsoft a 8 bit è un termine improprio. Si basavano su progetti sottoposti a standardizzazione ANSI, ma ANSI stesso non li ha mai standardizzati. Windows-1252 (la tabella codici più comunemente denominata "ANSI") è simile a ISO 8859-1 (latino-1), tranne per il fatto che Windows-1252 ha caratteri stampabili nell'intervallo 0x80..0x9F, dove ISO 8859-1 ha caratteri di controllo in quell'intervallo. Unicode ha anche caratteri di controllo in quell'intervallo. en.wikipedia.org/wiki/Windows_code_page

— Keith Thompson,

@ jp2code: Non lo farei, ma devi distinguere tra "contenuto inviato via HTTP dal server web" e "contenuto inviato via email". Non è il contenuto della pagina Web che invia l'e-mail - è l'app dietro di essa, presumibilmente. Il contenuto web sarebbe il migliore in UTF-8; il contenuto della posta potrebbe essere in UTF-7, anche se sospetto che vada bene conservarlo in UTF-8 in questi giorni.

— Jon Skeet,

Per UTF-16, IMHO, direi "2 byte per unità di codice" poiché un punto di codice esterno al BMP verrà codificato in coppie surrogate come 2 unità di codice (4 byte).

— Ludovic Kuty,

Manca le differenze tra UTF-16LE (all'interno di .NET) e BE, nonché la nozione di distinta base.

— Maarten Bodewes,

@Andrew: No, non esiste un marcatore di codifica (generale). Windows 1252 non può rappresentare la distinta componenti Unicode e non avrebbe senso in quanto è comunque solo una codifica a un byte per carattere.

— Jon Skeet,

Alcune letture per iniziare con la codifica dei caratteri: Joel on Software: il minimo assoluto Ogni sviluppatore di software deve assolutamente conoscere positivamente gli Unicode e i set di caratteri (niente scuse!)

A proposito: ASP.NET non ha nulla a che fare con esso. Le codifiche sono universali.

— Tomalak
fonte

Risposto qui 6 anni dopo la stesura dell'articolo. L'ho letto 8 anni dopo che il post è stato scritto. 14 anni dopo ed è ancora una buona lettura. È più della metà della mia vita fa. Incredibile.

— Dave Knise,