Pourquoi les noms de charset ne sont pas des constantes?

Deux ans plus tard, et les StandardCharsets de Java 7 définissent maintenant des constantes pour les 6 jeux de caractères standard.

Si vous êtes bloqué sur Java 5/6, vous pouvez utiliser les constantes Charsets de Guava, comme suggéré par Kevin Bourrillion et Jon Skeet.

Je dirais que nous pouvons faire beaucoup mieux que cela... pourquoi les jeux de caractères garantis-à-être-disponibles ne sont-ils pas accessibles directement? Charset.UTF8 devrait être une référence au Charset, pas le nom en tant que chaîne. De cette façon, nous n'aurions pas à gérer UnsupportedEncodingException partout.

Rappelez - vous, je pense aussi que.NET a choisi une meilleure stratégie en utilisant par défaut UTF-8 partout. Il a ensuite foiré en nommant la propriété d'encodage" operating system default " simplement Encoding.Default - qui n'est pas la valeur par défaut sein de .NET lui-même :(

Retour à propos du support du jeu de caractères de Java-pourquoi n'y a-t-il pas de constructeur pour FileWriter/FileReader qui prend un Charset? Fondamentalement, ce sont des classes presque inutiles en raison de cette restriction - vous avez presque toujours besoin d'un InputStreamReader autour d'un FileInputStream ou l'équivalent pour la sortie : (

Infirmière, Infirmière - où est mon médicament?

EDIT: il me semble que cela n'a pas vraiment répondu à la question. La vraie réponse est probablement soit "personne impliqué n'y a pensé" ou "quelqu'un qui pensait que c'était une mauvaise idée."Je suggère fortement que les classes d'utilité internes fournissant les noms ou les jeux de caractères évitent la duplication autour de la base de code... Ou vous pouvez simplement utiliser celui que nous avons utilisé chez Google lorsque cette réponse a été écrite pour la première fois . (Notez qu'à partir de Java 7, vous utiliseriez simplementStandardCharsets au lieu de cela.)

En Java 1.7

import java.nio.charset.StandardCharsets

Ex: StandardCharsets.UTF_8 StandardCharsets.US_ASCII

L'état actuel de l'API d'encodage laisse à désirer. Certaines parties de L'API Java 6 n'acceptent pas Charset à la place d'une chaîne (in logging, dom.ls, PrintStream; Il peut y en avoir d'autres). Cela n'aide pas que les encodages soient supposés avoir des noms canoniques différents pour différentes parties de la bibliothèque standard.

je peux comprendre comment les choses sont arrivées là où elles sont; Je ne suis pas sûr d'avoir des idées brillantes sur la façon de les réparer.

Comme un hormis...

Vous pouvez rechercher les noms de L'implémentation Java 6 de Sun ici .

Pour de l'UTF-8, les canonique valeurs sont "UTF-8" pour java.nio et "UTF8" pour java.lang et java.io. Les seuls encodages que la spécification nécessite un JRE à prendre en charge sont: US-ASCII; ISO-8859-1; UTF-8; UTF-16BE; UTF-16LE; UTF-16.

J'ai depuis longtemps défini une classe utilitaire avec les constantes Utf_8, ISO_8859_1 et US_ASCII Charset.

Aussi, il y a longtemps ( 2+ ans ) j'ai fait un test de performance simple entre new String( byte[], Charset ) et new String( byte[], String charset_name )et j'ai découvert que cette dernière implémentation est considérablement plus rapide. Si vous jetez un oeil sous le capot au code source, vous verrez qu'ils suivent en effet un chemin tout à fait différent.

, Pour cette raison, j'ai inclus un utilitaire dans la même classe

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

Pourquoi le String (byte[], charset ) constructeur ne fait pas la même chose, me bat.