Encodage sous Android

Bonjour J'ai un petit souci sous Android. Je m'explique.

J'ai cette fonction en Java que je souhaite utiliser sous android. Elle converti un tableau de int en String de là meme manière que fonctionne le struct.pack en python.

Code:

---

1 2 3 4 5 6 7 8 9

public static String a_to_str(int[] a) { StringBuffer str = new StringBuffer(); for (int i = 0; i<a.length*4; i++) { str.append((char)(0xFF & a[(i >> 2)] >>> 24- 8 * (i & 0x3))); } return str.toString();   }

---

Le paramètre de la fonction est celui ci.

Code:

---

int[] pk = { 0x93C467E3, 0x7DB0C7A4, 0xD1BE3F81, 0x0152CB56 };

---

Mon seul souci c'est que ma chaine retournée qui devrait être encoder en 16 bit à non seulement 28 bits. Pourtant en lançant via la JVM avec un encodage Windows (ISO-99XX) ça marche bien. Mais quand je le lance à l'intérieur de mon programme Android, il code la valeur "0x93C467E3" (qui est trop long pour rentrer dans un int) sur 7 bits au lieu de 4bits.

Quelqu'un a une solution a me proposer ? Comme avoir le même encodage sous Android que celui que j'ai sous Windows ?

Bonjour,

J'avoue que je ne comprends pas le but... Stocker un array de int dans un byte[] ? (si j'ai bien compris la fonction)...

Parce que à l’intérieur de String, c'est pas des bytes, et char=(presque)=int en java ! Donc cela ne correspondra à rien... Sans compter que c'est encodé en UTF-16 de toute manière à l'intérieur de String....

(char)(0xFF & a[(i >> 2)] >>> 24- 8 * (i & 0x3)) peut renvoyer des caractères de contrôles... voire même (0xFE00 par exemple) demander un caractère suivant (32bits encodé en UTF-16)... Et pire encore des '\0' (fin de chaine)...

Donc si le but est d'obtenir des bytes.... il faut retourner des byte[] et surtout pas des char[] et encore moins une String. On est dans un langage fortement typé, profitons en.

Citation:

---

Mon seul souci c'est que ma chaine retournée qui devrait être encoder en 16 bit à non seulement 28 bits.

---

Désolé, je ne comprends rien.

Citation:

---

il code la valeur "0x93C467E3" (qui est trop long pour rentrer dans un int) sur 7 bits au lieu de 4bits.

---

????
0x93C467E3 rentre parfaitement dans un int (32bits).



De manière annexe, ne pas utiliser StringBuffer dans une fonction simple... préférer StringBuilder (c'est la même chose, sans les 'synchronized': StringBuffer est un StringBuilder thread-safe).