convertir un long en string

bonjour,

J'ai une variable de type Long qui contient une adresse MAC (nombre compris entre 0x000000000000 et 0xFFFFFFFFFFFF)

Comment faire pour convertir ce nombre en une chaine de caractère de cette forme : xx : xx : xx : xx : xx : xx
=> xx représente la décomposition en valeurs hexadécimales de l'adresse MAC

ex:
Si ma variable vaut 0x010203040506
=> je veux avoir la chaine de caractère "01:02:03:04:05:06"


aussi, lorsque je fais ça :

Code:

---

Long val = Long.parseLong(varStr, 16); // convertion en nombre

---

=> si la chaine n'est pas un nombre ça me génère une erreur : comment faire pour éviter ceci ?


merci d'avance

Citation:

---

Envoyé par boboss123

Comment faire pour convertir ce nombre en une chaine de caractère de cette forme : xx : xx : xx : xx : xx : xx

---

A la main, tu décompose en bytes ton long et tu affiche chaque byte séparément en hexadécimal

Citation:

---

aussi, lorsque je fais ça :

Code:

---

Long val = Long.parseLong(varStr, 16); // convertion en nombre

---

=> si la chaine n'est pas un nombre ça me génère une erreur : comment faire pour éviter ceci ?

---

Si tu veux dire "comment parser une adresse mac", encore un fois c'est à la main. Tu splitte autour des ":" ta chaine, et pour chaque élément du split, tu fait passer dans Integer.parseInt(element,16) pour faire du parsing en hexadécimal.

ok merci, je pensais qu'il y avait des fonctions toutes faite pour ça :(

Pour parser un long en byte[], on fait comment (la classe Byte ne sait parser que des String) ?

Citation:

---

Citation:

---

aussi, lorsque je fais ça :
Code :

Long val = Long.parseLong(varStr, 16); // convertion en nombre

=> si la chaine n'est pas un nombre ça me génère une erreur : comment faire pour éviter ceci ?

---

Si tu veux dire "comment parser une adresse mac", encore un fois c'est à la main. Tu splitte autour des ":" ta chaine, et pour chaque élément du split, tu fait passer dans Integer.parseInt(element,16) pour faire du parsing en hexadécimal.

---

