Java 1.6 L'encodage de Windows-1252 échoue sur 3 caractères

Question

EDIT: J'ai été convaincu que cette question est quelque peu non-sensée. Merci à ceux qui ont répondu. Je peux poster une question de suivi plus spécifique.

Aujourd'hui, j'investissais des problèmes d'encodage et écrit ce test unitaire pour isoler une base repro cas:

int badCount = 0; 
for (int i = 1; i < 255; i++) { 
    String str = "Hi " + new String(new char[] { (char) i }); 

    String toLatin1 = new String(str.getBytes("UTF-8"), "latin1"); 
    assertEquals(str, new String(toLatin1.getBytes("latin1"), "UTF-8")); 

    String toWin1252 = new String(str.getBytes("UTF-8"), "Windows-1252"); 
    String fromWin1252 = new String(toWin1252.getBytes("Windows-1252"), "UTF-8"); 

    if (!str.equals(fromWin1252)) { 
     System.out.println("Can't encode: " + i + " - " + str + 
          " - encodes as: " + fromWin1252); 
     badCount++; 
    } 
} 

System.out.println("Bad count: " + badCount); 

La sortie:

 
    Can't encode: 129 - Hi ? - encodes as: Hi ?? 
    Can't encode: 141 - Hi ? - encodes as: Hi ?? 
    Can't encode: 143 - Hi ? - encodes as: Hi ?? 
    Can't encode: 144 - Hi ? - encodes as: Hi ?? 
    Can't encode: 157 - Hi ? - encodes as: Hi ?? 
    Can't encode: 193 - Hi Á - encodes as: Hi ?? 
    Can't encode: 205 - Hi Í - encodes as: Hi ?? 
    Can't encode: 207 - Hi Ï - encodes as: Hi ?? 
    Can't encode: 208 - Hi ? - encodes as: Hi ?? 
    Can't encode: 221 - Hi ? - encodes as: Hi ?? 
    Bad count: 10 

1.6.0_07 sous Mac JDK OS 10.6. Mon

Latin1 symétrique allie encode tous les 254 caractères. Windows-1252 non. Les trois caractères imprimables (193, 205, 207) sont les mêmes codes dans Latin1 et Windows-1252, donc je ne m'attendrais à aucun problème.

Quelqu'un peut-il expliquer ce comportement? Est-ce un bug JDK?

- James

Answer 1

À mon avis, le programme d'essais est profondément erronée, car elle rend les transformations efficacement inutiles entre les chaînes sans signification sémantique.

Si vous voulez vérifier si toutes les valeurs d'octets sont des valeurs valides pour un encodage donné, quelque chose comme cela pourrait être plus comme ça:

public static void tryEncoding(final String encoding) throws UnsupportedEncodingException { 
    int badCount = 0; 
    for (int i = 1; i < 255; i++) { 
     byte[] bytes = new byte[] { (byte) i }; 

     String toString = new String(bytes, encoding); 
     byte[] fromString = toString.getBytes(encoding); 

     if (!Arrays.equals(bytes, fromString)) { 
      System.out.println("Can't encode: " + i + " - in: " + Arrays.toString(bytes) + "/ out: " 
        + Arrays.toString(fromString) + " - result: " + toString); 
      badCount++; 
     } 
    } 

    System.out.println("Bad count: " + badCount); 
} 

Notez que ce programme teste de test entrées en utilisant la (usnigned) valeurs de octet 1 à 255. le code de la question utilise les valeurs char (équivalent à Unicode codets dans cette gamme) de 1 à 255.

Essayez d'imprimer les tableaux d'octets réelles traitées par le programme dans le exemple et vous voyez que vous ne vérifie pas réellement toutes les valeurs d'octets et que certaines de vos "mauvaises" correspondances sont des doublons d'autres.

L'exécution de ce avec "Windows-1252" comme argument produit cette sortie:

 
Can't encode: 129 - in: [-127]/ out: [63] - result: � 
Can't encode: 141 - in: [-115]/ out: [63] - result: � 
Can't encode: 143 - in: [-113]/ out: [63] - result: � 
Can't encode: 144 - in: [-112]/ out: [63] - result: � 
Can't encode: 157 - in: [-99]/ out: [63] - result: � 
Bad count: 5 

Ce qui nous dit que Windows-1252 n'accepte pas l'octet valeurs 129, 1441, 143, 144 et 157 comme des valeurs valides. (Note: je parle de valeurs d'octets non signés ici Le code ci-dessus montre -127, -115, ... parce que Java ne connaît que des octets non signés).

The Wikipedia article on Windows-1252 semble vérifier cette observation en déclarant ceci:

Selon les informations sur Microsoft et les sites Web du Consortium Unicode, les positions 81, 8D, 8F, 90 et 9D ne sont pas utilisés

Answer 2

Ce que votre code fait (String->byte[]->String, deux fois) est à peu près le opposé de transcodage, et n'a aucun sens du tout (il est pratiquement garanti de perdre des données).byte[]->String->byte[] signifie Transcodage:

public byte[] transcode(byte[] input, String inputEnc, String targetEnc) 
{ 
    return new String(input, inputEnc).getBytes(targetEnc); 
} 

Et bien sûr, il va perdre des données lorsque l'entrée contient des caractères que l'encodage cible ne prend pas en charge.