Discussion :

[bobic]

Slt � tous,

J'ai une m�thode dans laquelle je re�ois un String qui se trouve �tre de l'h�xad�cimal.

Il se trouve, que comme je veux r�cup�rer un tableau de bytes, je veux d�clarer mon objet comme �tant de l'h�xa et non un simple string...

Je ne veux donc pas le convertir (�a, je sais faire ^^) mais le caster...

Je vous remercie

[thelvin]

�a veut rien dire. Une String est une String. C'est une s�quence de caract�res et ce n'est pas autre chose.

Une String ne se caste pas. C'est donc, probablement, bien une conversion que tu veux faire.

Mais pour qu'on se fasse une id�e, c'est comme toujours : 'faudrait voir du code.
Cas o� il n'est pas n�cessaire de montrer un peu de concret pour exposer un probl�me : aucun. �a n'existe pas.

[bobic]

Je comprend bien ce que tu veux dire
Mais mon string qui entre dans ma m�thode, est bien de l'h�xa.

J'ai ainsi par ex EF010 qui arrive en tant que String.
Seulement ce EF010 est de h�xa, cad 978 960 en v�ritable string.

Mon but est de r�cup�rer les bytes de �a. Si je le prend tel quel en String ce n'est pas bon (forc�ment...), si je le convertit en h�xa idem...

C'est pour �a, que je dois d�clarer ma chaine en tant que h�xa, sans la convertir...

Cdlt,

[thelvin]

Je ne vois pas le probl�me � le prendre tel quel en String.

Le plus simple est d'utiliser la biblioth�que commons-codecs :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
String s = "EF0100";
byte[] bytes = Hex.decodeHex(s.toCharArray());
System.out.println(Arrays.toString(bytes));

Bien s�r, vu qu'un octet est sur deux chiffres hexad�cimaux, il faut un nombre pair de chiffres. Ton exemple impair, �a ne va pas aller.

Si on veut �viter une bibli externe, il suffit d'�crire sa propre m�thode de conversion :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class Hex {
 
  public static int getDigitValue(char ch) {
    if(ch >= '0' && ch <= '9') {
      return ch - '0';
    } else if(ch >= 'a' && ch <= 'f') {
      return ch - 'a' + 10;
    } else if(ch >= 'A' && ch <= 'F') {
      return ch - 'A' + 10;
    } else {
      throw new IllegalArgumentException("Illegal hexadecimal digit: " + ch);
    }
  }
 
  public static byte[] decode(String s) {
    int sLen = s.length();
    if(sLen % 2 != 0) {
      throw new IllegalArgumentException("Odd number of characters: " +*s);
    }
    byte[] bytes = new byte[sLen / 2];
    for(int i = 0; i < bytes.length; i++) {
      int thisByte = getDigitValue(s.charAt(2*i))*16 + getDigitValue(s.charAt(2*i + 1));
      bytes[i] = (byte)thisByte;
    }
    return bytes;
  }
 
  public static void main(String[] args) {
    String s = "EF0100";
    byte[] bytes = Hex.decode(s);
    System.out.println(Arrays.toString(bytes));
  }
}

[bulbo]

Si on veut �viter une bibli externe, il suffit d'�crire sa propre m�thode de conversion :
...

Et Integer.parseInt(taString, 16) .. c'est pas bien pour parser de l'hexa ?

Ensuite pour en revenir au probl�me .. �a veut dire quoi "je veux d�clarer mon objet comme �tant de l'h�xa"

Un type h�xa �a n'existe pas en java, c'est au mieux un tableau de byte.

Caster signifie changer le type de l'objet et non pas le convertir or m�me dans un langage comme le C permettant ce genre de cast violent, la valeur lue dans le tableau de byte ne correspondra pas � la valeur hexa repr�sent�e dans la string. Ce sera juste un tableau contenant les code ASCII des caract�res utilis�s pour repr�sent� la chaine h�xa... et �a n'a rien � voir du tout.

Il va donc falloir passer par une conversion et non un cast.

Bulbo

[tchize_]

Mais mon string qui entre dans ma m�thode, est bien de l'h�xa.

Une String c'est un String, c'est � dire un objet qui encapsule un tableau de char[], de l'hexad�cimal, comme du d�cimal, ce n'est jamais qu'une conversion d'un nombre binaire en un ensemble de valeur en m�moire qui correspondent � la table de charact�res utilis�e par le language

J'ai ainsi par ex EF010 qui arrive en tant que String.
Seulement ce EF010 est de h�xa, cad 978 960 en v�ritable string.

Je vois pas ce que tu appelle un v�ritable String. CF. mon point ci-dessus

si je le convertit en h�xa idem...

Je vois pas du tout ce que tu appelle "convertir en hexa". Quand � "d�clarer un chaine en tant que hexa", �a ne veux rien dire en termes de programmation. Si t'as une chaine de charact�res (String) qui repr�sente un nombre, peu importe sa base, tu va devoir la convertir en byte/int/long/float/double suivant sa signification pour pouvoir faire des calculs dessus.