non, ce que je voudrais faire c'est tester si element peut etre parser en int avant d'utiliser la focntion (pour eviter d'avoir une erreur)

Citation:

---

Envoyé par boboss123

Pour parser un long en byte[], on fait comment (la classe Byte ne sait parser que des String) ?

---

pas parser, convertir. Suffit d'extraire les bits qui t'intéressent:

Code:

---

1 2 3

byte0 = addresseLong & 0XFF; byte1 = addresseLong & 0XFF00 >> 8; byte2 = addresseLong & 0XFF0000 >> 16;

---

Etc...

Citation:

---

non, ce que je voudrais faire c'est tester si element peut etre parser en int avant d'utiliser la focntion (pour eviter d'avoir une erreur)

---

Avec un expression régulière, par exemple:

Code:

---

adressesString.matches("^\\s*(\\p{XDigit}\\p{XDigit}:){5}\\p{XDigit}\\p{XDigit}\\s*$");

---

Ok, merci beaucoup

Citation:

---

Envoyé par tchize_

pas parser, convertir. Suffit d'extraire les bits qui t'intéressent:

Code:

---

1 2 3

byte0 = addresseLong & 0XFF; byte1 = addresseLong & 0XFF00 >> 8; byte2 = addresseLong & 0XFF0000 >> 16;

---

---

=> c'est super lourd tous ces décalages et ces masques, y a pas plus simple ? En langage C ça aurait donné juste ça :

Code:

---

1 2 3 4 5 6 7 8 9 10

char myByte[4]; long myVal = 0x123456; // (taille 8 bytes en C) myByte[0] = ((char*)&myVal )[0]; myByte[1] = ((char*)&myVal )[1]; myByte[2] = ((char*)&myVal )[2]; myByte[3] = ((char*)&myVal )[3];     // ou encore *((long*)myByte) = myVal;

---

non, d'abord ton code C est faux, un long ne fait pas nécessairement 8 byte en C, sa taille minimum est de 32bits, mais ca peut varier suivant l'architecture et le compilateur utilisé. :faq: C

Ensuite, plus grave, ton code présuppose que les bytes au sein d'un long sont dans une endiance précise, ce qui n'est pas garantit suivant l'architecture utilisée. Dans ton cas, si j'exécute ton code sur x86, j'obtiens "56 34 12", sur HP-UX/PA-RISC j'obtiens "0 12 34". A contrario, un code avec des masque donne la garantie que c'est toujours le meme résultat.


Finalement, ce code détourne l'arithmétique sur les pointeur, il n'y a pas de pointeur en java.

Si tu veux faire "plus court", t'as ce code ci

Code:

---

1 2 3 4

byte[] b = new byte[8]; long val = ....; for (int i = 0; i< 8; i++) b[i]=val&(0xFF<<(i*8))>>i*8

---

mais c'est moins lisible et moins performant.

En fait

Code:

---

1 2 3 4

byte[] b = new byte[8]; long val = ....; for (int i = 0; i< 8; i++) b[i]= (byte)(val >> i*8);

---

Est suffisant. Un byte ne contient que 8 bits de toutes façon. Pas besoin de masque, le cast n'a pas vraiment le choix.

effectivement, le cast applique de facto le masque, c'est l'habitude de vouloir mettre les composant d'un int dans un autre int qui m'a fait sortir ce code :p

ok. effectivement mon code C n'est pas portable

En java la taille des types sont bien défini de façon fixe (contrairement au C qui impose juste une taille minimale) ?

Qu'est-ce qui impose l'endiance ? c'est le compilateur, la machine ou l'OS utilisée ? tous les programme java ne tournent pas forcement avec la même endiance ?
=> pourquoi il y a des endiances differentes ?

En java la taille des types sont bien défini de façon fixe (contrairement au C qui impose juste une taille minimale) ?

oui, c'est dans les spécifications de la JVM, tous les type java on une taille et des limites précises

Qu'est-ce qui impose l'endiance ?
En C, bien souvent c'est l'architecture (machine)

tous les programme java ne tournent pas forcement avec la même endiance ?
Si, ils tournent dans une machine virtuelle dont l'endiance est définie. Cependant, vu qu'il n'y a pas de pointeur en java, l'endiance n'a que peu d'influence sur le code, ca joue surtout au niveau de l'écriture dans les flux

=> pourquoi il y a des endiances differentes ?
Merci de faire des recherches, il y a de nombreux articles sur les différentes endiances. En pratique, c'est du à la naissance de l'informatique: plein de petits constructeurs = plein de spécifications différentes qu'on se traine toujours aujourd'hui.

ok, merci pour les infos

Citation:

---

Envoyé par tchize_

[I][COLOR="Silver"]
tous les programme java ne tournent pas forcement avec la même endiance ?
Si, ils tournent dans une machine virtuelle dont l'endiance est définie.

---

Quelles sont les machines virtuelles qui utilisent une endiances spécifique ? => est-ce que ce sont juste sur les µControlleur qu'on peut trouvé le cas ? peut-on dire que sur PC (je parle pas de PC qui ont plus de 10ans) l'endiance est fixe ou pas ?

Salut,


J'arrive un peu tard sur le sujet... mais il s'agit de simple conversion et il me semble que vous vous compliquer un peu la vie.

Depuis Java 5 on dispose de la méthode String.format() qui permet de formater des chaines "à la printf" ce qui est très pratique également pour formater un nombre en une base quelconque.

Cela permet en particulier de définir une longueur minimum pour la valeur, en rajoutant automatiquement les zéro inutile :

Code:

---

1 2 3 4

long number = 0x010203040506L;   // Convertion number -> text String text = String.format("%012X", number); // renvoi : "010203040506"

---

Ensuite il suffit de rajouter les ":" tous les 2 caractères, ce qui nous donne via une expression régulière :

Code:

---

1 2 3 4 5

long number = 0x010203040506L;   // Convertion number -> text String text = String.format("%012X", number) .replaceAll("(..)(?!$)", "$1:"); // renvoi "01:02:03:04:05:06"

---

Enfin, pour la conversion inverse ("01:02:03:04:05:06" vers un long), il suffit de "supprimer" les ":" afin de pouvoir parser la valeur tout à fait normalement :

Code:

---

1 2	// Conversion text -> number number = Long.parseLong( text.replace(":", ""), 16 );

---

Et on ne s'embête pas avec des décalages de bits :D

Citation:

---

Envoyé par boboss123

non, ce que je voudrais faire c'est tester si element peut etre parser en int avant d'utiliser la focntion (pour eviter d'avoir une erreur)

---

Attention à ceci car c'est bien souvent un mauvais choix car cela revient à doubler les traitements. La meilleur façon de s'assurer que parseLong() ne génère pas d'erreur serait d'appeler parseLong() :aie:

Toutes les autres solutions ne sont pas forcément sûr (en particulier à causes des plages de valeurs possibles) et ne font que rajouter du code inutile dans 95% des cas.

Il est nettement plus simple de traiter l'erreur lorsqu'elle surgit plutôt que de tenter de la repérer en amont...


a++

l'endiance est liée à l'architecture du processeur. En java le "processeur" est une machine virtuelle assez particulière car elle est indépendante de l'endiance. Il est impossible en java d'écrire un code qui détermine l'endiance de la JVM et donc le programmeur n'a pas a s'en soucier. Tous les outputstream java, par contre, utilisent une convention "big endian" mais ceci n'est pas liée à l'architecture interne de la JVM.

Pour ce qui est des PC, c'est de l'architecture x86, donc du little endian.

ok merci .