Quelle page de codage / code est utilisée par cmd.exe?


271

Lorsque j'ouvre cmd.exe dans Windows, quel encodage utilise-t-il?

Comment puis-je vérifier quel encodage il utilise actuellement? Cela dépend-il de mon environnement régional ou y a-t-il des variables d'environnement à vérifier?

Que se passe-t-il lorsque vous tapez un fichier avec un certain encodage? Parfois, je reçois des caractères tronqués (encodage incorrect utilisé) et parfois cela fonctionne. Cependant, je ne fais confiance à rien tant que je ne sais pas ce qui se passe. Quelqu'un peut-il expliquer?

Réponses:


389

Oui, c'est frustrant - parfois typeet d'autres programmes impriment du charabia, et parfois ils ne le font pas.

Tout d'abord, les caractères Unicode ne s'afficheront que si la police de console actuelle contient les caractères . Utilisez donc une police TrueType comme Lucida Console au lieu de la police raster par défaut.

Mais si la police de la console ne contient pas le caractère que vous essayez d'afficher, vous verrez des points d'interrogation au lieu de charabia. Lorsque vous obtenez du charabia, il se passe plus que de simples paramètres de police.

Lorsque les programmes utilisent des fonctions d'E / S de bibliothèque C standard comme printf, le codage de sortie du programme doit correspondre au codage de sortie de la console, sinon vous obtiendrez du charabia. chcpaffiche et définit la page de codes actuelle. Toutes les sorties utilisant des fonctions d'E / S de bibliothèque C standard sont traitées comme si elles se trouvaient dans la page de codes affichée par chcp.

Faire correspondre l'encodage de sortie du programme avec l'encodage de sortie de la console peut être accompli de deux manières différentes:

  • Un programme peut obtenir la page de codes actuelle de la console en utilisant chcpou GetConsoleOutputCP, et se configurer pour sortir dans cet encodage, ou

  • Vous ou un programme pouvez définir la page de codes actuelle de la console en utilisant chcpou SetConsoleOutputCPpour faire correspondre l'encodage de sortie par défaut du programme.

Cependant, les programmes qui utilisent les API Win32 peuvent écrire des chaînes UTF-16LE directement sur la console avec WriteConsoleW. C'est le seul moyen d'obtenir une sortie correcte sans définir de pages de code. Et même lorsque vous utilisez cette fonction, si une chaîne n'est pas dans le codage UTF-16LE pour commencer, un programme Win32 doit passer la page de code correcte à MultiByteToWideChar. En outre, WriteConsoleWne fonctionnera pas si la sortie du programme est redirigée; plus de violon est nécessaire dans ce cas.

typefonctionne une partie du temps car il vérifie le début de chaque fichier pour une marque d'ordre d'octets (BOM) UTF-16LE , c'est-à-dire les octets 0xFF 0xFE. S'il trouve une telle marque, il affiche les caractères Unicode dans le fichier en utilisant WriteConsoleW indépendamment de la page de code actuelle. Mais pour typetout fichier sans nomenclature UTF-16LE, ou pour utiliser des caractères non ASCII avec une commande qui n'appelle pas, WriteConsoleWvous devrez définir la page de code de la console et le codage de sortie du programme pour qu'ils correspondent.


Comment le découvrir?

Voici un fichier de test contenant des caractères Unicode:

ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好

Voici un programme Java pour imprimer le fichier de test dans un tas de codages Unicode différents. Il pourrait être dans n'importe quel langage de programmation; il imprime uniquement des caractères ASCII ou des octets codés vers stdout.

import java.io.*;

public class Foo {

    private static final String BOM = "\ufeff";
    private static final String TEST_STRING
        = "ASCII     abcde xyz\n"
        + "German    äöü ÄÖÜ ß\n"
        + "Polish    ąęźżńł\n"
        + "Russian   абвгдеж эюя\n"
        + "CJK       你好\n";

