Conversion de codage en Java

Question

Existe-t-il une librairie java gratuite que je peux utiliser pour convertir une chaîne de caractères en un encodage en un autre encodage, quelque chose comme iconv en php? J'utilise Java version 1.3.

Answer 1

Vous n'avez pas besoin d'une bibliothèque au-delà d'une norme - il suffit d'utiliser Charset. (Vous pouvez simplement utiliser les méthodes String constructors et getBytes, mais personnellement, je n'aime pas travailler avec les noms des encodages de caractères .. Trop de place pour les fautes de frappe.)

EDIT: Comme indiqué dans les commentaires, vous pouvez toujours utilisez les instances Charset, mais ayez la facilité d'utilisation des méthodes String: new String(bytes, charset) et String.getBytes(charset).

Answer 2

CharsetDecoder devrait être ce que vous cherchez, non? De nombreux protocoles et fichiers réseau stockent leurs caractères avec un jeu de caractères orienté octet, tel que ISO-8859-1 (ISO-Latin-1).
Toutefois, le codage de caractères natif de Java est Unicode UTF16BE (format de transformation UCS à seize bits, ordre des octets big-endian).

Voir Charset. Cela ne signifie pas UTF16 est le jeu de caractères par défaut (par exemple: la valeur par défaut « correspondance entre les séquences de seize bits Unicode code units et des séquences d'octets »):

Chaque instance de la machine virtuelle Java a un jeu de caractères par défaut , qui peut ou peut ne pas être l'un des charsets standard.
[US-ASCII, ISO-8859-1ISO-LATIN-1 a.k.a., UTF-8, UTF-16BE, UTF-16LE, UTF-16]
Le jeu de caractères par défaut est déterminée lors du démarrage de machine virtuelle et dépend généralement de la locale et charset utilisé par le système d'exploitation sous-jacent.

Cet exemple montre comment convertir ISO-8859-1 octets codés dans un ByteBuffer à une chaîne dans un CharBuffer et vice versa.

// Create the encoder and decoder for ISO-8859-1 
Charset charset = Charset.forName("ISO-8859-1"); 
CharsetDecoder decoder = charset.newDecoder(); 
CharsetEncoder encoder = charset.newEncoder(); 

try { 
    // Convert a string to ISO-LATIN-1 bytes in a ByteBuffer 
    // The new ByteBuffer is ready to be read. 
    ByteBuffer bbuf = encoder.encode(CharBuffer.wrap("a string")); 

    // Convert ISO-LATIN-1 bytes in a ByteBuffer to a character ByteBuffer and then to a string. 
    // The new ByteBuffer is ready to be read. 
    CharBuffer cbuf = decoder.decode(bbuf); 
    String s = cbuf.toString(); 
} catch (CharacterCodingException e) { 
} 

Answer 3

C'est beaucoup plus facile si vous considérez unicode comme un jeu de caractères (ce qu'il est réellement - il s'agit essentiellement de l'ensemble numéroté de tous les caractères connus). Vous pouvez l'encoder en UTF-8 (1-3 octets par caractère dépendant) ou peut-être UTF-16 (2 octets par caractère ou 4 octets en utilisant des paires de substitution).

Dans le passé, Java utilisait UCS-2 pour coder le jeu de caractères Unicode. Cela ne peut gérer que 2 octets par caractère et est maintenant obsolète. C'était un hack assez évident pour ajouter des paires de substitution et passer à UTF-16.

Beaucoup de gens pensent qu'ils auraient dû utiliser UTF-8 en premier lieu. Lorsque Java a été écrit à l'origine unicode avait bien plus de 65535 caractères de toute façon ...

Answer 4

UTF-8 et UCS-2/UTF-16 peuvent être distingués raisonnablement facilement via une marque d'ordre d'octets au début du fichier. Si cela existe, c'est un bon pari que le fichier est dans cet encodage - mais ce n'est pas une certitude morte. Vous pouvez également trouver que le fichier est dans l'un de ces encodages, mais n'a pas de marque d'octet.

Je ne connais pas grand-chose à ISO-8859-2, mais je ne serais pas surpris si presque chaque fichier est un fichier texte valide dans cet encodage. Le mieux que vous puissiez faire est de le vérifier de manière heuristique. En effet, la page Wikipedia qui en parle suggère que seul l'octet 0x7f est invalide. Il n'y a aucune idée de lire un fichier "tel quel" et de sortir du texte - un fichier est une séquence d'octets, vous devez donc appliquer un codage de caractères afin de décoder ces octets en caractères.

Source par stackoverflow

Answer 5

Je voudrais juste ajouter que si la chaîne est codé à l'origine en utilisant l'encodage erroné, il pourrait être impossible de le changer à un autre encodage sans erreurs. La question ne dit pas que la conversion ici est faite à partir d'encodage incorrect à l'encodage correct, mais je suis personnellement tombé sur cette question juste à cause de cette situation, donc juste une tête pour les autres aussi bien.

Cette réponse autre question donne une explication pourquoi la conversion ne donne pas toujours des résultats corrects https://stackoverflow.com/a/2623793/4702806