Problème "File.exists() et accents"

Version imprimable

27/01/2009, 17h37
mereyj

Problème "File.exists() et accents"
Bonjour,

Mon problème est le suivant. Je cherche à tester l'existence de fichiers sur le disque dur. Cela ne fonctionne pas pour les fichiers qui contiennent des accents.
Voici le code :
Code:

1 2 3 4 5 6 public static void main(String[] args) { String filename = args[0]; System.out.println(new File(filename).exists()); }
Je pense que cela vient de l'encodage.
L'os de la machine sur laquelle le code est exécuté est un unix.

Merci d'avance.
27/01/2009, 22h48
tchize_

je crois que ton problème c'est les arguments passés en paramètre. Vérifie les paramètres de ta console. Vérifie si cela fonctionne bien quand le nom de fichier est hardcodé dans le code java. Profite en aussi pour écrire dans une fichier temporaire, en utf-8, le nom demandé. Recharge ce fichier dans un éditeur de texte (ouverture absolument en utf-8) et vérifie que c'est correct (histoire d'etre certain d'etre indépendant de ta console ^^)
28/01/2009, 10h35
mereyj

J'ai essayé de le mettre en dur dans le code java mais rien n'y fait.
Je créé le fichier sous windows, je teste le bout de code ca fonctionne.
Je transfère le fichier sur la redhat, ça ne fonctionne plus.

Sans accent aucun problème.
Je me doute qu'il faut faire une transformation sur la chaine passée en paramètre au File.exists mais laquelle ?
28/01/2009, 11h22
JohnNC

Sur linux, la gestion des accents (et des espaces) est différente. Quel est le nom affiché sur red hat par la commande ls ? Et par l'auto-complétion ?
28/01/2009, 12h27
mereyj

Je me connecte avec putty donc cela dépend de l'encodage que je spécifie.
Avec l'encodage "ISO-8859-1", "t?t?" s'affiche au lieu de "tété".
28/01/2009, 13h08
tchize_

le problème viens pas de java, et donc java n'a aucune modification à faire dans les string. Ca viens du fait que le nom du fichier sur le disque n'est pas le même que ce que tu as tappé sur la console. Essaie déjà de faire passer ta console en utf-8. Et assure toi que le fichier a été envoyé correctement sur le serveur redhat.
28/01/2009, 13h13
JeitEmgie

Citation:

Envoyé par mereyj

Je me connecte avec putty donc cela dépend de l'encodage que je spécifie.
Avec l'encodage "ISO-8859-1", "t?t?" s'affiche au lieu de "tété".

si le programme de terminal et la JVM ne "s'entendent" pas sur l'encoding des arguments, ça ne fonctionnera jamais…

la variable "file.encoding" est censée contrôler l'encodage y compris des arguments en ligne de commande…

java -Dfile.encoding=…
28/01/2009, 13h18
mereyj
J'ai crée le fichier sous windows
J'ai essayé comme cela :
Code:

1 2 3 4 5 6 public static void main(String[] args) { String filename = "C:/tété"; System.out.println(new File(filename).exists()); }
Cela fonctionne.

Je transfère le fichier sur la redhat avec filezilla.
J'exécute le code suivant :
Code:

1 2 3 4 5 6 public static void main(String[] args) { String filename = "/home/user/test/tété"; System.out.println(new File(filename).exists()); }
Cela ne fonctionne pas.

Si je répète les mêmes opérations avec un fichier sans caractères spéciaux (accents...), cela fonctionne sur les deux environnements.

et ceci ?

Code:

1
2
3
4
5
6
 
public static void main(String[] args) 
{ 
        String filename = "/home/user/test/t\u00e9t\u00e9";  
        System.out.println(new File(filename).exists());
}

28/01/2009, 13h38
mereyj

Non plus
28/01/2009, 13h58
JeitEmgie

Citation:

Envoyé par mereyj

Non plus

donc c'est bien que la JVM considère un encoding par défaut qui n'est pas celui du file system…

(quel fichier avez-vous transférer "tété" ou le code source Java ?)
28/01/2009, 14h12
jean.2edi

Il faudrait savoir comment s'appelle ce fichier sous linux ! Est-ce que tu peux taper une commande dans le répertoire /home/user/test pour voir comment est codé le nom, par exemple :

Code:

ls t* | od -x
28/01/2009, 14h17
mereyj

C est le fichier "tété" créé sous windows que j'ai envoyé via filezilla sur ma redhat.

Avec la commande "ls t* | od -x" j obtiens :
0000000 e974 e974 000a
0000005
28/01/2009, 14h21
herch