    public static void main(String[] args)
        throws Exception
    {
        String[] encodings = new String[] {
            "UTF-8", "UTF-16LE", "UTF-16BE", "UTF-32LE", "UTF-32BE" };

        for (String encoding: encodings) {
            System.out.println("== " + encoding);

            for (boolean writeBom: new Boolean[] {false, true}) {
                System.out.println(writeBom ? "= bom" : "= no bom");

                String output = (writeBom ? BOM : "") + TEST_STRING;
                byte[] bytes = output.getBytes(encoding);
                System.out.write(bytes);
                FileOutputStream out = new FileOutputStream("uc-test-"
                    + encoding + (writeBom ? "-bom.txt" : "-nobom.txt"));
                out.write(bytes);
                out.close();
            }
        }
    }
}

La sortie dans la page de codes par défaut? Déchets totaux!

Z:\andrew\projects\sx\1259084>chcp
Active code page: 850

Z:\andrew\projects\sx\1259084>java Foo
== UTF-8
= no bom
ASCII     abcde xyz
German    ├ñ├Â├╝ ├ä├û├£ ├ƒ
Polish    ąęźżńł
Russian   ð░ð▒ð▓ð│ð┤ðÁð ÐìÐÄÐÅ
CJK       õ¢áÕÑ¢
= bom
´╗┐ASCII     abcde xyz
German    ├ñ├Â├╝ ├ä├û├£ ├ƒ
Polish    ąęźżńł
Russian   ð░ð▒ð▓ð│ð┤ðÁð ÐìÐÄÐÅ
CJK       õ¢áÕÑ¢
== UTF-16LE
= no bom
A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h         ♣☺↓☺z☺|☺D☺B☺
 R u s s i a n       0♦1♦2♦3♦4♦5♦6♦  M♦N♦O♦
 C J K               `O}Y
 = bom
 ■A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h         ♣☺↓☺z☺|☺D☺B☺
 R u s s i a n       0♦1♦2♦3♦4♦5♦6♦  M♦N♦O♦
 C J K               `O}Y
 == UTF-16BE
= no bom
 A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h        ☺♣☺↓☺z☺|☺D☺B
 R u s s i a n      ♦0♦1♦2♦3♦4♦5♦6  ♦M♦N♦O
 C J K              O`Y}
= bom
■  A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h        ☺♣☺↓☺z☺|☺D☺B
 R u s s i a n      ♦0♦1♦2♦3♦4♦5♦6  ♦M♦N♦O
 C J K              O`Y}
== UTF-32LE
= no bom
A   S   C   I   I                       a   b   c   d   e       x   y   z
   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                   ♣☺  ↓☺  z☺  |☺  D☺  B☺
   R   u   s   s   i   a   n               0♦  1♦  2♦  3♦  4♦  5♦  6♦      M♦  N
♦  O♦
   C   J   K                               `O  }Y
   = bom
 ■  A   S   C   I   I                       a   b   c   d   e       x   y   z

   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                   ♣☺  ↓☺  z☺  |☺  D☺  B☺
   R   u   s   s   i   a   n               0♦  1♦  2♦  3♦  4♦  5♦  6♦      M♦  N
♦  O♦
   C   J   K                               `O  }Y
   == UTF-32BE
= no bom
   A   S   C   I   I                       a   b   c   d   e       x   y   z
   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                  ☺♣  ☺↓  ☺z  ☺|  ☺D  ☺B
   R   u   s   s   i   a   n              ♦0  ♦1  ♦2  ♦3  ♦4  ♦5  ♦6      ♦M  ♦N
  ♦O
   C   J   K                              O`  Y}
= bom
  ■    A   S   C   I   I                       a   b   c   d   e       x   y   z

   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                  ☺♣  ☺↓  ☺z  ☺|  ☺D  ☺B
   R   u   s   s   i   a   n              ♦0  ♦1  ♦2  ♦3  ♦4  ♦5  ♦6      ♦M  ♦N
  ♦O
   C   J   K                              O`  Y}

