Java byte encodage

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 :)

À 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:

---

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.

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

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.

Citation:

---

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

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.

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.

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.

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

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 ?

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

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

Citation:

---

Envoyé par deltree

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.

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 ;))

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

Citation:

---

Envoyé par deltree

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.

Citation:

---

Envoyé par Nemek

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.

Citation:

---

Envoyé par drKzs

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.

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 ?

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:

---

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 :)

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

Code:

---

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

Citation:

---

Envoyé par Nemek

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.

Citation:

---

Envoyé par drKzs

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é.)

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 :oops:, j'espère quand même que ça fera avancer le schmilblick...

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

Citation:

---

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 ?

Citation:

---

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 :)

Citation:

---

Envoyé par thelvin

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.



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é.)

---

Je trouve ça plutôt pertinent au vue de la demande, ça aurait très bien pu être son problème !
Pour information as-tu essayé avec différentes versions de Java ?
La classe qui gère le mapping entre le système de fichier et Java, c'est la classe java.io.FileSystem. Il y a une implémentation spécifique pour Windows. Peut-être que le code natif était buggé ?
Il reste également possible que ce soit la version supporté d'Unicode qui est changée.

Citation:

---

Envoyé par drKzs

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.

---

Les noms des fichiers étant des String, ils sont "codés" en Unicode 4.0.
Sauf problème de conversion lié à un bug dans la classe FileSystem.
Il me semble que tout caractère Unicode est encodable en UTF-*, notemment grâce aux "surrogate pairs" (encodage d'un symbole sur plusieurs "code point").
Vérifies côté Java que le nom du fichier n'est pas "déformé" (N'utilises pas la console car elle n'est pas nécessairement dans un encodage compatible.

Ensuite le problème peut-être du côté C++ !

Citation:

---

Envoyé par drKzs

thelvin
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 ?

---

Le charset est utilisé pour convertir depuis ou vers les octets avec la représentation interne de Java qui n'utilise qu'un unique "codage".

Plus d'information sur la classe Character.

Bon, je vais essayer de te résumer ce qui se passe:

Sur le filesystem, j'ai un fichier. La nature même d'un filesystem fait que le nom du fichier est encodé sous forme binaire. Lorsque je demande à l'OS la liste des fichier d'un dossier, il existe deux manières de faire. Soit passer un char*, soit passer un byte*. Viens java et son API file. Cette API ne passe que par les appels de l'OS utilisant char*. L'OS ou JAva (faut voir les détaisl d'implémentation) va donc lire les byte[] du filesystem et les encoder suivant l'encodage utilisé pour monter le filesystem (c'est là qu'interviennent sous windows les bon vieux codepage). Et parfois, certains byte[] ne correspondent à rien et son traduits par du n'importe quoi, toujours au niveau de l'OS ou de l'implémentation interne java.

Et là, tu l'a dans le baba, parce que ca veux dire que tu obtiens au final un String qui ne peux même plus être utilisée correctement avec new File() ou new FileInputStream() :aie:
Bref, pour certains cas exotiques, t'as un fichier qui n'est tout simplement jamais ouvrable en java.

C'est un problème avec Java et il y a déjà eu des RFE sur le bugtrack demandant que les api nio de java permettent l'accès aux noms de fichier sous forme de byte[]. Mais on promet on promet mais on vois rien venir :)


Dans ton cas, pour localiser la cause réelle du problème: Pourrais tu faire ceci:

Prendre coté java la String que tu as récupérée et tenter d'ouvrir le Fichier en java via un new FileInputStream(cheminComplet). Si ca marche, alors il n'y a pas eu de perte au niveau java, et l'erreur est coté C++. Ce sera juste une question de faire ceci
1) envoyer à c++ le nom de fichier encodé en UTF-8
2) dans l'application C++ faire la conversion UTF-8 -> encodage attendu par l'OS

Si ce n'est pas le cas, tenter de relancer l'application java avec le paramètre -Dfile.encoding=.... mis à diférentes valeur (UTF-8, UTF-16LE, ISO8859-1 etc) histoire de voir si une des valeurs marche.

Si pas tu l'a dans l'OS :mrgreen:

aah oui, j'aime bien ce résumé :)

Effectivement, impossible de réouvrir le fichier avec un FileInputStream :) Cette erreur me plaît, elle est logique ( on s'attache à rien parfois ;) )

Je vais essayer le truc du -Dfile.encoding pour voir, c'est intéressant. Cela dit l'encodage ça pose tellement de problème, du coté client j'ai un problème Xerces avec l'ouverture d'un xml au nom (et pas le contenu, le nom!) exotique :mouarf:

Bon, je continue mes tests, je reviendrais :)

