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.

[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.

[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.

[drKzs]

hmm je commence à être perdu, mais la discussion est très intéressante
Essayons de répondre, pour voir où mon raisonnement s'écroule

Deltree:
Justement, je souhaite éviter de me préoccuper de l'encodage. Mais ton idée marcherait, dans le sens ou le codage/décodage doit en théorie assurer que la sortie est identique qu'à l'entrée. Reste à direau serveur quel encodage le client a utilisé pour stocker les données, et pour certaines classes de l'API Java, je ne sais pas lequel elles ont utilisées quand elles me renvoient une String...Je trouve l'utilisation des byte plus transparente, mais ça vaut le coup d'essayer aus

thelvin
Je n'ai pas tout compris... Au fond, je ne m'attend à aucun nombre précis d'octets pour a.txt (reprenons l'exemple ). Justement, le fait de charger des octets, transporter des octets, et "ouvrir des octets" (entendons par là ouvrir le fichier correspondant aux octets reçus) me dispense de gérer tout problème de charset, selon moi.
Maintenant, tu as raison quand tu dis que le problème de source est le charset de départ... Mais comme il n'est pas toujours évident de le déterminer, le plus simple me paraissait d'utiliser les octets.

Non ?

[deltree]

Merci au passage de ne mettre "-" qu'aux réponses hors sujet, et pas à ceux qui tentent de t'aider.

[drKzs]

euuh, j'ai peut-être fait une bêtise , mais je ne vois pas de quoi tu parles ?

[Logan Mauzaize]

Merci au passage de ne mettre "-" qu'aux réponses hors sujet, et pas à ceux qui tentent de t'aider.

Merci de ne pas incriminer tout le monde

Je réitère ma réponse sur le sujet, la classe File te renvoie des String qui contient des char et que les char représentent tous les caractères inimaginables.
Si tu veux pouvoir "transférer" n'importe quelle chaîne de caractères, il faut utiliser un encodage qui couvrent tout l'unicode comme les UTF-*.
Charges à toi ensuite de lire les données transférées avec le bon encodage.

[drKzs]

Donc Nemek, si je comprends bien ce que tu me dis, et que je schématises, en gros je récupère via la classe File le noms des fichiers sous forme de String contenant les char encodés en {charset-utilisé-par-défaut-en-java}. C'est ce charset que je devrais utiliser côté serveur pour manipuler les données reçues.

Mais ai-je bien compris, la principale différence avec "mon" approche par octets est le fait que j'encode d'un coté, puis que j'utilise cet encodage de l'autre ?
(et donc que je me coltine un encodage dont je me passerai bien puisque je finirais par utiliser une méthode qui prend des char en paramètres )

[Logan Mauzaize]

Java représente les caractères en interne en utilisant l'Unicode.

Cependant pour le transfert il faut utiliser un encodage car une représentation ce ne sont pas des octets à proprement parler.

Si tu veux transférer des caractères, il faut que tu utilises le même encodage point.

Quelques liens qui pourraient t'aider à comprendre la différence entre jeu de caractère et encodage :
http://fr.wikipedia.org/wiki/Unicode
http://fr.wikipedia.org/wiki/Codage_de_caract%C3%A8res
http://fr.wikipedia.org/wiki/UTF-8

[thelvin]

Merci au passage de ne mettre "-" qu'aux réponses hors sujet, et pas à ceux qui tentent de t'aider.

Tu essaies de l'aider et tu es hors-sujet, car le problème n'est pas situé aux endroits dont tu parles.
Ce qui devrait être clair en me lisant, ainsi qu'en essayant soi-même.
J'enlève les - mais ils servent pourtant à ça.
Sauf que c'est moi qui me suis planté de sujet, donc je m'écrase.

Je réitère ma réponse sur le sujet

Inutile, ce n'est pas de cela qu'il s'agit. Lisez-moi, svp.
Pareil.

Je n'ai pas tout compris... Au fond, je ne m'attend à aucun nombre précis d'octets pour a.txt (reprenons l'exemple ). Justement, le fait de charger des octets, transporter des octets, et "ouvrir des octets" (entendons par là ouvrir le fichier correspondant aux octets reçus) me dispense de gérer tout problème de charset, selon moi.

