Perché i nomi dei set di caratteri non sono costanti?

I problemi dei set di caratteri sono confusi e complicati da soli, ma soprattutto devi ricordare i nomi esatti dei tuoi set di caratteri. È vero "utf8"? Oppure "utf-8"? O forse "UTF-8"? Durante la ricerca di esempi di codice in Internet vedrai tutto quanto sopra. Perché non solo farli nominare costanti e usarli Charset.UTF8?

La semplice risposta alla domanda è che le stringhe di set di caratteri disponibili variano da piattaforma a piattaforma.

Tuttavia, ci sono sei che devono essere presenti, quindi le costanti avrebbero potuto essere fatte per quelli molto tempo fa. Non so perché non lo fossero.

JDK 1.4 ha fatto una grande cosa introducendo il tipo Charset. A questo punto, non avrebbero più voluto fornire costanti di stringa, poiché l'obiettivo è far sì che tutti utilizzino le istanze di Charset. Quindi perché non fornire le sei costanti Charset standard, quindi? Ho chiesto a Martin Buchholz poiché è seduto proprio accanto a me, e mi ha detto che non c'era un motivo davvero eccezionale, tranne per il fatto che all'epoca le cose erano ancora cotte a metà - troppo poche API JDK erano state adattate accetta Charset, e di quelli che erano, i sovraccarichi di Charset di solito andavano leggermente peggio.

È triste che solo in JDK 1.6 abbiano finalmente finito di attrezzare tutto con i sovraccarichi di Charset. E che questa situazione di prestazioni all'indietro esiste ancora (il motivo per cui è incredibilmente strano e non posso spiegarlo, ma è legato alla sicurezza!).

Per farla breve: basta definire le proprie costanti o utilizzare la classe Charsets di Guava a cui Tony the Pony collegava (anche se quella libreria non è ancora stata rilasciata).

Aggiornamento: una StandardCharsetsclasse è in JDK 7.

Due anni dopo, e StandardCharsets di Java 7 ora definisce le costanti per i 6 set di caratteri standard.

Se sei bloccato su Java 5/6, puoi usare le costanti Charsets di Guava , come suggerito da Kevin Bourrillion e Jon Skeet.

Direi che possiamo fare molto meglio di così ... perché i set di caratteri garantiti per essere disponibili sono accessibili direttamente? Charset.UTF8dovrebbe essere un riferimento a Charset, non il nome come stringa. In questo modo non dovremmo gestireUnsupportedEncodingException tutto il posto.

Intendiamoci, penso anche che .NET abbia scelto una strategia migliore in modo predefinito su UTF-8 ovunque. Quindi ha rovinato nominando semplicemente la proprietà di codifica "default del sistema operativo" Encoding.Default- che non lo è il valore predefinito all'interno di .NET stesso :(

Tornando al ranting sul supporto del set di caratteri Java - perché non esiste un costruttore per FileWriter/ FileReaderche richiede un Charset? Fondamentalmente quelle sono classi quasi inutili a causa di quella restrizione - quasi sempre hai bisogno di un InputStreamReadergiro aFileInputStream o all'equivalente per l'output :(

Infermiera, infermiera - dov'è la mia medicina?

EDIT: Mi viene in mente che questo non ha veramente risposto alla domanda. La vera risposta è presumibilmente o "nessuno coinvolto ci pensava" o "qualcuno coinvolto pensava che fosse una cattiva idea". Suggerirei vivamente che le classi di utilità interne che forniscono i nomi o i set di caratteri evitino la duplicazione attorno alla base di codice ... O potresti semplicemente usare quello che abbiamo usato su Google quando questa risposta è stata scritta per la prima volta . (Nota che a partire da Java 7, StandardCharsetsinvece , useresti semplicemente .)

In Java 1.7

import java.nio.charset.StandardCharsets

ex: StandardCharsets.UTF_8 StandardCharsets.US_ASCII

Lo stato corrente dell'API di codifica lascia a desiderare. Alcune parti del Java 6 API non accettano Charsetin luogo di una stringa (in logging, dom.ls, PrintStream, ci possono essere altri). Non aiuta il fatto che le codifiche dovrebbero avere nomi canonici diversi per le diverse parti della libreria standard.

Posso capire come le cose sono arrivate dove sono; non sono sicuro di avere idee geniali su come risolverli.

A parte ...

Puoi cercare i nomi per l'implementazione Java 6 di Sun qui .

Per UTF-8, i valori canonici sono "UTF-8"per java.nioe "UTF8"per java.lange java.io. Le uniche codifiche che la specifica richiede un JRE per supportare sono: US-ASCII; ISO-8859-1; UTF-8; UTF-16 BE; UTF-16; UTF-16 .

Molto tempo fa ho definito una classe di utilità con costanti Charset UTF_8, ISO_8859_1 e US_ASCII.

Inoltre, molto tempo fa (più di 2 anni) ho fatto un semplice test delle prestazioni tra new String( byte[], Charset )e ho new String( byte[], String charset_name )scoperto che quest'ultima implementazione è CONSIDERABILE più veloce. Se dai un'occhiata sotto il cofano al codice sorgente vedrai che effettivamente seguono un percorso piuttosto diverso.

Per questo motivo ho incluso un'utilità nella stessa classe

public static String stringFromByteArray (
    final byte[] array,
    final Charset charset
)
{
    try
    {
        return new String( array, charset.name( ) )
    }
    catch ( UnsupportedEncodingException ex )
    {
        // cannot happen
    }
}

Perché il costruttore String (byte [], Charset) non fa lo stesso, mi batte.