Discussion :

[ram-0000]

Bonjour,

Je doit convertir du binaire (byte[]) en string ASCII. J'ai déjà fait une fonction (qui marche ) mais je me demandais s'il n'y aurait pas plus élégant en termes de vitesse. Je ne connais pas toute l'API Java (loin s'en faut)

Mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
	public String toAscii(byte[] Value)
	{
		if( (Value == null) || (Value.length == 0) )
			return "";
 
		// translate byte[] into string
		StringBuilder buf = new StringBuilder();
		for(int boucle = 0; boucle != Value.length; boucle++)
		{
			byte carac = Value[boucle];
			buf.append(String.format("%02x", carac & 0xff));
 
		}
		return buf.toString();
	}

Est ce qu'il y a mieux (je suis sûr que oui)

Merci de vos retours

[thelvin]

Edit : nope, le code ci-contre n'est pas du tout ce qui est demandé. String s = new String(value, StandardCharsets.US_ASCII);

Par contre, ça fera un NullPointerExcepion si value est null.

Quelques remarques de style :

- ta méthode aurait dû s'appeler fromAscii() edit : bon bah toHexa(), plutôt.
- Seuls les noms de classe devraient commencer par une majuscule. (Et les noms de constantes, puisqu'ils devraient être entièrement en majsucules.) Le paramètre Value devrait donc être value.
- et en fait, value ça veut pas dire grand-chose. Plutôt un nom comme bytes, qui indique que ce sont les octets que l'on veut convertir en String. Edit : finalement, ça se discute.

[ram-0000]

Par contre, ça fera un NullPointerExcepion si value est null.

Le cas Value est null ou Value est vide est géré en début de fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String s = new String(value, StandardCharsets.US_ASCII);

Tu es sûr (ou alors on ne s'est pas compris) ?

Mes données en entrée sont du binaire pur (en fait le contenu d'une image PNG) que je doit transporter dans du XML d'où la transformation binaire ==> ASCII

[thelvin]

Le cas Value est null ou Value est vide est géré en début de fonction

Je parle du code que je te montre. Le tien accepte un tableau null. Le mien, non.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String s = new String(value, StandardCharsets.US_ASCII);

Tu es sûr (ou alors on ne s'est pas compris) ?

Edit : yup, je me suis planté, j'ai pas les yeux en face des trous. Désolé.

je suis sûr que mon code fait la même chose que le tient.

Edit : ou pas, quand on le copie/colle.
Désolé.

[tchize_]

Ou la non les codes sont pas les même et la demande est très mal formulée. Ce que tu veux c'est transformer le binaire en un string qui ne contient que des charactères ascii pour des raisons de transmission, et qui pourra, par la suite être retransformée en binaire de l'autre coté. Ta question départ était plutot formulée du genre j'ai lu un fichier ascii avec inputStream, j'ai maintenant un tableau de byte, comment récupérer la String qui était dans le fichier



Ce que tu cherche au final, c'est de l'encodage en base64 pour rester standard. Et là le plus simple, c'est de passer par une api dédiée, comme commons codec, qui fournis un encodeur décodeur en base 64:


http://commons.apache.org/proper/com...ry/Base64.html

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
byte[] test = ....
String resultat =  Base64.encodeBase64String(test);
byte[] retourALaNormale =  String	decodeBase64(resultat);
// test et retourALaNormale contiennent maintenant les mêmes valeurs

PS: si tu veux vraiment partir sur l'hexadecimal comme tu as commencé avec ton code (mais qui aboutit à des chaînes plus longues), il y a la classe Hex dans la même librairie, avec des appels similaires:

http://commons.apache.org/proper/com...inary/Hex.html

[thelvin]

Bon bah effectivement si je prenais la peine de copier/coller avant de parler je dirais moins d'âneries -_-°.

tchize_ a indiqué le B.-A.-BA, je ne pense pas qu'il y ait autre chose à ajouter.
En principe, il serait un peu plus performant de faire soi-même la conversion byte -> 2 chiffres hexa que de le faire avec String.format(). D'où l'intérêt de commons-codec Hex si on tient à utiliser l'hexa.

[adiGuba]

Salut,



Sinon concernant ton code initial il est plutôt propre.

J'aurais juste 3 remarques :

• La paramètre "Value" devrait se nommer "value"
• On peut déterminer à l'avance la taille de la chaine finale, et donc initialiser le StringBuilder à la bonne taille (pour éviter les redimensionnements auto)
• Utilises le for-étendus pour parcourir le tableau

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
	public String toAscii(byte[] value) {
		if (value == null || value.length == 0)
			return "";
 
		StringBuilder buf = new StringBuilder(value.length*2);
		for (byte carac : value) {
			buf.append(String.format("%02x", carac & 0xff));
		}
		return buf.toString();
	}

a++

[ram-0000]

OK, ce sera donc du base64 encoding d'autant plus qu'Android possède déjà une classe base64 toute faite.

En fait, je préfère aussi le base64 parce que l'encodage généré est plus court que de la solution sur laquelle j'étais parti.

La cible finale c'est bien pour Android mais comme c'est aussi du Java...

Je trouverais bien un moyen de décoder le Base64 sous Qt (sur plateforme PC), c'est assez "standard" comme encodage mais cela, c'est une autre histoire.

Merci à tous

[ram-0000]

Sinon concernant ton code initial il est plutôt propre.

Merci !

[*] La paramètre "Value" devrait se nommer "value"

J'en prends bonne note

[*] On peut déterminer à l'avance la taille de la chaine finale, et donc initialiser le StringBuilder à la bonne taille (pour éviter les redimensionnements auto)

C'est vrai, bonne optimisation

[*] Utilises le for-étendus pour parcourir le tableau[/list]

Heu ... quand on débute (et je suis un débutant Java), on reste sur les bases (d'autant plus que je ne suis pas persuadé qu'un for étendu aille plus vite que le for que j'avais fait).

[tchize_]

La cible finale c'est bien pour Android mais comme c'est aussi du Java...

Je trouverais bien un moyen de décoder le Base64 sous Qt (sur plateforme PC), c'est assez "standard" comme encodage mais cela, c'est une autre histoire.

Merci à tous

Ha ben, je comprends maintenant, je me demandait depuis quelques semaines pourquoi tu venait te perdre de notre coté du forum

[thelvin]

Heu ... quand on débute (et je suis un débutant Java), on reste sur les bases (d'autant plus que je ne suis pas persuadé qu'un for étendu aille plus vite que le for que j'avais fait).

Il irait plus vite à taper en tout cas. Ce n'est pas une question de rapidité mais de clarté du code, tout comme Value qui devrait commencer par une minuscule.

Le for-étendu peut parfois mener à du code plus rapide (par exemple, quand on parcourt une List, qui pourrait être une LinkedList très longue, et que sans for étendu on l'aurait parcourue avec get() plutôt qu'avec iterator().) Du coup c'est une bonne idée d'en prendre le réflexe. Mais en général, c'est pas pour ça qu'on en parle.

[adiGuba]

C'est vrai, bonne optimisation

C'est juste du détail, qui ne se fera sentir que sur de très grosse chaine de caractère.
L'important c'est surtout d'utiliser StringBuilder et de ne pas faire de concaténation de String...

Heu ... quand on débute (et je suis un débutant Java), on reste sur les bases (d'autant plus que je ne suis pas persuadé qu'un for étendu aille plus vite que le for que j'avais fait).

C'est juste que le for-étendus est plus lisible, et donc plus pratique !

Quand à l'optimisation je pense que le compilateur et la JVM ont tout ce qu'il faut pour optimiser cela comme il faut




a++