ce serait pas plutot un OS configuré avec des pieds palmés? Avoir une merde sur 1 fichier, ok, avoir des merde sur tous les fichiers: faut vraiment le faire exprès.

Les noms de ficheir apparaissent correctement dans l'explorateur de l'OS (explorer/nautilus/autre) ??

C'est un peu plus palmé que ça, en réalité je reçois plein de fichiers de différents OS (que je ne connais pas) avec différentes locales (que je ne connais pas), donc parfois ça passe, parfois ça casse... D'où mon envie que ce soit complètement transparent :)

Un exemple simple que j'avais fait dès le départ pour tester, je prends un fichier sous windows, avec un é. Je le copie sur mon client et mon serveur linux (locale UTF-8). Le nom s'affiche correctement sous Nautilus (pourquoi, je pensais qu'il utilisais la locale), mais pas sous la console, ni toutes les traces que je peux mettre dans mon programme C++ (via console eclipse configurée en UTF-8) : le é est affiché en ?.
Si je passe par l'API JAVA File pour récupérer le nom de fichier, il est corrompu dès le départ, vu avec ton test (donc même avant le passage dans la socket, et la réception par mon serveur C++): le é est flingué. Si je passe le nom directement en byte, c'est OP, ça s'affiche toujours mal à l'arrivée mais le nom arrive intact à l'autre bout de la chaîne :)

ca prouve simplement que la partie "je le copie sur linux" s'est mal passée. C'est pas à l'applicatif de rattraper les merdes faites sous l'OS.

Ici, sans aucun soucis:
En console: "touch Чиз.txt"
résultat du ls:

Code:

---

1 2 3

me@xxx:/tmp$ ls test/ Чиз.txt me@xxx:/tmp$

---

résultat du code java suivant:

Code:

---

1 2 3 4 5 6

public static void main(String[] args) throws IOException, ParseException { for (String file : new File("/tmp/test").list()) { System.out.println(file); } }

---

Code:

---

Чиз.txt

---

maintenant, si je monte un vfat avec le charset ISO-8859-1, que j'y met un fichier avec un nom cyrillique, que je démonte, puis que je remonte avec le charset ISO-8859-7, j'obtiens ceci dans la console:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

me@xxx:/tmp$ sudo mount -t vfat -o loop,iocharset=iso8859-1 somefat mounted/ me@xxx:/tmp$ sudo chmod a+w mounted/ me@xxx:/tmp$ sudo mv test/* mounted/ mv: impossible de préserver l'appartenance pour «mounted/Чиз2.txt»: Opération non permise mv: impossible de préserver l'appartenance pour «mounted/Чиз.txt»: Opération non permise me@xxx:/tmp$ ls mounted/ Чиз2.txt Чиз.txt me@xxx:/tmp$ sudo umount mounted/ me@xxx:/tmp$ sudo mount -t vfat -o loop,iocharset=iso8859-7 somefat mounted/ me@xxx:/tmp$ ls mounted/ ?????? ??????2.txt ??????.txt

---

et le résultat de mon code java dans ce cas

Code:

---

1 2 3

?�???�2.txt ?�???�.txt ?�?�?�

---

Bref c'est à l'OS hôte de ton application de faire ses mounts correctements.


Pour ce qui est de l'envoi, il suffit que tes clients parlent tous le meme charset que ton serveur, que tu définis à ce que tu veux, ca ne concerne que la communication client<-> serveur. Au client de faire la conversion String-> byte[] dans le charset choisi et au serveur de faire la conversion byte[] -> char* en respectant le charset en question.

Citation:

---

En console: "touch Чиз.txt"

---

Si je me trompe pas, ici c'est le même système qui le crée et le lit (via le code JAva, mais qui doit utiliser les locales système), donc ce cas-là est sans problème, effectivement.

Citation:

---

ca prouve simplement que la partie "je le copie sur linux" s'est mal passée

---

Justement, je ne suis pas sensé savoir comment (et doù) arrivent les fichiers, donc "le s'est mal passé", je risque d'y être souvent confronté (c'est même le cas normal en fait :mouarf:)

Citation:

---

C'est pas à l'applicatif de rattraper les merdes faites sous l'OS

---

Au contraire, c'est ce qui m'importe, avoir une méthode qui couvre le maximum de cas :)
Donc peu-importe comment a été convertit le nom, je veux simplement assurer que dans ma chaîne de bout en bout, je conserve la valeur brut du nom du fichier tel qu'il existe sur le système, sans rajouter d'encodage et risquer d'altérer un caractère, et assurer la conservation du nom ...

Citation:

---

Pour ce qui est de l'envoi, il suffit que tes clients parlent tous le meme charset que ton serveur, que tu définis à ce que tu veux, ca ne concerne que la communication client<-> serveur. Au client de faire la conversion String-> byte[] dans le charset choisi et au serveur de faire la conversion byte[] -> char* en respectant le charset en question.

---

Oui, il reste à choisir un charset qui ne dénature aucun caractère (en somme qui couvre tous les caractères sans utiliser de caractère de remplacement) du charset d'origine, que je ne connais pas. C'est pourquoi passer par les byte me semblait plus simple, élégant, et sûr.

si j'ai bien suivi ta logique, le fichier est visible depuis deux OS différent. donc si il y a eu une merde au montage, a moins d'avoir la chance d'avoir fait exactement al même erreur de chaque coté, je ne vois pas pourquoi les nom binaire vu (sous forme de uint*) d'un coté serait identique du nom vu de l'autre coté. (exemple: un monte en ISO-8859-7, l'autre en ISO-8859-4)

De toutes façon pour le nom en binaire, tu ne l'aura pas en java, point!

Citation:

---

Envoyé par drKzs

Oui, il reste à choisir un charset qui ne dénature aucun caractère (en somme qui couvre tous les caractères sans utiliser de caractère de remplacement) du charset d'origine, que je ne connais pas.

---

Tu ne t'en sortira pas pour autant. Ce n'est pas parce que deux encodages couvrent ont une plage commune de caractères qu'ils sont "compatibles" (même si on se limite à ces caractères en commun).

Par exemple, prend un fichier nommé:

Code:

---

Ÿ.txt

---

Sur ton client le FS utilise "Cp1252" donc en lisant directement les octets tu trouves:

Code:

---

9F 2E 74 78 74

---

Tu envois ces octets à ton serveur où le FS utilise "UTF-8" ce qui donne

Code:

---

C5 B8 2E 74 78 74

---

donc tes tableaux d'octets ne correspondent pas (ils n'ont même pas la même longueur d'ailleurs). Donc tu en déduis que ce ne sont pas les mêmes noms de fichiers !

Si j'ai bien suivi, sont problème est l'inverse, des deux cotés ils a

Code:

---

9F 2E 74 78 74

---

Maintenant, d'un coté c'est monté en cp1252, donc en string il obtiens Ÿ.txt quand il liste le répertoire, information qui est transmise au serveur.

De l'autre coté, serveur, il demande alors à ouvrir "Ÿ.txt" et le serveur cherche donc le fichier

Code:

---

C5 B8 2E 74 78 74

---

qui n'existe pas, car le fichier est

Code:

---

9F 2E 74 78 74

---

qui s'affiche ?.txt

Et ce qu'il voudrait ce serait plutot pouvoir directement transmettre
9F 2E 74 78 74 afin que coté server il fasse un open(9F 2E 74 78 74)

Citation:

---

si j'ai bien suivi ta logique, le fichier est visible depuis deux OS différent. donc si il y a eu une merde au montage, a moins d'avoir la chance d'avoir fait exactement al même erreur de chaque coté, je ne vois pas pourquoi les nom binaire vu (sous forme de uint*) d'un coté serait identique du nom vu de l'autre coté. (exemple: un monte en ISO-8859-7, l'autre en ISO-8859-4)

---

Oui, c'est complètement vrai ça :) Mais cette configuration là c'est pour mes premiers tests, en réalité les fichiers seront accessibles depuis le serveur, et la liste des noms sera du coté client. Comme ceux qui s'en occupent utilisent des appli Java et ont déjà eu le problème, je blinde ma partie le plus possible en faisant des tests tout moisis, et je suis tombé sur ce cas intéressant qui a donné dans ce forum une discussion intéressante :)

Citation:

---

De toutes façon pour le nom en binaire, tu ne l'aura pas en java, point!

---

oui, j'ai bien compris que ça se mérite :mouarf:

Citation:

---

Et ce qu'il voudrait ce serait plutot pouvoir directement transmettre
9F 2E 74 78 74 afin que coté server il fasse un open(9F 2E 74 78 74)

---

Oui c'est ça, un tunnel brut :)

comme déjà dit, c'est pas le tunnel le problème :)