byte[] bytes = new byte[] { 1, -1 };
System.out.println(Arrays.toString(new String(bytes, "UTF-8").getBytes("UTF-8")));
System.out.println(Arrays.toString(new String(bytes, "ISO-8859-1").getBytes("ISO-8859-1")));
:encode decode entre la chaîne et l'octet en sortie java
[1, -17, -65, -67]
[1, -1]
pourquoi ???
Votre tableau d'octets n'est pas une chaîne UTF-8 codé valide ... donc la chaîne que vous obtenez de
new String(bytes, "UTF-8")
contient U + 0001 (pour le premier octet) et U + FFFD pour signifier mauvaises données dans le deuxième octet. Lorsque cette chaîne est codée à l'aide de UTF-8, le modèle d'octet s'affiche.
Fondamentalement, vous ne devriez pas essayer d'interpréter des données binaires arbitraires comme si elles étaient codées dans un codage particulier. Si vous souhaitez représenter des données binaires arbitraires sous la forme d'une chaîne, utilisez quelque chose comme base64.
merci Jon. Mais je ne suis pas familier avec base64, comment base64 prend en charge tous les octets en cas de perte de données? – seven
@seven: Je ne sais pas exactement ce que vous voulez dire - mais il convertit les données binaires opaques en ASCII, ce qui est généralement facile à transporter. –
Est-il possible que certains octets, qui ne sont pas inclus dans l'alphabet ASCII, ne puissent pas être convertis en ASCII? Merci. – seven
-1 n'est pas un caractère codé UTF-8 valide. [-17, -65, -67] est probablement la représentation en octets du replacement character qui est substitué.
La chaîne n'est pas un conteneur pour les données binaires. C'est un conteneur pour char. -1 n'est pas une valeur légale pour un caractère. Il n'y a aucune raison pour que ce que vous faites fonctionne. Ergo, ne le fais pas.
http://stackoverflow.com/questions/2544965/why-new-stringbytes-enc-getbytesenc-does-not-return-the-original-byte-array – Bozho