Informazioni sulle codifiche

Articolo
09/12/2008

Aggiornamento: novembre 2007

Internamente .NET Framework archivia il testo come Unicode UTF-16. Un codificatore trasforma tali dati di testo in una sequenza di byte. Un decodificatore trasforma una sequenza di byte in questo formato interno. Una codifica descrive le regole in base alle quali opera un codificatore o un decodificatore. La classe UTF8Encoding ad esempio descrive le regole per la codifica e la decodifica da una sequenza di byte che rappresenta testo come Unicode UTF-8. Nella codifica e nella decodifica possono anche essere inclusi alcuni passaggi di convalida. La classe UnicodeEncoding ad esempio verifica tutti i surrogati per assicurarsi che costituiscano coppie di surrogati valide. Entrambe queste classi ereditano dalla classe Encoding.

Scelta di una codifica

Secondo lo standard Unicode viene assegnato un punto di codice (un numero) a ciascun carattere in ogni script supportato. Il formato UTF (Unicode Transformation Format) consente di codificare tale punto di codice. Per ulteriori informazioni sui formati UTF supportati dalle classi in System.Text, vedere Uso della codifica Unicode in Unicode in .NET Framework.

Selezione di una classe di codifica

La classe Encoding è molto generica. Le classi supportate che ereditano da Encoding consentono alle applicazioni .NET di utilizzare le codifiche comuni probabilmente presenti nelle applicazioni preesistenti e accettano l'implementazione di codifiche aggiuntive. Quando si ha la possibilità di scegliere una codifica è tuttavia consigliabile utilizzare una codifica Unicode, in genere UTF8Encoding o UnicodeEncoding. È supportata anche la codifica UTF32Encoding. In particolare, la codifica UTF8Encoding è da preferire a ASCIIEncoding. Se il contenuto è ASCII, le due codifiche sono identiche, ma la codifica UTF8Encoding può anche rappresentare tutti i caratteri Unicode. La codifica ASCIIEncoding, invece, supporta soltanto i valori dei caratteri Unicode tra U+0000 e U+007F. Poiché ASCIIEncoding non fornisce il rilevamento degli errori, UTF8Encoding garantisce anche una maggiore sicurezza.

UTF8Encoding è stata ottimizzata in modo da essere il più veloce possibile e dovrebbe essere più rapida di qualsiasi altra codifica. Anche se il contenuto è interamente ASCII, le operazioni eseguite con UTF8Encoding risultano più veloci delle operazioni eseguite con ASCIIEncoding. Prendere in considerazione l'eventualità di utilizzare la codifica ASCIIEncoding solo per alcune applicazioni preesistenti. Anche in questo caso, UTF8Encoding può rappresentare comunque la scelta migliore. Supponendo l'utilizzo delle impostazioni predefinite, possono verificarsi i seguenti scenari:

Se l'applicazione dispone di contenuto non completamente ASCII e viene eseguita la codifica con ASCIIEncoding, ogni carattere non ASCII viene codificato come punto interrogativo ("?"). La successiva decodifica di tali dati da parte dell'applicazione provoca la perdita delle informazioni.
Se l'applicazione dispone di contenuto non completamente ASCII e viene eseguita la codifica con UTF8Encoding, il risultato appare incomprensibile se interpretato come ASCII. Con la successiva decodifica di tali dati da parte dell'applicazione, tuttavia, viene eseguito un round trip corretto.

Scelta di una strategia di fallback

Quando un'applicazione tenta di codificare o decodificare un carattere in assenza di mapping è necessario implementare una strategia di fallback, ovvero un meccanismo di gestione degli errori. Esistono due tipi di strategie di fallback:

Fallback con mapping più appropriato

Quando i caratteri non hanno una corrispondenza esatta nella codifica o decodifica di destinazione, l'applicazione può tentare di eseguirne il mapping a un carattere simile.
Fallback con stringa di sostituzione

In assenza di un carattere simile appropriato l'applicazione può specificare una stringa di sostituzione.

L'applicazione ad esempio può chiamare GetEncoding(1252, 0, 0) (vedere GetEncoding). In questo modo viene indicata la tabella codici 1252, ovvero la tabella codici di Windows per le lingue dell'Europa occidentale, con gli oggetti encoderFallback e decoderFallback specificati come zero. Il comportamento predefinito prevede l'utilizzo del mapping più appropriato per alcuni caratteri Unicode. Il carattere CIRCLED LATIN CAPITAL LETTER S (U+24C8), ad esempio, viene trasformato in LATIN CAPITAL LETTER S (U+0053) prima della codifica. Il carattere SUPERSCRIPT FIVE (U+2075) viene invece trasformato in DIGIT FIVE (U+0035). Se l'applicazione effettua quindi la decodifica dalla tabella codici 1252 a Unicode, il cerchio intorno alla lettera viene rimosso e 2⁵ diventa 25. Altre conversioni potrebbero essere persino più estreme. Il simbolo INFINITY Unicode (U+221E) ad esempio, potrebbe essere mappato a DIGIT EIGHT (U+0038).

