Quando è utile usare codifiche diverse da UTF-8? A parte trattare con documenti pre-unicode, cioè. E, ancora più importante, perché l'UTF-8 non è l'impostazione predefinita nella maggior parte delle lingue? Cioè, perché spesso ho bisogno di impostarlo esplicitamente?
Per una codifica esterna (cioè una codifica di cose che non sono all'interno del tuo programma) è molto difficile da battere UTF-8; supporta ogni carattere che i tuoi utenti potrebbero mai ragionevolmente aver bisogno e c'è molto supporto in molti sistemi operativi e strumenti. (L'unico punto che conta come eccezione è nei nomi dei file, dove è necessario utilizzare le convenzioni della piattaforma se si desidera qualsiasi tipo di interoperabilità.) Fortunatamente, molte piattaforme ora usano UTF-8 per questo motivo, quindi l'avvertimento è discutibile punto lì.)
Per una codifica interna, le cose sono più complesse. Il problema è che un personaggio in UTF-8 non è un numero costante di byte, il che rende ogni tipo di operazione più complessa di quanto si possa sperare. In particolare, l'indicizzazione nella stringa per carattere (un'operazione molto comune quando si esegue l'elaborazione delle stringhe!) Cambia da un'operazione O (1) a un'operazione O (N) e questo può essere un problema di prestazioni molto significativo. Esistono diverse soluzioni alternative, ad esempio l'utilizzo di una struttura dei dati di corda o la conversione della stringa in un formato carattere a larghezza fissa (tipicamente ASCII, ISO 8859-1, UTF-16 o UTF-32, a seconda del valore Unicode massimo dei caratteri nella stringa). I problemi che affliggono tali formati (supporto limitato dei caratteri e / o problemi di endianità) in realtà non si applicano qui perché puoi applicare una trasformazione solo quando è significativa e la stai solo utilizzando come interna codifica.
Non pensare di poter fare a meno di memorizzare quella codifica interna su disco o assegnarla a un altro programma. Potrebbe essere "conveniente" ma è un problema che aspetta di accadere; invia / archivia i dati come UTF-8.
E non dimenticare che ci sono molti dati legacy là fuori, troppo da liquidare. Di particolare interesse sono le varie lingue dell'Asia orientale che hanno codifiche complesse che sono potenzialmente un po 'più corte di UTF-8, quindi risultano in meno pressione per convertire, ma ci sono molte altre questioni che si nascondono anche nei sistemi occidentali. (Non voglio sapere cosa sta succedendo nei principali database bancari ...)
La risposta è che UTF-8 è di gran lunga la migliore codifica per lo scambio di dati general-purpose, ed è quasi obbligatoria se si utilizza uno qualsiasi degli altri protocolli che lo sviluppano (mail, XML, HTML, ecc.). / p>
Tuttavia, UTF-8 è una codifica multi-byte e relativamente nuova, quindi ci sono molte situazioni in cui è una scelta sbagliata. Eccone alcuni.
Codifica interna in Windows / C / C ++ / C # / Java / ObjectiveC. Questi ambienti non supportano internamente UTF-8 (o qualsiasi codifica multibyte). Le stringhe sono rispettivamente ANSI / UCS-2 / UTF-16.
Codice legacy, in particolare C / C ++. Le stringhe sono in genere ANSI / ISO / UTF-16 / UTF-32.
Dati legacy. Ci sono vaste montagne di dati testuali già codificate in un formato a 8 bit, incluse varie code page, JIS, ecc.
I casi rimanenti riguardano l'uso di file di testo. Rimarranno probabilmente un problema purché i vecchi file di testo rimangano popolari. Il punto è che i file di testo non codificano la loro codifica, quindi il lettore e lo scrittore devono fare supposizioni. Sì, c'è qualcosa chiamato un Byte Order Mark ma non è né richiesto né raccomandato per i file UTF-8, quindi qualsiasi file contenente caratteri a 8 bit è di codifica incerta.
Ecco alcuni esempi di file di testo con pochi motivi per consentire o utilizzare UTF-8.
Strumenti software. Cose come sed, awk, tr ecc possono o potrebbero non funzionare con UTF-8. Spesso è più facile non provarci.
compilatori. La maggior parte dei linguaggi per computer sono definiti in termini di ASCII a 7 bit e leggono file di testo in chiaro dal disco, con trucchi speciali per caratteri estesi.
File di registro, protocolli semplici, sistemi incorporati. A volte 7/8 bit ASCII è solo il più semplice.
Non sempre necessario. La maggior parte delle lingue europee può essere codificata nella code page 850 o 1252, con possibili risparmi nello spazio e nella logica codificata.
Confido che molti di questi andranno via nel tempo, ma sono vere ragioni per evitare l'UTF-8 in determinate situazioni fino ad allora.
Leggi altre domande sui tag utf-8 character-encoding text-encoding