Cependant, que se passe-t-il si nous typeles fichiers qui ont été enregistrés? Ils contiennent exactement les mêmes octets qui ont été imprimés sur la console.

Z:\andrew\projects\sx\1259084>type *.txt

uc-test-UTF-16BE-bom.txt


■  A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h        ☺♣☺↓☺z☺|☺D☺B
 R u s s i a n      ♦0♦1♦2♦3♦4♦5♦6  ♦M♦N♦O
 C J K              O`Y}

uc-test-UTF-16BE-nobom.txt


 A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h        ☺♣☺↓☺z☺|☺D☺B
 R u s s i a n      ♦0♦1♦2♦3♦4♦5♦6  ♦M♦N♦O
 C J K              O`Y}

uc-test-UTF-16LE-bom.txt


ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好

uc-test-UTF-16LE-nobom.txt


A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h         ♣☺↓☺z☺|☺D☺B☺
 R u s s i a n       0♦1♦2♦3♦4♦5♦6♦  M♦N♦O♦
 C J K               `O}Y

uc-test-UTF-32BE-bom.txt


  ■    A   S   C   I   I                       a   b   c   d   e       x   y   z

   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                  ☺♣  ☺↓  ☺z  ☺|  ☺D  ☺B
   R   u   s   s   i   a   n              ♦0  ♦1  ♦2  ♦3  ♦4  ♦5  ♦6      ♦M  ♦N
  ♦O
   C   J   K                              O`  Y}

uc-test-UTF-32BE-nobom.txt


   A   S   C   I   I                       a   b   c   d   e       x   y   z
   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                  ☺♣  ☺↓  ☺z  ☺|  ☺D  ☺B
   R   u   s   s   i   a   n              ♦0  ♦1  ♦2  ♦3  ♦4  ♦5  ♦6      ♦M  ♦N
  ♦O
   C   J   K                              O`  Y}

uc-test-UTF-32LE-bom.txt


 A S C I I           a b c d e   x y z
 G e r m a n         ä ö ü   Ä Ö Ü   ß
 P o l i s h         ą ę ź ż ń ł
 R u s s i a n       а б в г д е ж   э ю я
 C J K               你 好

uc-test-UTF-32LE-nobom.txt


A   S   C   I   I                       a   b   c   d   e       x   y   z
   G   e   r   m   a   n                   õ   ÷   ³       ─   Í   ▄       ▀
   P   o   l   i   s   h                   ♣☺  ↓☺  z☺  |☺  D☺  B☺
   R   u   s   s   i   a   n               0♦  1♦  2♦  3♦  4♦  5♦  6♦      M♦  N
♦  O♦
   C   J   K                               `O  }Y

uc-test-UTF-8-bom.txt


´╗┐ASCII     abcde xyz
German    ├ñ├Â├╝ ├ä├û├£ ├ƒ
Polish    ąęźżńł
Russian   ð░ð▒ð▓ð│ð┤ðÁð ÐìÐÄÐÅ
CJK       õ¢áÕÑ¢

uc-test-UTF-8-nobom.txt


ASCII     abcde xyz
German    ├ñ├Â├╝ ├ä├û├£ ├ƒ
Polish    ąęźżńł
Russian   ð░ð▒ð▓ð│ð┤ðÁð ÐìÐÄÐÅ
CJK       õ¢áÕÑ¢

La seule chose qui fonctionne est le fichier UTF-16LE, avec une nomenclature, imprimé sur la console via type.

Si nous utilisons autre chose que typepour imprimer le fichier, nous obtenons des ordures:

Z:\andrew\projects\sx\1259084>copy uc-test-UTF-16LE-bom.txt CON
 ■A S C I I           a b c d e   x y z
 G e r m a n         õ ÷ ³   ─ Í ▄   ▀
 P o l i s h         ♣☺↓☺z☺|☺D☺B☺
 R u s s i a n       0♦1♦2♦3♦4♦5♦6♦  M♦N♦O♦
 C J K               `O}Y
         1 file(s) copied.

Du fait qu'il copy CONn'affiche pas correctement Unicode, nous pouvons conclure que la typecommande a une logique pour détecter une nomenclature UTF-16LE au début du fichier et utiliser des API Windows spéciales pour l'imprimer.

Nous pouvons voir cela en ouvrant cmd.exedans un débogueur quand il type sort un fichier:

entrez la description de l'image ici

Après avoir typeouvert un fichier, il recherche une nomenclature de 0xFEFF—ie, les octets 0xFF 0xFEen petit-boutien — et s'il existe une telle nomenclature, typedéfinit un fOutputUnicodeindicateur interne . Ce drapeau est vérifié plus tard pour décider s'il faut appeler WriteConsoleW.

Mais c'est le seul moyen d'accéder typeà la sortie Unicode, et uniquement pour les fichiers qui ont des nomenclatures et qui sont en UTF-16LE. Pour tous les autres fichiers et pour les programmes qui n'ont pas de code spécial pour gérer la sortie de la console, vos fichiers seront interprétés en fonction de la page de code actuelle et apparaîtront probablement comme du charabia.

Vous pouvez émuler la façon dont les typesorties Unicode vers la console dans vos propres programmes comme ceci:

#include <stdio.h>
#define UNICODE
#include <windows.h>

static LPCSTR lpcsTest =
    "ASCII     abcde xyz\n"
    "German    äöü ÄÖÜ ß\n"
    "Polish    ąęźżńł\n"
    "Russian   абвгдеж эюя\n"
    "CJK       你好\n";

int main() {
    int n;
    wchar_t buf[1024];

    HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);

    n = MultiByteToWideChar(CP_UTF8, 0,
            lpcsTest, strlen(lpcsTest),
            buf, sizeof(buf));

    WriteConsole(hConsole, buf, n, &n, NULL);

    return 0;
}

Ce programme fonctionne pour imprimer Unicode sur la console Windows en utilisant la page de code par défaut.


Pour l'exemple de programme Java, nous pouvons obtenir un peu de sortie correcte en définissant manuellement la page de code, bien que la sortie soit gâchée de manière étrange:

Z:\andrew\projects\sx\1259084>chcp 65001
Active code page: 65001

Z:\andrew\projects\sx\1259084>java Foo
== UTF-8
= no bom
ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好
ж эюя
CJK       你好
 你好
好
�
= bom
ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好
еж эюя
CJK       你好
  你好
好
�
== UTF-16LE
= no bom
A S C I I           a b c d e   x y z
…

Cependant, un programme C qui définit une page de code Unicode UTF-8:

#include <stdio.h>
#include <windows.h>

int main() {
    int c, n;
    UINT oldCodePage;
    char buf[1024];

    oldCodePage = GetConsoleOutputCP();
    if (!SetConsoleOutputCP(65001)) {
        printf("error\n");
    }

    freopen("uc-test-UTF-8-nobom.txt", "rb", stdin);
    n = fread(buf, sizeof(buf[0]), sizeof(buf), stdin);
    fwrite(buf, sizeof(buf[0]), n, stdout);

    SetConsoleOutputCP(oldCodePage);

    return 0;
}

a une sortie correcte:

Z:\andrew\projects\sx\1259084>.\test
ASCII     abcde xyz
German    äöü ÄÖÜ ß
Polish    ąęźżńł
Russian   абвгдеж эюя
CJK       你好

La morale de l'histoire?

  • type peut imprimer des fichiers UTF-16LE avec une nomenclature quelle que soit votre page de code actuelle
  • Les programmes Win32 peuvent être programmés pour sortir Unicode sur la console, en utilisant WriteConsoleW.
  • D'autres programmes qui définissent la page de codes et ajustent leur encodage de sortie en conséquence peuvent imprimer Unicode sur la console, quelle que soit la page de codes au démarrage du programme
  • Pour tout le reste, vous devrez jouer avec chcp, et vous obtiendrez probablement toujours une sortie étrange.

73
Whoa, ce doit être la réponse la plus détaillée que j'ai jamais vue sur SO. Crédit supplémentaire pour les impressions de démontage et les compétences multilingues! Tout simplement magnifique, monsieur!
frappe aérienne le

2
On peut également vouloir étudier l'extension spécifique à Microsoft _setmode (_fileno (stdout), _O_U16TEXT) qui a été introduite dans VS2008. Voir stackoverflow.com/a/9051543 et stackoverflow.com/a/12015918 et msdn.microsoft.com/en-us/library/tw4k6df8(v=vs.90).aspx Outre les différences évidentes de portabilité entre _setmode () et SetConsoleOutputCP (), il peut également y avoir d'autres subtilités et effets secondaires cachés dans les deux approches qui ne sont pas entièrement compris à première vue. Si andrewdotn pouvait mettre à jour sa réponse avec des observations sur _setmode (fd, _O_U16TEXT), ce serait formidable.
JasDev

13
Bien que ce soit une excellente réponse, il est trompeur de dire que la console prend en charge UTF-16. Il est limité à UCS-2, c'est-à-dire limité aux caractères du plan multilingue de base (BMP). Lorsque le serveur de console Win32 (conhost.exe, de nos jours) a été conçu vers 1990, Unicode était une norme 16 bits, de sorte que le tampon d'écran de la console utilise un WCHAR 16 bits par cellule de caractère. Une paire de substitution UTF-16 s'imprime sous la forme de deux caractères de boîte.
Eryk Sun

3
@ user200783, le formulaire décomposé n'est pas pris en charge; généralement, on peut se transformer en un équivalent NFC. En outre, la console dans les paramètres régionaux occidentaux ne permet pas de mélanger des glyphes pleine largeur et demi-largeur. De plus, lors de l'utilisation de la page de codes 65001 (UTF-8), avant Windows 8 WriteFile, le nombre de caractères écrits au lieu du nombre d'octets était signalé. . Également en 65001, la lecture des caractères non ASCII échoue dans conhost.exe car elle suppose 1 octet ANSI par code UTF-16 lors de l'appel WideCharToMultiByte.
Eryk Sun

2
Les programmes de démonstration simples de cette réponse supposent que GetStdHandle(STD_OUTPUT_HANDLE)et C stdoutsont des descripteurs de console. En pratique, pour tester une console, vérifiez que cela GetConsoleModeréussit. N'utilisez pas non plus la _isattyfonction d' exécution C pour vérifier si un descripteur de fichier d'E / S faible est une console; qui vérifie simplement un périphérique en mode caractère, qui comprend NULentre autres. Au lieu de cela, appelez _get_osfhandleet vérifiez la poignée directement.
Eryk Sun

29

Type

chcp

pour voir votre page de codes actuelle (comme Dewfy l'a déjà dit).

Utilisation

nlsinfo

pour voir toutes les pages de codes installées et savoir ce que signifie votre numéro de page de codes.

Vous devez avoir installé le Kit de ressources Windows Server 2003 (fonctionne sur Windows XP) pour l'utiliser nlsinfo.


19
Fait intéressant, nlsinfoil ne semble pas exister sur mon Windows 7.
Joey

2
nlsinfon'existe pas non plus sur ma machine Windows XP SP3.
Thomas Owens

2
Oh je suis désolé. Je pense qu'il est livré avec les outils du Kit de ressources Windows Server. Je l'ai utilisé plusieurs fois sur ma machine Windows XP SP3 plus tôt et je ne savais pas qu'il n'était pas installé par défaut.
Cagdas Altinkaya

Ah, cela explique pourquoi il est là sur ma machine Vista, où je les ai installés.
Joey

4
nlsinfon'existe pas non plus sur la machine Windows 10E.
Yousha Aleayoub

21

Pour répondre à votre deuxième question re. comment fonctionne l'encodage, Joel Spolsky a écrit un excellent article d'introduction à ce sujet . Fortement recommandé.


13
Je l'ai lu et je le sais. Cependant, sous Windows, je me sens toujours perdu parce que le système d'exploitation et la plupart des applications semblent totalement ignorants de l'encodage.
danglund

5

La commande CHCP affiche la page de codes actuelle. Il a trois chiffres: 8xx et est différent de Windows 12xx. Donc, en tapant un texte uniquement en anglais, vous ne verrez aucune différence, mais une page de code étendue (comme le cyrillique) sera imprimée à tort.


5
CHCP ne montre ni 3 chiffres ni le format 8 ##. 437 est par exemple un codage américain, et c'est la norme de facto sur les systèmes anglais. - 65001 est un codage Unicode (si je me souviens bien, c'est UTF-8 et 65000 est UTF-7) et peut être choisi. CMD permet également de passer à la page de code 1250 par exemple, mais je ne sais pas depuis quand ces pages de code sont sélectionnables. (C'est sous Win7.)
Adam LS

4

Je suis frustré depuis longtemps par les problèmes de page de codes Windows et les problèmes de portabilité et de localisation des programmes C qu'ils provoquent. Les articles précédents ont détaillé les problèmes en détail, donc je ne vais rien ajouter à ce sujet.

Pour faire court, j'ai fini par écrire ma propre couche de bibliothèque de compatibilité UTF-8 sur la bibliothèque C standard Visual C ++. Fondamentalement, cette bibliothèque garantit qu'un programme C standard fonctionne correctement, dans n'importe quelle page de code, en utilisant UTF-8 en interne.

Cette bibliothèque, appelée MsvcLibX, est disponible en open source sur https://github.com/JFLarvoire/SysToolsLib . Caractéristiques principales:

  • Sources C codées en UTF-8, utilisant des chaînes C char [] normales et des API de bibliothèque C standard.
  • Dans n'importe quelle page de code, tout est traité en interne sous la forme UTF-8 dans votre code, y compris la routine principale () argv [], avec une entrée et une sortie standard automatiquement converties en la bonne page de code.
  • Toutes les fonctions du fichier stdio.h prennent en charge les noms de chemin UTF-8> 260 caractères, jusqu'à 64 Ko en fait.
  • Les mêmes sources peuvent se compiler et se lier avec succès dans Windows en utilisant Visual C ++ et MsvcLibX et la bibliothèque C Visual C ++, et sous Linux en utilisant gcc et la bibliothèque C standard Linux, sans avoir besoin de blocs #ifdef ... #endif.
  • Les ajouts incluent des fichiers communs à Linux, mais manquants dans Visual C ++. Ex: unistd.h
  • Ajoute des fonctions manquantes, comme celles pour les E / S de répertoire, la gestion des liens symboliques, etc., le tout avec le support UTF-8 bien sûr :-).

Plus de détails dans le fichier Lisezmoi MsvcLibX sur GitHub , y compris comment construire la bibliothèque et l'utiliser dans vos propres programmes.

La section de publication du référentiel GitHub ci-dessus fournit plusieurs programmes utilisant cette bibliothèque MsvcLibX, qui montreront ses capacités. Ex: Essayez mon outil which.exe avec des répertoires avec des noms non ASCII dans le CHEMIN, en recherchant des programmes avec des noms non ASCII et en changeant les pages de codes.

Un autre outil utile est le programme conv.exe. Ce programme peut facilement convertir un flux de données de n'importe quelle page de code à n'importe quelle autre. Sa valeur par défaut est entrée dans la page de codes Windows et sortie dans la page de codes de la console actuelle. Cela permet de visualiser correctement les données générées par les applications Windows GUI (ex: Bloc-notes) dans une console de commande, avec une commande simple comme:type WINFILE.txt | conv

Cette bibliothèque MsvcLibX n'est en aucun cas complète et les contributions pour l'améliorer sont les bienvenues!


2

En Java, j'ai utilisé l'encodage "IBM850" pour écrire le fichier. Cela a résolu le problème.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.