Citation:

Sur linux, la gestion des accents (et des espaces) est différente. Quel est le nom affiché sur red hat par la commande ls ? Et par l'auto-complétion ?

C'est pourtant clair ce qu'il t'a dit.
quand tu crée tété sous windows, ça ne veut pas dire qu'il sera "tété" sous linux, c'est simplement t?t?, ou t@t@ ou un truc bizarre de ce genre, un é de windows n'est pas un é de linux.
donc, pour faire simple, commence par créer ton fichier tété sous linux, et non pas le transférer de windows vers linux
28/01/2009, 14h40
mereyj

C est aussi clair ce que j ai dit. Je n ai pas le choix.
On m envoie des fichiers que je dois injecter.
Je dois vérifier qu'ils sont bien présent avant de les injecter.
Et les utilisateurs créent leurs fichiers sous windows (Excel...)
Donc quelles modifications dans le code puis je faire pour voir les fichiers avec des accents une fois transférés sur la redhat ?
28/01/2009, 15h11
herch

c'est pas un problème de java, c'est un problème de compatibilité entre systèmes.
28/01/2009, 15h25
mereyj

J'ai compris que c était un problème d encodage mais il doit bien exister une méthode en java pour convertir la string dans le bon encodage.
Je ne pense pas être le seul qui ait eu a faire à ce problème.
28/01/2009, 15h26
JeitEmgie

Citation:

Envoyé par mereyj

C est aussi clair ce que j ai dit. Je n ai pas le choix.
On m envoie des fichiers que je dois injecter.
Je dois vérifier qu'ils sont bien présent avant de les injecter.
Et les utilisateurs créent leurs fichiers sous windows (Excel...)
Donc quelles modifications dans le code puis je faire pour voir les fichiers avec des accents une fois transférés sur la redhat ?

vérifier qu'il n'existe pas des paramètres dans Filezilla pour éviter le problème…

ou

utiliser un outil FTP qui respecte les encodings…
28/01/2009, 15h34
mereyj

Je ne pense pas que cela vienne de filezilla car j ai le même problème avec le lot de mon client qui est sous la forme d'un tar.gz qui contient les fichiers.

J'envoie le tar.gz sur le serveur redhat. Je le décompresse. Je voie bien les fichiers sans accent.

C est ce qui m a amené à faire ce test.
28/01/2009, 16h20
mereyj

N'ayant pas de solutions en java, j ai demandé a changer quelques variables
export LANG="fr_FR.ISO-8859-1"
export LC_ALL="fr_FR.ISO-8859-1"
export LANGUAGE="fr_FR.ISO-8859-1"
28/01/2009, 20h44
JeitEmgie

Citation:

Envoyé par mereyj

N'ayant pas de solutions en java, j ai demandé a changer quelques variables
export LANG="fr_FR.ISO-8859-1"
export LC_ALL="fr_FR.ISO-8859-1"
export LANGUAGE="fr_FR.ISO-8859-1"

avec tar essayez l'option "--format=posix"…
22/11/2010, 13h08
paflechien33

Bonjour à tous,

Désolé de déterrer ce post, mais il se trouve que je suis tombé récemment sur le même type de problématique.

Contrairement à certaines affirmations antérieures, il y a bien un bug java ouvert sur cette question :
Bug Java

A ce que j'en ai compris, point de salut en dehors de java 7 :cry: :cry:

Allez expliquer ça aux clients qui sont encore en java 5 :calim2:

Je suis toujours à la recherche d'un contournement là dessus, et si je trouve quelque chose de valable je reviendrai poster ici même.
22/11/2010, 13h29
tchize_

la meilleurs chose à dire à vos clients, c'est de ne pas casser leur filesystem. Le bug report que vous mentionnez fait état d'un problème lorsque des ficheir dont le nom est encodé en UTF-8 sont strocké sur une filesysteme non-utf8. C'est foutu d'office là. Même l'exlporateur windows s'emellera les pinceaux dessus. Il faut garder uen cohérence sur le filesystem. Et il faut définir la locale utilisée par java comme la même que celle utilisé par le système.

Les demandes du bug report c'est qu'on utiliser un array de byte pour identifier un fichier plutot qu'un String. Je comprend tout à fait la politique de sun/oracle à ce sujet de mettre ça en basse priorité. Ne cassez pas votre filesystem, pour commencer! Dans un filesystem correctement entretenu, tout fichier doit décement avoir une représentation textuelle possible.

Fuseau horaire GMT +2. Il est actuellement 09h10.