Discussion :

[Plopeur]

Bonjour,

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

Code x :

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

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

[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 x :

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

1
2
3
4
Runtime.getRuntime().exec(new String[] {
              "explorer ",
              "D:\\\\한국어"}
              );

[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

[tchize_]

Ê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 x :

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

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 :

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

1
2
 
0xD55C 0xAD6D 0xC5B4

Essayez aussi ceci pour votre code

Code :

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

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

[Plopeur]

Concernant la première partie ca fonctionne bien, j'ai bien eu comme output:

Code :

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

1
2
1
20xD55C 0xAD6D 0xC5B4

Par contre en faisant ca:

Code :

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

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

J'ai toujours l'erreur suivante

Code :

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

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

De plus quand je fais

Code x :

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

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

J'ai une erreur du genre

Code x :

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

Cannot execute D:\\한국어

Le nom du dossier est bien pris en compte.

[tchize_]

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

Code :

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

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

et afficher le nom de tous les fichiers présents?

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

[tchize_]

vous pourriez essayer d'ajouter

-Dfile.encoding=UTF-8

à votre appel à java?

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

[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

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

[thelvin]

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.

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