J'ai une application Java qui reçoit des données sur une prise à l'aide d'un qui ne correspond pas nécessairement à ce que le système signale comme page de code. Par exemple: L'application peut recevoir l'octet 0x81, qui dans le code représente le caractère J'ai pu contourner ce problème pour un client qui a utilisé le code Page 850 En ajoutant une autre option de ligne de commande dans le fichier de commandes qui lance l'application: mais pas tous mes clients utilisent le code de la page 850, bien sûr. Comment puis-je obtenir Java d'utiliser une page de code compatible avec le système Windows sous-jacent? Ma préférence serait quelque chose que je pouvais simplement mettre dans le fichier de commandes, laissant le code Java intact: INPUTStreamReader . Il rapporte "CP1252" à partir de son getcoding méthode: ¼ . Le programme interprète cet octet avec code Page 1252, qui ne définit aucun caractère à cette valeur, donc je reçois une marque d'interrogation à la place.
4 Réponses :
En ce qui concerne le code Snippit, la bonne réponse consiste à utiliser le constructeur approprié pour INPUTStreamReader qui fait la conversion correcte du code. De cette façon, cela n'aura pas d'importance ce qui codant sur la valeur par défaut sur le système, vous savez que vous obtenez un codage correct qui correspond à ce que vous obtenez sur la prise.
Ensuite, vous pouvez spécifier le codage lorsque vous écrivez des fichiers si vous en avez besoin, plutôt que de compter sur le codage du système, mais bien sûr, lorsqu'ils ouvrent des fichiers sur ce système, ils peuvent avoir des problèmes, mais la prise en charge des systèmes Windows modernes UTF-8 Pour que vous puissiez écrire le fichier dans UTF-8 si vous devez (en interne Java représentant toutes les chaînes comme 16 bits Unicode).
Je penserais que c'est la "bonne" solution en général qui serait la plus compatible avec la plus grande gamme de systèmes sous-jacents.
+1. BTW sur mon système Windows 7 La page de code actif est 850, mais Java rapporte "CP1252" comme la propriété du système "File.Encoding".
Les clients et le serveur doivent être configurés avec le même codage, tout ce qui pourrait être pour un client donné. Une application non-Java envoie des données de caractères sur le serveur à l'aide de la page Code local, le serveur stocke les données, puis le serveur l'envoie à l'application Java. Personne ne stocke ce que la page de code est, car tant que tout le monde utilisait la même chose, cela n'a pas d'importance. Le problème est que l'application Java ne coopère pas; Il utilise toujours CP1252. (La solution "droite" consiste à modifier le protocole pour tout forcer, disons, UTF-8, mais un changement de protocole casse toutes les installations existantes.)
Ensuite, il semble que G_a a votre réponse. Une autre option consiste à avoir ce rapport d'application non-Java à votre application Java ce qu'elle pense que le codage est, puis utilisez le constructeur approprié, comme indiqué ci-dessus.
Windows a la complication ajoutée d'avoir deux codes de code actifs. Dans votre exemple, les 1252 et 850 sont corrects, mais ils dépendent de la manière dont le programme est exécuté. Pour les applications GUI, Windows utilisera la page de code ANSI, qui pour les langues de l'Europe occidentale sera généralement de 1252. Toutefois, la ligne de commande signalera le codépage OEM de 850 pour les mêmes localités.
Vous avez fait de vraies déclarations, mais je ne sais pas comment ils répondent à ma question. De toute évidence, la page Code OEM est celle que le programme Java doit être compatible avec. Comment puis-je choisir une valeur fichier en fonction de celle-ci? La façon dont le programme est exécuté est via java.exe .
Si la valeur de la page de code qui revenir à partir d'une commande CHCP renvoie la valeur dont vous avez besoin, vous pouvez utiliser la commande suivante pour obtenir la page de code ceci définit le code de code variable à la valeur de la page de code renvoyée à partir de CHCP Vous pouvez utiliser cette valeur dans votre fichier BAT en le préfixant avec cp
Cela semblait prometteur, mais il repose sur certaines hypothèses sur le format de la sortie CHCP , qui peut différer sur des systèmes non anglais. En allemand, par exemple, la page de code est à Token 3, et il y a une période après le numéro: "Codépage Aktive: 850."
C'est ainsi que cela fonctionne même pour un système allemand: pour / f "jetons = 2 Delims =:" " %% I in ('CHCP') SET CP = %% I , puis couper les espaces avec SET CP =% CP: =% et enfin ECHO CP% CP% CP% CP% CP% CP%
Voir cette solution ici: Get Windows CMD Codepage avec fichier de commandes ou commande unique
Le codage par défaut utilisé par modifier le codage via le commutateur code> code> affectera tous vos mécanismes de codage par défaut, y compris STDOUT / STDIN / STDIN / STDERR redirigé. Ce n'est pas une solution idéale. P> Je suis venu avec ce script WSH pouvant définir la console sur le code ANSI système, mais je n'ai pas compris comment passer à une police de manière programmatique. P > cmd.exe code> est cp850 code> (ou autre que "OEM" cp est originaire du système d'exploitation); Le codage du système est CP1252 CODE> (ou tout ce que "ANSI" CP est originaire du système d'exploitation). Détails de Gory ici . Une façon de découvrir l'encodage de la console serait de le faire Via le code natif (voir getconsoleOutPutCP a> pour codage de la console actuelle; voir getacp pour codage par défaut "ANSI"; etc .) . 'file: setacp.vbs
'usage: cscript /Nologo setacp.vbs
Set objShell = CreateObject("WScript.Shell")
'replace ACP (ANSI) with OEMCP for default console CP
cp = objShell.RegRead("HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001" &_
"\Control\Nls\CodePage\ACP")
WScript.Echo "Switching console code page to " & cp
objShell.Exec "chcp.com " & cp