Runtime.Exec et UTF8

Version imprimable

22/04/2011, 10h49
Plopeur

Runtime.Exec et UTF8

Bonjour,

Je souhaiterais exécuter cette commande dans mon programme java, mais ca ne fonctionne pas:

Code:

Runtime.getRuntime().exec("explorer "+"D:\\한국어");

Je reçois une erreur comme cela:

The path "D:\\???" does not exist.

Quelqu'un sait comment faire?

Merci par avance
22/04/2011, 10h58
tchize_
Vous devez doublez les \ quand vous créez une string java.

Je vous recommande aussi de séparer l'application de ses argmuents, c'est plus clair à lire:
Code:

1 2 3 4 Runtime.getRuntime().exec(new String[] { "explorer ", "D:\\\\한국어"} );
22/04/2011, 11h04
Plopeur

Merci pour votre réponse, cependant le soucis ne semble pas venir des \\\\, en effet, en faisant

Runtime.getRuntime().exec(new String[] {
"explorer ",
"D:\\toto"}
);

La commande fonctionne bien.
Il semblerait que ce soit lié aux caractères UTF8 :(

Êtes vus sûr que votre compilateur lit bien correctement votre fichier source (dans l'encodage qui a été utilisé pour le sauver) ?

Pourriez vous afficher le résultat de
Code:

1 2 3 4 5 6 7 public static void main(String[] args) throws FileNotFoundException, FontFormatException, IOException { String s = "한국어"; for (char c: s.toCharArray()) System.out.printf("0x%4X ",(long)c); System.out.println(); }
Vous devriez obtenir ceci si le compilateur fonctionne correctement:
Code:

1 2 0xD55C 0xAD6D 0xC5B4
Essayez aussi ceci pour votre code
Code:

1 2 3 4 5 Runtime.getRuntime().exec(new String[] { "explorer ", "D:\\\ud55c\uad6d\uC5B4"} );

22/04/2011, 11h37
Plopeur
Concernant la première partie ca fonctionne bien, j'ai bien eu comme output:
Code:

1 2 1 20xD55C 0xAD6D 0xC5B4
Par contre en faisant ca:
Code:

1 2 3 4 Runtime.getRuntime().exec(new String[] { "explorer ", "D:\\\ud55c\uad6d\uC5B4"} );
J'ai toujours l'erreur suivante

Code:

the path D:\\??? does not exists or is not a directory.

De plus quand je fais

Code:

Runtime.getRuntime().exec("D:\\한국어");

J'ai une erreur du genre

Code:

Cannot execute D:\\한국어

Le nom du dossier est bien pris en compte.
22/04/2011, 11h50
tchize_

il est possible que le nom du fichier sur le filesystem soit erroné.
Pourriez vous faire un

Code:

new File("D:\\").list()

et afficher le nom de tous les fichiers présents?
22/04/2011, 14h58
tchize_

je me souviens d'un bug report dans la jvm (lié à la classe File) qui mentionnait que java utilisait l'api windows prenant des char[] plutot que celle prenant des handle de fichier, et que ca posait problème avec certains caractères, c'est peut être lié.

PS: faudrait voir accessoirement, si du code équivalent en C en est capable, je connais pas les limites de windows.
22/04/2011, 15h06
tchize_

vous pourriez essayer d'ajouter

-Dfile.encoding=UTF-8

à votre appel à java?
22/04/2011, 17h27
deltree

Bonjour à tous.
vous êtes sûr qu'on peut faire de l'UTF-8 en ligne de commande?
parce que dans un bat par exemple, je suis presque sûr qu'il faut respecter l'encoding DOS: le CP437 ou CP850 (même pas le CP1252 de windows)
http://www.kostis.net/charsets/trans130/cpdos.htm

Un moyen de contournement faire un "Dir /x" pour avoir le nom du répertoire en nom 8.3 qui lui est ASCII et passe de partout.
22/04/2011, 18h51
tchize_

on ne parle pas de ligne de commande ici, mais de demander à l'os d'exécuté un programme identifié par son nom. LE fait que la ligne de commande ne supporte pas le nom, ne veux pas dire qu'on ne peux pas cliquer dessus pour l'exécuter ;)
24/04/2011, 11h22
deltree

D'accord Tchize, mais j'ai un doute car d'après la doc, on lance une commande, on passe donc par le système comme si c'était une ligne de commande:
http://download.oracle.com/javase/6/...va.lang.String[],%20java.lang.String[],%20java.io.File)

Mais en fait peu importe, ce qui est en UTF-8 est un argument (le dossier à faire ouvrir par l'explorer), et pas le programme lui-même; c'est donc peut-etre simplement le système qui limite l'encoding des arguments, et pas Java: est-ce que explorer.exe gère bien les arguments en UTF-8?

Sous windows on a toujours une double table d'allocation nom long-nom court(=8.3), Windows peut toujours s'en sortir avec le nom court.
=> d'ou mon idée de contournement, qui n'est pas très propre, mais quand on fait du exec, on a déjà renoncé à la portabilité.
24/04/2011, 12h04
thelvin

Citation:

Envoyé par deltree

Mais en fait peu importe, ce qui est en UTF-8 est un argument (le dossier à faire ouvrir par l'explorer), et pas le programme lui-même; c'est donc peut-etre simplement le système qui limite l'encoding des arguments, et pas Java: est-ce que explorer.exe gère bien les arguments en UTF-8?

Alors attention, il s'agit pas vraiment ici d'UTF-8 ou d'un charset quelconque. La commande est passée sous forme de Strings, on n'a donc pas la main sur un encodage. Après il faudra bien sûr passer par des octets pour parler aux fonctions systèmes de Windows, mais on n'a pas spécialement besoin d'UTF-8, Windows gère plutôt les noms de fichiers en UTF-16. Tous les tests que j'ai pu faire avec l'explorer tendent à indiquer qu'il peut ouvrir n'importe quel fichier dont le nom nécessite un charset unicode.

Il semble, toutefois, que java ne soit pas capable de passer des paramètres de commande utilisant tout unicode. Uniquement des paramètres qui utilisent codepage 1252. Les autres caractères sont transformés en points d'interrogation '?', cas typique de conversion de charset unicode vers codepage 1252, avec caractères qui n'existe pas dans codepage 1252.
Pourquoi codepage 1252 et pas autre chose, apparemment c'est dû aux réglages Windows. Changer le -Dfile.encoding Java n'a aucun effet. Mais changer la "langue par défaut des programmes non-Unicode" de Windows, si. Si je mets sur Japonais, je peux d'un seul coup passer des paramètres japonais en Java (et ce sont les accents qui deviennent des '?'.)

Ça m'a tout l'air insoluble.

Citation:

Envoyé par deltree

Sous windows on a toujours une double table d'allocation nom long-nom court(=8.3), Windows peut toujours s'en sortir avec le nom court.
=> d'ou mon idée de contournement, qui n'est pas très propre, mais quand on fait du exec, on a déjà renoncé à la portabilité.

Bonne idée quand c'est possible, mais cela suppose qu'on peut facilement obtenir le nom MS-DOS du fichier visé. C'est une grosse contrainte.
(Personnellement je suis très opposé aux noms de fichier non-ASCII, du fait que rien en informatique ne prévoie correctement ce cas et que ça pose toujours des problèmes. Mais c'est un peu compliqué de dire ça à nos amis coréens, chinois, japonais, russes, arabes...)