Le strategie di fallback con mapping più appropriato variano per tabelle codici diverse e non vengono trattate in dettaglio. Per alcune tabelle codici, ad esempio, i caratteri dell'alfabeto latino a larghezza intera vengono mappati a caratteri dello stesso alfabeto a metà larghezza più comuni. Per altre tabelle codici tale mapping non ha luogo.

Anche applicando una strategia di fallback con mapping più appropriato particolarmente aggressiva, per alcuni caratteri in determinate codifiche non esiste una corrispondenza adatta immaginabile. Un ideogramma cinese, ad esempio, non ha alcun mapping ragionevole alla tabella codici 1252. In tal caso, verrà utilizzata una stringa di sostituzione. Per impostazione predefinita, questa stringa è costituita semplicemente da un solo carattere QUESTION MARK (U+003F).

Il mapping più appropriato è il comportamento predefinito per Encoding, che codifica i dati Unicode in dati della tabella codici, e vi sono applicazioni preesistenti che si basano su tale comportamento. La maggior parte delle nuove applicazioni deve tuttavia evitare questo tipo di comportamento per motivi di sicurezza. Le applicazioni, ad esempio, devono evitare di sottoporre i nomi di dominio a una codifica con mapping più appropriato.

Per il mapping più appropriato le applicazioni hanno a disposizione unicamente le alternative seguenti:

Utilizzare solo codifiche Unicode (UTF8Encoding, UnicodeEncoding e UTF32Encoding) per evitare problemi di fallback.

Attenzione:
Tecnicamente, UTF7Encoding è una codifica Unicode, ma risulta meno affidabile e meno protetta delle altre codifiche. In alcune situazioni il cambiamento di un bit può alterare radicalmente l'interpretazione di un'intera stringa UTF-7. In altre situazioni stringhe UTF-7 sostanzialmente diverse possono codificare lo stesso testo. Evitare pertanto di utilizzare UTF-7 quando si ha la possibilità di scegliere. Il formato UTF-8 è da preferire a UTF-7.

Tecnicamente, UTF7Encoding è una codifica Unicode, ma risulta meno affidabile e meno protetta delle altre codifiche. In alcune situazioni il cambiamento di un bit può alterare radicalmente l'interpretazione di un'intera stringa UTF-7. In altre situazioni stringhe UTF-7 sostanzialmente diverse possono codificare lo stesso testo. Evitare pertanto di utilizzare UTF-7 quando si ha la possibilità di scegliere. Il formato UTF-8 è da preferire a UTF-7.

Utilizzare EncoderExceptionFallback e DecoderExceptionFallback, che generano un'eccezione (rispettivamente EncoderFallbackException e DecoderFallbackException), se un carattere non viene mappato esattamente.
Utilizzare sempre EncoderReplacementFallback e DecoderReplacementFallback per applicare una stringa di sostituzione se un carattere non viene mappato esattamente. Questo è il comportamento predefinito per ASCIIEncoding. Per impostazione predefinita, questa stringa è costituita unicamente da un punto interrogativo, ma vengono forniti metodi che consentono a un'applicazione di scegliere una stringa diversa. Anche se in genere si tratta di un singolo carattere, non è un requisito. Per DecoderReplacementFallback, utilizzato durante la trasformazione di testo in Unicode, un carattere utilizzato comunemente è REPLACEMENT CHARACTER (U+FFFD).
Utilizzare un oggetto EncoderFallback e/o DecoderFallback personalizzato per implementare una strategia preferita. Per informazioni, vedere Esempio di applicazione per la codifica di fallback.

Di seguito sono riportate altre due note relative alle strategie di fallback per la codifica o decodifica con mapping più appropriato:

L'individuazione del mapping più appropriato è soprattutto un problema di codifica, non di decodifica. Il numero delle tabelle codici che contengono caratteri che non possono essere mappati correttamente in Unicode è veramente limitato. Tali caratteri sono stati omessi da Unicode poiché non vengono utilizzati comunemente.
Non sono supportati oggetti denominati corrispondenti ai fallback con mapping più appropriato, che sono distinti per ciascuna tabella codici. Se l'applicazione deve poter passare dal mapping più appropriato a un altro tipo di fallback e viceversa per un singolo oggetto Encoding, è opportuno che venga creata una copia dell'oggetto più appropriato originale in una variabile prima dell'assegnazione di qualsiasi altro oggetto di fallback. L'applicazione ha quindi la possibilità di recuperare il fallback con mapping più appropriato assegnando di nuovo tale valore a Encoding.EncoderFallback o Encoding.DecoderFallback.