J'ai un probleme d'ordre esthétique avec l'envoi du résultat d'une commande dans un fichier,
le jeu de caractère de windows (FR) n'est pas pris en compte par la commande ">" et je me retrouve donc avec des accents tronqués et 1 texte quelques fois incompréhensible en lecture rapide...
 

 
renvoie
 

 
donc si quelqu'un sait comment faire ce serait sympa merci

J'avais écrit un filtre DOS pour transcoder des fichiers ASCII DOS pour les lire sous Windows 3. KI_WIN sur mon site ouèbe (rubrique "softs perso" ).
 
Ca devient
dir C:\Windows\system32 /P /AD D | KI_WIN > C:\lol.txt

Crée ton batch avec PowerBatch astase.com il transcode les fichiers automatiquement  
 
si j'ai bien compris ton problème

Tu peux essayer de lancer cmd  avec /u ,
comme ca : cmd /u
 

Ici c'est l'histoire de conversion ANSI-OEM. cmd /u pour le support Unicode ne peut pas aider
 
PowerBatch non plus, puisque ce n'est pas l'entrée de la commande qu'il faut traiter mais la sortie.
 
La soluce de Carbon_14 est la bonne. J'avais aussi confronté à ce souci et pas trouvé une réponse "ad-hoc". Finalement, j'ai dû aussi m'écrire un utilitaire perso qui fait cette conversion.

 
 
Moi aussi je me suis fait mon propre programme  ,
mais cmd /u fontionne , regarde  :
 
 Le volume dans le lecteur F n'a pas de nom.
 Le numéro de série du volume est 1CE7-FD94
 
 Répertoire de F:\
 
22/10/2004  13:59            18 725 main.exe
22/10/2004  11:52             3 563 main.cpp

Sous Win2K, il met des caractères superfétatoires entre chaque lettre. Bizarre... (tellement que le copier/coller ne marche pas sous PFE)
 
Sous éditeur hexa, le fichier lol.txt commence par 20 00 H et chaque caractère ASCII est précédé d'un 00H (pas glop car c'est un terminateur naturel en C de chaîne, donc pas copiable -> chaîne nulle).  
 
Par contre, sans redirection, le DIR semble pas mal. Avec ou sans le commutateur /u.  

Ce n'est pas la sortie affichée à l'écran qui pose le problème mais quand tu la rediriges dans un fichier texte (cf. premier post du topic).
 
@Carbon_14 : c'est normal : le nombre d'octets utilisés par caractère n'est plus le même.

 
 
C'etait le contenu du fichier la mon truc , mébon .

Sous quel OS ?
Avec Win2K, c'est castatropfique...    
Quand j'allume le portable, je teste sous XP.

Je ne mens pas
 

 
 
Ta raison ,  mais avec notepad tu peux voir la difference sur le fichier de sortie  
entre faire cmd  ou cmd / u  , c'est ca que j'avais pigé a la question de départ .

Parce que la version Notepad de XP supporte (automatiquement) l'Unicode Ce que tu vois n'est pas le contenu réel du fichier.

Merci bien