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.