ByteBuffer, CharBuffer, et le jeu de caractères de la Chaîne

Je suis en train de faire le tri des personnages, de leur représentation dans les séquences d'octets selon les jeux de caractères, et la façon de convertir à partir d'un jeu de caractères à un autre en Java. J'ai quelques difficultés.

Par exemple,

ByteBuffer bybf = ByteBuffer.wrap("Olé".getBytes());

Ma compréhension est que:

Chaîne sont toujours stockées en tant que UTF-16 séquence d'octets en Java (2 octets par caractère, big endian)
getBytes() résultat est le même UTF-16 séquence d'octets
wrap() maintient cette séquence
bybf est donc un UTF-16 big endian représentation de la chaîne de Olé

Donc dans ce code:

Charset utf16 = Charset.forName("UTF-16");  
CharBuffer chbf = utf16.decode(bybf);  
System.out.println(chbf);

decode() devrait

Interpréter bybf comme UTF-16 représentation de chaîne
"convertir" à la chaîne d'origine Olé.

Fait pas d'octet doit être modifié depuis tout est en UTF-16 stockées et UTF-16 Charset devrait être une sorte de "neutre" d'opérateur. Cependant, le résultat est imprimé en tant que:

??

Comment peut-il être?

Question supplémentaire: Pour convertir correctement, il semble Charset.decode(ByteBuffer bb) nécessite bb être un UTF-16 big endian séquence d'octets de l'image d'une chaîne. Est-ce exact?

