199 votes

Encoder une chaîne en UTF-8

J'ai une chaîne de caractères avec un caractère "ñ" et j'ai quelques problèmes avec elle. J'ai besoin d'encoder cette chaîne en encodage UTF-8. J'ai essayé de cette manière, mais cela ne fonctionne pas :

byte ptext[] = myString.getBytes();
String value = new String(ptext, "UTF-8");

Comment puis-je encoder cette chaîne en utf-8 ?

2 votes

Ce que vous essayez de faire exactement n'est pas clair. Est-ce que maChaîne contient correctement le caractère ñ et vous avez des problèmes pour la convertir en tableau d'octets (dans ce cas, voir les réponses de Peter et Amir), ou est-ce que maChaîne est corrompue et vous essayez de la réparer (dans ce cas, voir les réponses de Joachim et moi) ?

0 votes

Je dois envoyer myString à un serveur avec un encodage utf-8 et je dois convertir le caractère "ñ" en encodage utf-8.

1 votes

Si le serveur attend l'UTF-8, vous devez lui envoyer des octets, pas une chaîne. Donc, conformément à la réponse de Peter, spécifiez l'encodage dans la première ligne et laissez tomber la deuxième ligne.

183voto

Amir Rachum Points 13236

Que diriez-vous d'utiliser

ByteBuffer byteBuffer = StandardCharsets.UTF_8.encode(myString)

0 votes

Voir ma discussion avec Peter. Mais si son hypothèse sur la question est correcte, votre solution ne serait toujours pas une idée puisqu'elle renvoie un ByteBuffer.

8 votes

Mais comment obtenir une chaîne de caractères codée ? Il renvoie un ByteBuffer.

7 votes

@Alex : c'est pas possible pour obtenir une chaîne Java codée en UTF-8. Vous voulez des octets, alors soit vous utilisez directement le ByteBuffer (ce qui pourrait même être la meilleure solution si votre objectif est de l'envoyer via une collection réseau), soit vous appelez array() dessus pour obtenir un byte[].

145voto

Joachim Sauer Points 133411

String en Java utilisent le codage UTF-16 qui ne peut pas être modifié.

La seule chose qui peut avoir un encodage différent est une byte[] . Ainsi, si vous avez besoin de données UTF-8, vous avez besoin d'un fichier byte[] . Si vous avez un String qui contient des données inattendues, alors le problème se situe à un endroit antérieur qui a converti de manière incorrecte des données binaires en un fichier de type String (c'est-à-dire qu'il utilisait le mauvais encodage).

94 votes

Techniquement parlant, byte[] n'a pas d'encodage. Le tableau d'octets PLUS l'encodage peut cependant donner une chaîne de caractères.

1 votes

@Peter : vrai. Mais le fait d'y attacher un encodage n'a de sens que pour byte[] il n'y a pas de sens pour String (sauf si l'encodage est UTF-16, auquel cas cela a du sens mais c'est toujours une information inutile).

4 votes

String objects in Java use the UTF-16 encoding that can't be modified. Avez-vous une source officielle pour cette citation ?

86voto

rzymek Points 3464

En Java7, vous pouvez utiliser :

import static java.nio.charset.StandardCharsets.*;

byte[] ptext = myString.getBytes(ISO_8859_1); 
String value = new String(ptext, UTF_8); 

Cela présente l'avantage de getBytes(String) qu'il ne déclare pas throws UnsupportedEncodingException .

Si vous utilisez une ancienne version de Java, vous pouvez déclarer les constantes charset vous-même :

import java.nio.charset.Charset;

public class StandardCharsets {
    public static final Charset ISO_8859_1 = Charset.forName("ISO-8859-1");
    public static final Charset UTF_8 = Charset.forName("UTF-8");
    //....
}

2 votes

C'est la bonne réponse. Si quelqu'un veut utiliser un type de données de type chaîne, il peut l'utiliser dans le bon format. Les autres réponses indiquent le type de données au format octet.

0 votes

Fonctionne en 6. Merci.

0 votes

Réponse correcte pour moi aussi. Une chose cependant, lorsque j'ai utilisé la méthode ci-dessus, le caractère allemand a été remplacé par ?. J'ai donc utilisé ceci : byte[] ptext = myString.getBytes(UTF_8) ; String value = new String(ptext, UTF_8) ; Cela a bien fonctionné.

77voto

Peter Štibraný Points 17507

Utilisez byte[] ptext = String.getBytes("UTF-8"); au lieu de getBytes() . getBytes() utilise ce que l'on appelle le "codage par défaut", qui peut ne pas être UTF-8.

9 votes

@Michael : il a clairement du mal à obtenir des octets à partir d'une chaîne. Comment getBytes(encodage) peut-il manquer le point ? Je pense que la deuxième ligne est là juste pour vérifier s'il peut le reconvertir.

1 votes

Je l'interprète comme ayant une chaîne cassée et essayant de la "réparer" en la convertissant en octets et inversement (malentendu courant). Il n'y a aucune indication réelle que la deuxième ligne ne fait que vérifier le résultat.

0 votes

Michael, non, ce n'est pas le cas, c'est juste mon interprétation. La vôtre est simplement différente.

33voto

Michael Borgwardt Points 181658

En interne, une chaîne Java est toujours codée en UTF-16, mais il faut y penser comme suit : un codage est un moyen de traduire les chaînes en octets.

Donc, si vous avez un problème d'encodage, au moment où vous avez String, il est trop tard pour le régler. Vous devez corriger l'endroit où vous créez cette chaîne à partir d'un fichier, d'une base de données ou d'une connexion réseau.

1 votes

C'est une erreur courante de croire que les chaînes de caractères sont codées en interne en UTF-16. En général, elles le sont, mais si c'est le cas, il s'agit uniquement d'un détail spécifique à l'implémentation de la classe String. Le stockage interne des données de caractères n'étant pas accessible via l'API publique, une implémentation spécifique de String peut décider d'utiliser tout autre encodage.

4 votes

@jarnbjo : L'API indique explicitement "A String représente une chaîne de caractères au format UTF-16". L'utilisation d'un autre format interne serait très inefficace, et toutes les implémentations réelles que je connais utilisent UTF-16 en interne. Donc, à moins que vous ne puissiez en citer une qui ne le fait pas, vous vous engagez dans un débat absurde.

0 votes

Est-il absurde de faire une distinction entre l'accès public et la représentation interne des structures de données ?

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X