Plus ou moins... Selon les préconfigurations des programmes, Windows ne leur enverra pas les mêmes octets.
Java est malheureusement configuré comme les programmes pré-Unicode (et ce n'est pas réglable pour nous, seulement pour ceux qui font Java.)
Par conséquent, Windows ne lui envoie que des octets dans le charset de la plate-forme par défaut.
La plupart des programmes sont passés à la compatibilité Unicode, et reçoivent de l'UTF-16.
Un système Unix, en recevant des fichiers au nom en UTF-16, tirerait sévèrement la tronche.

[Logan Mauzaize]

Au final le problème est-il le transfert de noms de fichiers avec des caractères exotiques ?

Ou bien la manipulation de fichiers qui ont des noms exotiques ?
Dans ce dernier cas, est-il possible d'avoir un exemple de nom de fichier possible sous Windows mais qui pose problème en Java ?

[drKzs]

Oui, c'est pas faux, je pourrais être plus clair sur la problématique.

Sur le client, j'ai des fichiers avec des noms dont je ne connais pas l'encodage.
Sur le serveur, j'ai exactement ces mêmes fichiers (ne me demandez pas pourquoi )

Je veux envoyer ces noms par socket, les récupérer sur le serveur et les utiliser par exemple pour ouvrir les fichiers, ou les copier, etc etc....

Le client A est en Java sous windows, le serveur en C++ sous linux. Le passage se fait par socket.

Voici quel avait été mon raisonnement: vu que je peux avoir au départ différents encodages, plutot que de m'en préoccuper, je veux tout faire en byte.

Code :

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

   récupérer nom => transmission socket => ouverture via fopen

Aucun problème pour la réception et les traitements, car en C++ si je ne me trompe pas la classe std::string n'utilise pas de charset particulier, et semble être un container neutre pour passer les byte. C'est là que j'ai vu que la classe String en Java semblait altérer (au sens utiliser un charset particulier) les données. D'où ma question concernant la récupération du nom des fichiers sous forme de tableau de byte, et d'où cette discussion très intéressante

[Logan Mauzaize]

Dans ce cas le client doit envoyer du texte en utilisant en encodage universel (UTF-8 par exemple).

Code java :

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

1
2
3
4
5
6
7
8
9
OutputStream os = socket.getOutputStream();
OuputStreamWriter osw = new OutputStreamWriter(os, "UTF-8");
PrintWriter pw = new PrintWriter(osw);
for (String filename : filenames) {
  pw.println(filename);
}
pw.println(); // mark end of transfer
pw.flush();
pw.close();

Ensuite le serveur doit lire les données reçues en utilisant le même encode
Je mets pas de code car je connais pas le C++ mais il me semble que la STL fournie des objets pour gérés l'UTF-8 genre StringUTF ...

[thelvin]

Dans ce dernier cas, est-il possible d'avoir un exemple de nom de fichier possible sous Windows mais qui pose problème en Java ?

Il n'y a pas si longtemps, 日本.txt aurait été un tel exemple, sauf si le Windows est configuré en Japonais.
Bien sûr, à présent ça marche parfaitement sur tout ce que j'ai pu tester, histoire de me donner tort . (Il reste des malfonctions, mais seulement dans des cas bien plus compliqués qu'un simple listing de noms de fichiers à caractères visibles.)
Je présente donc mes plus plates excuses et invite le monde entier à moinsser tout ça.

Sur le client, j'ai des fichiers avec des noms dont je ne connais pas l'encodage.

UTF-16LE... Mais peu importe. Windows te donnera ce qu'il veut.
Pour le coup, c'est Deltree et Nemek qui ont raison, en fait : Java efface la notion d'encodage, en s'arrangeant avec Windows pour ne travailler qu'avec des caractères. Et apparemment, il ne se trompe plus.

Tu ne peux pas avoir "différents encodage" : deux noms de fichiers sont identiques ou équivalents ou différents. Cela n'a rien à voir avec l'encodage. Il n'y a rien dont tu aurais eu à te préoccuper à ce niveau-là (même si la situation que j'expose plus haut avait perduré.)

[-gma-]

Si l'on en croit la Javadoc de Character, lorsque le char en Java (2) a été conçu l'Unicode ne comportait des caractères que de U+0000 à U+FFFF

Depuis l'Unicode a été étendu et cela va maintenant de U+0000 à U+10FFFF (et que donc si l'on veut travailler sur la plage étendue il faut utiliser des int à la place des char, mais ce n'est pas là que je veux en venir)

Est-ce qu'on peut envisager des nom de fichiers (sous un OS ou un autre) qui contiendront des caractères entre U+FFFF et U+10FFFF ?

Si oui (et je le crois, la javadoc par du '\uD840') alors je pense que ça va être compliqué (impossible ?) de lire le nom de ces fichiers en utilisant java.io (pour revenir au problème initial si je l'ai bien compris)

Edit: non en fait mon raisonnement est faux car les String utilisent des "surrogate pairs" (toujours d'après la Javadoc) pour gérer ces cas.
Ca m'apprendra à aller jusqu'au bout avant de poster , j'espère quand même que ça fera avancer le schmilblick...

[drKzs]

hmm, désolé si je vais paraître un peu (arf) têtu ou obtu ....

Nemek
Je récupère les noms des fichiers en String en UTF8, je les envoies via la socket en UTF8, et je les récupère en UTF8, ok (en C++, la Glib donne la classe ustring qui permet la manipulation UTF8, pour la précision). Mais sous linux (sous windows je sais pas) , il arrive qu'il ne trouve pas le fichier car le nom a été encodé en UTF8, et que certains caractères n'ont pu être convertis.

thelvin

Pour le coup, c'est Deltree et Nemek qui ont raison, en fait : Java efface la notion d'encodage, en s'arrangeant avec Windows pour ne travailler qu'avec des caractères. Et apparemment, il ne se trompe plus.

Pourtant, je lis partout que lorsque tu crées une String, Java utilise forcément un charset (que tu peux préciser d'ailleurs dans le constructeur). Est-ce que je mélange les choses ?

Tu ne peux pas avoir "différents encodage" : deux noms de fichiers sont identiques ou équivalents ou différents. Cela n'a rien à voir avec l'encodage. Il n'y a rien dont tu aurais eu à te préoccuper à ce niveau-là (même si la situation que j'expose plus haut avait perduré.)

D'accord, sauf que dans certains charset utilisés au passage de byte vers une classe comme String en java ou Glib::ustring en C++, les caractères non reconnus sont remplacés par un caractère par défaut (ça me le fait en tout cas en UTF-8). Et donc au final, je n'ai plus le même nom de fichier.

Désolé si je vous fait tourner en rond