Déclarer un String comme étant de l'héxadécimal

Version imprimable

01/06/2011, 18h11
bobic

Déclarer un String comme étant de l'héxadécimal

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 :)
01/06/2011, 18h17
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.
06/06/2011, 00h25
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... :ccool:

Cdlt,

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:

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:

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));
  }
}

06/06/2011, 10h35
bulbo

Citation:

Envoyé par thelvin

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 ;)
06/06/2011, 10h36
tchize_

Citation:

Envoyé par bobic

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

Citation:

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

Citation:

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.
06/06/2011, 10h40
thelvin

Citation:

Envoyé par bulbo

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 ?
06/06/2011, 11h04
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..
06/06/2011, 11h13
tchize_

Citation:

Envoyé par bulbo

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 ;)
06/06/2011, 11h14
thelvin

Citation:

Envoyé par bulbo

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_

Citation:

Envoyé par bulbo

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.
06/06/2011, 11h21
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 :)
06/06/2011, 11h46
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.
06/06/2011, 12h16
bulbo

Citation:

Envoyé par Nemek

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 ;)
06/06/2011, 12h57
thelvin

Citation:

Envoyé par bulbo

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.

Citation:

Envoyé par bulbo

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.
06/06/2011, 12h59
Logan Mauzaize

Citation:

Envoyé par bulbo

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.

Citation:

Envoyé par bulbo

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 !
06/06/2011, 13h24
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:

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:

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

bref si on avait des type non signés, on aurait d'autres problèmes :)
06/06/2011, 13h35
bulbo

Citation:

Envoyé par Nemek

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.
06/06/2011, 13h40
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 ;)

Mouais et là ? Tu expliques ça comment ?
Code:

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.

06/06/2011, 14h00
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:

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.
06/06/2011, 14h24
bulbo
Code:

1 2 int b = 0xFF; a = (byte) (b);
On ne perd aucune précision, pas d'exception, et la valeur attendue de -1 alors que si on perdait en précision, par exemple à cause du bit de signe, on devrait obtenir comme valeur (127) 7F et pas -1

Mais si on fait:

Code:

Byte.parseByte("0xFF", 16);

On se prend une exception.

Et là moi ça me chagrine un peu, surtout que c'est un cast 'régulier'
06/06/2011, 14h49
tchize_
Citation:
Envoyé par bulbo

Code:

1 2 int b = 0xFF; a = (byte) (b);

On ne perd aucune précision, pas d'exception, et la valeur attendue de -1 alors que si on perdait en précision, par exemple à cause du bit de signe, on devrait obtenir comme valeur (127) 7F et pas -1
Si il y a perte de précision (255 ca rentre pas dans un byte), non en cas de perte de précision en typecasting, il n'y a pas d'exception en java (de même qu'en cas de débordement), non on ne devrait pas avoir 127. Convertir "255" en byte, ca n'est pas plus correct mathématiquement de prendre 127 que de prendre -1. 2044 convertis en byte donne -4, ce n'est pas mathématiquement correct. C'est bien marqué dans la JLS, si tu dépasse les bornes du type vers lequel tu caste, la valeur ne sera pas préservée, on va juste couper les bits en trop.

Et je le répète ici, on parle de typecasting, ce qui n'a absolument rien à voir avec parseByte qui concerne du parsing de String. D'ailleurs parseByte et totalement cohérent par rapport à parseInt. Maintenant, effectivement, on peux leur reprocher de ne pas être cohérent par rapport au language puisque je peux écrire
Code:

1 2 3 4 public static void main(String[] args) throws IOException { int a = 0xFFFFFFFF; Integer.parseInt(String.format("%X", a)); }
et que c'est exception garantie
Encore une fois, c'est une librairie, elle a sa doc il suffit de la suivre pour savoir ce qu'on peux faire ou pas.

Fuseau horaire GMT +2. Il est actuellement 08h08.