Modifier: à Partir des réponses fournies, j'ai fait quelques tests pour imprimer un ByteBuffer contenu et la chars obtenu par décodage. Octets [encodage ="Olé".getBytes(charsetName)] sont imprimés sur la première ligne de groupes, l'autre ligne(s) sont les chaînes obtenues par le décodage arrière les octets [avec Charset#decode(ByteBuffer)] avec divers Charset.

J'ai aussi confirmé que le codage par défaut pour le stockage de la Chaîne byte[] sur un ordinateur Windows 7 est windows-1252 (à moins contiennent des chaînes de caractères nécessitant UTF-8).

Default VM encoding: windows-1252  
Sample string: "Olé"  


  getBytes() no CS provided : 79 108 233  <-- default (windows-1252), 1 byte per char
     Decoded as windows-1252: Olé         <-- using the same CS than getBytes()
           Decoded as UTF-16: ??          <-- using another CS (doesn't work indeed)

  getBytes with windows-1252: 79 108 233  <-- same than getBytes()
     Decoded as windows-1252: Olé

         getBytes with UTF-8: 79 108 195 169  <-- 'é' in UTF-8 use 2 bytes
            Decoded as UTF-8: Olé

        getBytes with UTF-16: 254 255 0 79 0 108 0 233 <-- each char uses 2 bytes with UTF-16
           Decoded as UTF-16: Olé                          (254-255 is an encoding tag)

InformationsquelleAutor mins | 2014-06-29

8

Vous êtes la plupart du temps correct.

Le natif de représentation des caractères en java est UTF-16. Cependant lors de la conversion de caractères d'octets que vous spécifier le jeu de caractères que vous utilisez, ou le système utilise par défaut c'est ce qui a généralement été UTF-8 chaque fois que j'ai vérifié. Cela donnera des résultats intéressants si vous êtes le mélange et l'appariement.

eg pour mon système, le suivant
```
System.out.println(Charset.defaultCharset().name());
ByteBuffer bybf = ByteBuffer.wrap("Olé".getBytes());
Charset utf16 = Charset.forName("UTF-16");
CharBuffer chbf = utf16.decode(bybf);
System.out.println(chbf);
bybf = ByteBuffer.wrap("Olé".getBytes(utf16));
chbf = utf16.decode(bybf);
System.out.println(chbf);
```
produit

UTF-8

佬쎩

Olé

Donc cette partie n'est exacte que si l'UTF-16 est le jeu de caractères par défaut

getBytes() result is this same UTF-16 byte sequence.

Donc soit toujours spécifier le jeu de caractères que vous utilisez qui est la plus sûre que vous saurez toujours ce qui se passe, ou de toujours utiliser la valeur par défaut.
- la plupart des systèmes windows ne pas par défaut est utf-8. aussi, vous ne savez pas ce que vous entendez par "UTF-16 "ish". java utilise l'UTF-16.
- Grâce BevynQ. Je suis actuellement en apprentissage de Java, votre démonstration a été très utile pour moi.
- mon défaut CS a été windows-1252 jusqu'à ce que j'ai changé l'exemple de la chaîne de "I♥café". L'ajout du cœur Java passer à l'UTF-8. Très éducatif.
InformationsquelleAutor BevynQ
7

Chaîne sont toujours stockées en tant que UTF-16 séquence d'octets en Java (2 octets par caractère, big endian)

Oui.

getBytes() le résultat est cette même UTF-16 séquence d'octets

Pas. Il code pour l'UTF-16 caractères dans la plate-forme de jeu de caractères par défaut, tout ce qui est. Déconseillé.

wrap() soutient cette séquence

wrap() maintient tout.

bybf est donc un UTF-16 big endian représentation de la chaîne Olé

Pas. Elle enveloppe la plate-forme de l'encodage par défaut de la chaîne d'origine.
decode() devrait
- Interpréter bybf comme UTF-16 représentation de chaîne
Non, voir ci-dessus.
- "convertir" à la chaîne d'origine Olé.
Pas moins que la plate-forme de l'encodage par défaut est "UTF-16".
- Merci pour la réponse détaillée. J'aurais sélectionné comme l'un correct trop si il était possible de sélectionner plusieurs réponses. getBytes() n'est pas encore obsolète, mais il est découragé.
- href="https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#getBytes--" >Chaîne de caractères.getBytes() c'est en effet obsolète. Voir la Javadoc. Il ya un couple de surcharges qui ne le sont pas, mais vous n'êtes pas les utiliser.
- La seule #getBytes() est obsolète est public void getBytes(int srcBegin, int srcEnd, byte[] dst, int dstBegin), toutes les autres versions surchargées de cette méthode (y compris le sans arguments) ne sont pas obsolètes.
InformationsquelleAutor user207421

J'ai eu presque le même problème avec les données codées en double-byte charset.
Réponse 3 ci-dessus contient déjà l'essentiel des pièges que vous devriez garder un oeil sur.

Définir un jeu de caractères pour le codage de source.
Définir un jeu de caractères que pour la cible de codage, si elle est différente de votre système d'encodage.

Code suivant fonctionne

public static String convertUTF16ToString(byte[] doc)
{
    final Charset doublebyte = StandardCharsets.UTF_16;
    //Don't need this because it is my local (system default).  
    //final Charset ansiCharset = StandardCharsets.ISO_8859_1;

    final CharBuffer encoded = doublebyte.decode(ByteBuffer.wrap(doc));
    StringBuffer sb = new StringBuffer(encoded);
    return sb.toString();        
}

Remplacer le système par défaut par votre favori encodage.

public static String convertUTF16ToUTF8(byte[] doc)
{
    final Charset doublebyte = StandardCharsets.UTF_16; 
    final Charset utfCharset = StandardCharsets.UTF_8; 
    final Charset ansiCharset = StandardCharsets.ISO_8859_1;

    final CharBuffer encoded1 = doublebyte.decode(ByteBuffer.wrap(doc));
    StringBuffer sb = new StringBuffer(encoded1);
    final byte[] result = ansiCharset.encode(encoded1).array();
    //alternative to utf-8
    //final byte[] result = utfCharset.encode(encoded1).array();

    return new String(result);        
}

Réponse 3 " est vide de sens. Veuillez fournir un auteur ou d'un lien.

InformationsquelleAutor Wolf

Vous devez vous connecter pour publier un commentaire.