[thelvin]

Et Integer.parseInt(taString, 16) .. c'est pas bien pour parser de l'hexa ?

Pour faire un byte[] ? Moi je suis pas fan.
Si l'int est sup�rieur � 0x7fff ffff, on fait comment ? Et sup�rieur � 0x7fff ffff ffff ffff ?

[bulbo]

Tu lis ta chaine de 2 en 2 en partant de la fin et Byte.parseByte(taSubstring, 16).

J'�tais juste rest� sur ta m�thode getDigitValue qui retournait un int..

[tchize_]

Tu lis ta chaine de 2 en 2 en partant de la fin et Byte.parseByte(taSubstring, 16).

Des trucs sup�rieur � 7F ne passeront pas dans Byte.parseByte, car �a attends des valeur comprises entre -128 et +127, donc entre -80 et +7F en Hexa

Il faudrait donc passer par Integer.parseInt() et typecaster en byte

[thelvin]

Tu lis ta chaine de 2 en 2 en partant de la fin et Byte.parseByte(taSubstring, 16).

C'est d'un pratique.
Au fait, mon entr�e "80EFBD" a un soucis.
Edit: grill� par tchize_

J'�tais juste rest� sur ta m�thode getDigitValue qui retournait un int..

Ouais enfin construire des Strings en pagaille, bof bof. Et niveau lisibilit� je suis pas convaincu. Mais bon, �a peut se faire.

[tchize_]

personellement, je trouve qu'au lieu de sa casser la nenette sur des chippotage, utiliser une librairies comme commons-codec qui le fait d�j�, ca reste le plus propre

[Logan Mauzaize]

Surtout qu'il ne faut pas oublier que les nombres en Java sont TOUS sign�s. Donc �a risque de donner quelques surprises � la conversion en byte.

[bulbo]

Surtout qu'il ne faut pas oublier que les nombres en Java sont TOUS sign�s. Donc �a risque de donner quelques surprises � la conversion en byte.

Oui et non .. une valeur en byte sign�e ou non est la bonne valeur .. et l'API standard en tient compte ..

Par contre il faut m'expliquer le choix de l'API standard de ne pas parser FF en -1 mais de retourner au lieu de �a un "value out of range" .. tant qu'a supporter un radix, ils auraient pu tenir compte du bit de signe.

Donc pour revenir sur ce que je disais, il ne faut effectivement pas utiliser Byte.parseByte(s, 16) mais Integer.parseInt(s, 16) ou �ventuellement Character.digit(c, 16) et caster en byte tout en nettoyant le bit de signe.

Tout �a parce que j'ai dit qu'il y avait mieux que la version de getDigitValue propos�e par thelvin qui ose trouver un probl�me de lisibilit� dans un substring
Pour info commons-codec utilise Character.digit(c, 16) et � part une boucle for et le nettoyage du bit de signe n'apporte rien de plus.
Ah si .. commons-codec balance une exception si nombre impair de caract�re au lieu de faire du padding avec des 0.. ce qui pourrait �tre un comportement plus sympa.

Sachant que si quelqu'un a besoin de manipuler de l'hexa en java, �a peut �tre une bonne chose qu'il soit un peu � l'aise en op�ration binaire et bit de signe.. et que donc s'il ne sait pas faire ou n'apprend pas � faire cette conversion basique, il risque de toute fa�on de buter dessus plus tard.

Bulbo

[thelvin]

Par contre il faut m'expliquer le choix de l'API standard de ne pas parser FF en -1 mais de retourner au lieu de �a un "value out of range" .. tant qu'a supporter un radix, ils auraient pu tenir compte du bit de signe.

Bah, on pourrait consid�rer qu'il y a pas d'histoire de bit de signe : FF c'est 255 ; les bytes vont de -128 � 127 ; et 255 est au-dessus de 127, donc c'est en dehors de l'intervalle.
Pour -1, il y a... "-1". C'est s�r qu'avec des bytes et en base 16 c'est d�bile, mais avec des ints et en base 10 ou 7, c'est une autre histoire, hum ? Ils ont simplement pr�serv� la coh�rence entre tous les types et toutes les bases. Je ne trouve pas �a malin, mais bon.

Donc pour revenir sur ce que je disais, il ne faut effectivement pas utiliser Byte.parseByte(s, 16) mais Integer.parseInt(s, 16) ou �ventuellement Character.digit(c, 16) et caster en byte tout en nettoyant le bit de signe.

Beurk Integer.parseInt() qui accepte le - sans rechigner. Et puis il faut v�rifier le d�passement. Je pr�f�re garder les choses claires et faire le calcul explicitement plut�t que des v�rifications � la mords-moi-le-n�ud que personne ne comprendra.

