Je demande cela parce que j'envoie un flux d'octets d'un processus C à Java. Du côté C, l'entier de 32 bits a le LSB comme premier octet et le MSB comme quatrième octet.
Ma question est donc la suivante : Du côté de Java, lorsque nous lisons l'octet tel qu'il a été envoyé par le processus C, qu'est-ce que endienne du côté de Java ?
Une question de suivi : Si l'endian du côté Java n'est pas le même que celui envoyé, comment puis-je le convertir ?
Je ne suis pas sur ma machine linux en ce moment mais htons est une des librairies standard ?
Selon h30097.www3.hp.com/docs//base_doc/DOCUMENTATION/V51_HTML/MAN/ elle fait partie de la bibliothèque c standard, oui
Je suis tombé ici par hasard via Google et j'ai obtenu la réponse que Java est grand endian .
En lisant les réponses, j'aimerais signaler que les octets ont effectivement un ordre endian, bien que, heureusement, si vous n'avez eu affaire qu'à des microprocesseurs "grand public", il est peu probable que vous ayez jamais rencontré ce problème. En effet, Intel, Motorola et Zilog se sont tous mis d'accord sur le sens de décalage de leurs puces UART et le MSB d'un octet est le suivant 2**7 et le LSB serait 2**0 dans leurs processeurs (j'ai utilisé la notation de puissance FORTRAN pour souligner l'ancienneté de ces données :) ).
J'ai rencontré ce problème avec certaines données de liaison descendante en série de la navette spatiale il y a plus de 20 ans lorsque nous avons remplacé un matériel d'interface de 10 000 $ par un ordinateur Mac. Un dossier technique de la NASA a été publié à ce sujet il y a longtemps. J'ai simplement utilisé une table de consultation de 256 éléments avec les bits inversés ( table[0x01]=0x80 etc.) après que chaque octet ait été décalé du flux binaire.
Si l'un d'entre eux est public, pourriez-vous mettre un lien vers le dossier technique de la NASA (et les données de la navette spatiale sur la liaison descendante en série par bit) dont vous parlez ? ce serait fascinant, je n'ai jamais vu une chose pareille.
L'endiannité par bit entre également en jeu avec les formats de compression qui utilisent une forme de codage de Huffman (c'est-à-dire tous). Pour plus de fun, JPEG est "bitwise big-endian" (c'est-à-dire que le bit le plus significatif est le "premier" bit) et LZ est "bitwise little-endian". J'ai travaillé une fois sur un format de compression propriétaire qui utilisait les deux formats sous le capot. Oh, c'était amusant...
Il n'existe pas d'entiers non signés en Java. Tous les entiers sont signés et en big endian.
Du côté C, chaque octet a le LSB au début à gauche et le MSB à la fin.
On dirait que vous utilisez LSB pour Least significant bit, n'est-ce pas ? LSB signifie généralement octet le moins significatif. Endianness n'est pas basé sur les bits mais sur les octets.
Pour convertir un octet non signé en un entier Java :
int i = (int) b & 0xFF;Pour convertir une valeur non signée 32 bits little-endian en byte[] en long Java (de mémoire, non testé) :
long l = (long)b[0] & 0xFF;
l += ((long)b[1] & 0xFF) << 8;
l += ((long)b[2] & 0xFF) << 16;
l += ((long)b[3] & 0xFF) << 24;
Je viens de réaliser que :$ alors comment suis-je censé envoyer ce petit endian non signé à mon processus java pour qu'il le lise correctement ?
Ce que je veux dire par le début est que lsb est au début des 4 octets (c'est un int 32 bits non signé) donc je voulais dire l'octet le moins significatif.
Cela ne peut en aucun cas influencer quoi que ce soit en Java, puisqu'il n'existe aucun moyen (direct hors API) de convertir directement certains octets en un int en Java.
Chaque API qui fait cela ou quelque chose de similaire définit le comportement de manière assez précise, vous devriez donc consulter la documentation de cette API.
Oh, bien sûr que si. Les mathématiques binaires (&, |, <<, etc.) fonctionnent très bien sur les octets et les ints. Il est assez facile de prendre des octets arbitraires et de les coller dans un entier.
Mais si vous faites cela, vous ne pouvez toujours pas savoir quel endianess votre JVM utilise en interne.
Oui, mais même là, vous n'êtes pas directement en correspondance. Vous utilisez une arithmétique qui fait exactement ce que vous lui dites, il n'y a aucune ambiguïté. En C, vous pouvez toujours convertir un "byte*" en un "long*" et le déréférencer. Il faudrait alors se préoccuper de l'endianité. En Java, il n'y a pas de moyen direct et ambigu de le faire.
Car même si je lisais chaque octet individuellement, l'endian de l'octet envoyé serait incorrect et je devrais le convertir.
Endianness d'un octet ? Qu'est-ce que c'est que ça ? Les mots sont sensibles à l'endianness, les octets individuels ne le sont pas.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
6 votes
Voici mon moyen mnémotechnique pour ne pas oublier : Java n'étant pas un matériel mais plutôt virtuel, c'est le langage de l'internet. Le site ordre des octets du réseau est grand endian . Par conséquent, Java est grand endian .