Discussion :

[drKzs]

Bonjour,

Je fait un client/serveur basé sur des sockets. Point principal, je veux envoyer depuis le client une liste avec des noms de fichiers, que le serveur récupère et utilise (ouverture fichiers, listing, etc...)

Comme les noms de fichiers ont parfois un encodage exotique, je veux les envoyer en tableau de byte (je suis sous linux du coté serveur, donc les méthodes primitives me permettront d'ouvrir les fichiers sans problème même si l'encodage n'est pas réellement défini).

Mon problème se situe au niveau client. Comment puis-je faire pour récupérer (à partir d'un fichier de config ou directment du filesystem) les noms des fichiers directement en byte ? Car en général dans l'API Java (que je ne connais pas très bien je l'avoue), je récupère des String. Hors si je me trompe pas, les String en Java sont toujours encodées (UTF16 par défaut)...

Merci

[thelvin]

À ma connaissance, ce n'est pas possible. Il faudrait faire une bibliothèque JNI pour ça.

Note que pour transformer une String en tableau de bytes, il suffit de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

byte[] bytes = "Bonjour à tous !".getBytes("utf-16LE");

par exemple.

Mais cela ne te dira pas quels étaient les octets originels pour représenter le nom de fichier : ces octets ont été transformés en String d'une manière inconnue et ne sont plus accessibles. Et après tu retransformes cette String en octets en utilisant un charset quelconque.

Cela dit, si je ne me trompe pas, Windows utilise canoniquement UTF-16LE pour les noms de fichiers.

[drKzs]

Oui, c'est bien là mon problème, je ne peux pas récupérer le nom de fichier en conservant le charset inconnu, le passage par une String casse tout Il faudrait que le constructeur String prenne en compte un charset null, que l'API Java donne des accès utilisant directement un tableau de bytes...

Mais comme tu le précise, une solution, JNI....

[Logan Mauzaize]

Il n'y a pas d'encodage pour les char !
C'est une représentation interne qu'on appelle codepoint (Voir UNICODE sur Wikipedia ou le site officiel)
UTF-8, UTF-16 c'est un moyen de stockage de ces codepoint.

Unicode c'est une représentation (binaire) d'un caractère et non un encodage.
Un encodage permet de stocker la représentation d'un caractère.

Si tu veux transférer des caractères soit tu transfères en encodant (ca permet de gagner de la place) soit tu transfères leur réprésentation binaire (en Java il suffit de caster un char en int et inversement).
Cependant attention car la méthode write(int) de l'OutputStream n'écrit que le plus petit octet.

Writes the specified byte to this output stream. The general contract for write is that one byte is written to the output stream. The byte to be written is the eight low-order bits of the argument b. The 24 high-order bits of b are ignored.

source

[drKzs]

Oui je ne dis pas le contraire, c'est justement pour cela que j'utilise les byte pour transférer mes noms de fichiers

C'est pour le point d'entrée le plus gênant (pour moi, car je suis pas très avancé en java).

C'est bon pour les récupérer à partir d'un fichier (fichier contenant les noms de fichiers écrits en encodage exotique), en utilisant un FileInputStream pas de soucis...

Mais c'est un workaround, maintenant je vais essayer de récupérer les noms de fichier directement à partir du filesystem.

[thelvin]

Note que, même si je comprends ce que tu dis, au fond Nemek n'a pas tort en disant que tu n'as pas la bonne approche.

Les "noms de fichiers exotiques", en principe sous Windows, ne sont pas constitués de bytes, mais plutôt de code points unicode de U+0 à U+FFFF, avec éventuel emploi des surrogates. Par conséquent, un nom comme a.txt ne devrait pas être constitué de 5 octets, mais 10 octets.
Or toi, tu t'attends à voir 5 "trucs", non ? 5 unités logiques. Je ne sais pas exactement ce que c'est censé être, peut-être des w_char, mais il est censé y en avoir 5 pour a.txt.

Ce qui te pose vraiment problème, ce n'est pas que tu n'as pas accès aux octets.
Ce qui te pose problème, c'est que tes noms de fichiers contiennent des caractères qui ne sont pas gérés dans le charset par défaut de ta plate-forme, or Java, sous Windows, ne lit et n'écrit les noms de fichiers qu'en passant par ce charset par défaut, au lieu de passer simplement par les APIs de fichier Unicode.
C'est là qu'il est le problème. Ce qu'il faudrait c'est une bibliothèque JNI qui lise les noms de fichiers avec une API plus moderne. Il me semble que c'est prévu dans le prochain JDK.

[deltree]

Bonjour,
Pour encoder sur un flux, il est plus pratique d'utiliser InputStreamReader et OutputStreamWriter qui travaillent sur des string, en précisant bien l'encoding dans le constructeur.
l'UTF-8 serait amha le plus pratique, puisqu'il contient tous les caractères spéciaux et est un sur-ensemble de l'ASCII. cela permet par exemple de brancher les programmes java sur un telnet.

edit pour la réponse arrivée entre-temps: Je ne comprend pas bien cette hiostoire de byte: les noms de fichier obtenu à partir de la classe "File" seront des String, on n'a besoin de manipuler la représentation interne de java, puisque par encodage-decodage, on le récupère sous la même forme de l'autre côté de la socket.