Character.digit() est une bonne trouvaille que je ne connaissais pas. Mais je me m�fie de isDigit(). Moi quand je fais de l'hexa je manipule de l'ASCII ou rien. Mais bon, je vois que Integer.parseInt() se base dessus, alors je suppose que c'est du domaine de l'acceptable.

[Logan Mauzaize]

Oui et non .. une valeur en byte sign�e ou non est la bonne valeur .. et l'API standard en tient compte ..

Tu ne peux pas convertir des nombres h�xad�cimaux sup�rieurs � 7F.

Par contre il faut m'expliquer le choix de l'API standard de ne pas parser FF en -1 mais de retourner au lieu de �a un "value out of range" .. tant qu'a supporter un radix, ils auraient pu tenir compte du bit de signe.

Ils ont fait le choix logique de convertir des nombre sign�s en nombre sign�.
Les nombres en Java ne sont pas manipul�s selon leur repr�sentation binaire mais bien leur s�mantique num�rique/math�matique ...

Ainsi FF vaut 255 et est "out of range" d'un byte. Ce qui est logique !

[tchize_]

en fait, l'absence de type non sign�s n'est probl�matique en g�n�ral que pour une chose: le codage d'api / algos de bas niveau qui doivent manipuler des octets ind�pendament en les convertissant. Et m�me l� on a d�j� les class DateInput/OutputStream qui font le travail. Le m�lange sign�/non sign� �tant probl�matique en g�n�ral (voir code ci-dessous en C), java a fait le choix de ne pas m�langer. Le seul type non sign� en java est char, et rien que �a am�ne parfois des erreurs dans des algos a cause de la conversion sign�/non sign�. Java aurait pu faire le choix de n'avoir que des non sign�s, mais faut admettre que le r�sultat aurait �t� vachement handicapant.

Qu'on soit en sign� ou pas, la plupart des op�ration bit � bit fonctionnent de la m�me mani�re. C'est juste quand on joue avec des conversions vers String qu'il faut faire gaffe

Code c :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
#include "stdio.h"
int main (char** argv){
   unsigned int x;
   signed int y;
   y=-1;
   x=y;
   printf("%X,%X,%d/2=%d,%d/2=%d\n",x,y,x,x/2,y,y/2);
 
}

sa sortie:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

FFFFFFFF,FFFFFFFF,-1/2=2147483647,-1/2=0

bref si on avait des type non sign�s, on aurait d'autres probl�mes

[bulbo]

Ils ont fait le choix logique de convertir des nombre sign�s en nombre sign�.
...
Ainsi FF vaut 255 et est "out of range" d'un byte. Ce qui est logique !

FF sur une taille d'un octet (byte) dans un monde sign� signifie -1 donc la logique consistant � traduire �a en 255 .. j'ai du mal.

Surtout que -128 � +127 sur la taille d'un byte �a couvre de 0x00 � 0xFF donc en interne si on regarde la valeur stock�e dans le byte on a bien au niveau de la m�moire FF qui est une valeur valide.

[tchize_]

non, c'est Faux, -1 c'est -0x01

Sinon on se retrouve avec des curiosit� comme en C o� quand vous mettez dans une octet sign� -0xFF ils stocke "1", ce qui n'a pas plus de sens. Java ce n'est pas du C, comme l'a dit Nemek, la logique de java est la logique math�matique, qui dit que -0x01 ce n'est pas la m�me chose que 0xFF. De toutes facons, la conversion nombre -> String d�pend uniquement de la mani�re dont la librairie que vous utilisez veux interpr�ter l'hexa, c'est tout. C'est pour �a qu'il y a une doc et qu'il faut la lire

[bulbo]

Mouais et l� ? Tu expliques �a comment ?

Code java :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
byte a = -1;
System.out.println("byte value = " + a);
String s = Integer.toHexString(a & 0xFF);
 
System.out.println("hexa String = " + s);
 
int b = 0xFF;
a = (byte) (b);
 
System.out.println("byte value = " + a);

On l'accepte tout le temps ou on l'accepte jamais, mais l� c'est n'imp et pis c'est tout.

[tchize_]

J'ai du mal a comprendre ton point l�, tu travaille avec des int l�, sign� et qui contiennent sans probl�me la valeur non sign�e 0xFF, et non pas avec des byte qui ne peuvent pas la contenir, ce qui �tait le sujet original du post. Passer par Integer.parseInt a d'ailleurs d�j� �t� sugg�r�. C'est aussi d'ailleurs comme �a qu'on cr�e des tableau de byte facilement partire d'hexa:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

byte[] classHeader = new byte[]{(byte)0xCA,(byte)0xFE,(byte)0xBA,(byte)0xBE}

On est plus dans la repr�sentation sign�e ou pas d'un nombre hexadecimal, on est dans les r�gle de type casting d'un entier -> un byte, qui pr�cise bien les risque li�s � la perte de pr�cision.