Java 8, chiffrement AES, encodage, Windows 10, invite de commande, batch et IDE
Résolu
Oliv
-
Oliv -
Oliv -
Hello world !
Et vous, qui allez, j'en suis sûr, répondre avec brio...
Voilà, j'ai un soucis lorsque j'exécute mon programme - un triolet de programmes en fait - son résultat diffère en fonction de son mode de lancement, à savoir :
soit depuis l'IDE (Eclipse 2020-03) sur lequel il est écrit avec comme arguments du Run Configuration de Encrypt :
output : GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA=
puis pour le Run Configuration de Decypher :
output : Aïe, aïe, ça écrit pô bien !
soit depuis l'invite de commande Windows 10 (variable environnement ad hoc) avec successivement :
output : GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA=
Puis :
output : Aïe, aïe, ça écrit pô bien !
soit depuis des fichiers batch (encodés en ANSI ou en UTF-8, même résultat) qui contiennent successivement :
output : 5JaO3P+T0ZAEv4+Xbc/bbGvykgT1R0zO7vquGvHF150=
Puis :
output : A´e, a´e, þa Úcrit p¶ bien !
Mais si je mets en second argument du batch du Decypher.jar le message chiffré que j'aurais obtenu par une des deux autres méthodes, l'encodage est ok, l'output est conforme.
Pourquoi Encrypt.jar donne un output différent suivant qu'on le lance directement depuis la console ou via un batch ? D'où cela vient-il ? Comment y remédier ?
Voici le triolet de programmes en question :
Merci de bien vouloir m'éclairer, l'encodage, entre l'unicode de la JVM, le cp1252 de ses flux par défaut sous Windows, et l'ANSI de Windows (est-ce à 100 % le cp1252 ?), n'est vraiment pas ma tasse de thé, d'autant que je ne sais pas où il se perd, ni même si c'est bien strictement un problème d'encodage de l'affichage console.
Et vous, qui allez, j'en suis sûr, répondre avec brio...
Voilà, j'ai un soucis lorsque j'exécute mon programme - un triolet de programmes en fait - son résultat diffère en fonction de son mode de lancement, à savoir :
soit depuis l'IDE (Eclipse 2020-03) sur lequel il est écrit avec comme arguments du Run Configuration de Encrypt :
"Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=" "Aïe, aïe, ça écrit pô bien !"
output : GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA=
puis pour le Run Configuration de Decypher :
"Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=" "GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA="
output : Aïe, aïe, ça écrit pô bien !
soit depuis l'invite de commande Windows 10 (variable environnement ad hoc) avec successivement :
java -jar "C:\Users\moi\Encrypt.jar" "Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=" "Aïe, aïe, ça écrit pô bien !"
output : GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA=
Puis :
java -jar "C:\Users\moi\Decypher.jar" "Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=" "GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA="
output : Aïe, aïe, ça écrit pô bien !
soit depuis des fichiers batch (encodés en ANSI ou en UTF-8, même résultat) qui contiennent successivement :
@echo off java -jar "C:\Users\moi\Encrypt.jar" "Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=" "Aïe, aïe, ça écrit pô bien !" pause
output : 5JaO3P+T0ZAEv4+Xbc/bbGvykgT1R0zO7vquGvHF150=
Puis :
@echo off java -jar "C:\Users\moi\Decypher.jar" "Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=" "5JaO3P+T0ZAEv4+Xbc/bbGvykgT1R0zO7vquGvHF150=" pause
output : A´e, a´e, þa Úcrit p¶ bien !
Mais si je mets en second argument du batch du Decypher.jar le message chiffré que j'aurais obtenu par une des deux autres méthodes, l'encodage est ok, l'output est conforme.
Pourquoi Encrypt.jar donne un output différent suivant qu'on le lance directement depuis la console ou via un batch ? D'où cela vient-il ? Comment y remédier ?
Voici le triolet de programmes en question :
class KeysGenerator {
public static void main(String _arguments[]) {
try {
KeyGenerator key_generator = KeyGenerator.getInstance("AES");
key_generator.init(256, SecureRandom.getInstanceStrong());
System.out.println(Base64.getUrlEncoder().encodeToString(key_generator.generateKey().getEncoded()));
} catch(NoSuchAlgorithmException _e) {
System.err.println("Erreur lors de la création de la clé : ".concat(_e.getMessage()));
}
}
}
class Encrypt {
public static void main(String _arguments[]) {
try {
Cipher _encrypt = Cipher.getInstance("AES");
_encrypt.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(Base64.getUrlDecoder().decode(_arguments[0]), "AES"));
System.out.println(Base64.getEncoder().encodeToString(_encrypt.doFinal(_arguments[1].getBytes())));
} catch(NoSuchAlgorithmException | NoSuchPaddingException | InvalidKeyException | IllegalBlockSizeException | BadPaddingException _e) {
System.err.println("Erreur lors du chiffrement : ".concat(_e.getMessage()));
}
}
}
class Decypher {
public static void main(String _arguments[]) {
try {
Cipher _decypher = Cipher.getInstance("AES");
_decypher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(Base64.getUrlDecoder().decode(_arguments[0]), "AES"));
System.out.println(new String(_decypher.doFinal(Base64.getDecoder().decode(_arguments[1]))));
} catch(NoSuchAlgorithmException | NoSuchPaddingException | InvalidKeyException | IllegalBlockSizeException | BadPaddingException _e) {
System.err.println("Erreur lors du déchiffrement : ".concat(_e.getMessage()));
}
}
}
Merci de bien vouloir m'éclairer, l'encodage, entre l'unicode de la JVM, le cp1252 de ses flux par défaut sous Windows, et l'ANSI de Windows (est-ce à 100 % le cp1252 ?), n'est vraiment pas ma tasse de thé, d'autant que je ne sais pas où il se perd, ni même si c'est bien strictement un problème d'encodage de l'affichage console.
1 réponse
-
Bonjour,
Effectivement tu t'es pris les pieds dans l'encodage.
Prenons une analogie avec les langues :- Eclipse fait une traduction du français vers l'anglais puis de l'anglais vers le français, c'est bon.
- L'invite de commandes fait une traduction du français vers l'allemand puis de l'allemand vers le français, donc c'est bon aussi.
Ton problème, c'est que tu demandes à Eclipse de faire une traduction du français vers l'anglais, puis à l'invite de commandes de traduire de l'allemand vers le français.
Or le texte en anglais ce n'est pas de l'allemand ! Donc la traduction de l'allemand à partir du texte anglais ça ne peut pas donner un français correct...
Dans ton code, le problème se situe ici au niveau de Encrypt_arguments[1].getBytes()
et de Decyphernew String(...)
, car ces méthodes prennent une valeur d'encodage par défaut, or si celle-ci est différente entre le chiffrement et le déchiffrement alors ça ne fonctionnera pas.
Ci dessous un petit code d'exemple pour comprendre : peu importe l'encodage choisi si on utilises le même lors de la conversion String/byte[] et byte[]/String ça fonctionnera, mais dès qu'on mélange les encodages, ça fera un peu n'importe quoi :
import java.nio.charset.Charset; import java.util.Arrays; public class Test { public static void main(String[] args) throws Exception { Charset c1 = Charset.forName("windows-1252"); Charset c2 = Charset.forName("UTF-8"); String text = "Aïe"; System.out.println("text"); // Aïe byte[] textC1 = text.getBytes(c1); System.out.println("c1\t" + Arrays.toString(textC1)); // 65, -17, 101 byte[] textC2 = text.getBytes(c2); System.out.println("c2\t" + Arrays.toString(textC2)); // 65, -61, -81, 101 String textC1C1 = new String(textC1, c1); System.out.println("c1c1\t" + textC1C1); // Aïe String textC2C2 = new String(textC2, c2); System.out.println("c2c2\t" + textC2C2); // Aïe String textC1C2 = new String(textC1, c2); System.out.println("c1c2\t" + textC1C2); // A?e String textC2C1 = new String(textC2, c1); System.out.println("c2c1\t" + textC2C1); // Aïe } }
Pour corriger ton code, il faut donc que tu imposes un encodage (peu importe lequel) pour que la conversion String/byte[] et byte[]/String soit cohérente.-
Un grand merci pour ta réponse, et plus encore pour sa rapidité !
Je ne vois pas trop où imposer l'encodage. En fait, a priori il était censé l'être car il me semble que Java compile toujours en encodant par défaut les caractères dans l'encodage par défaut du système, donc tout dans mon cas aurait été "censé" (dans mon cerveau) être en cp1252 puisque je n'ai rien précisé nul part.
D'autre part et surtout, pourquoi diable l'invite de commande (oublions l'exécution sur Eclipse qui "cache" souvent quelques bugs pourtant existants "grâce" à ses propres paramètres d'exécution) ne se rend compte de rien non plus ? Mon desarroi vient du fait que la même commande :
java -jar Encrypt.jar "cle" "message"
donne un résultat différent si elle est tapée manuellement sur l'invite de commande ou si c'est un batch (tapé manuellement) qui la "tape", l'encodage du fichier batch lui-même n'étant pas en cause, puisque changer sa valeur ne produit aucune différence d'aucune sorte.
Je sèche... -
"Je ne vois pas trop où imposer l'encodage."
Il faut reprendre mon code d'exemple, au lieu d'utiliserString.getBytes()
j'ai utiliséString.getBytes(Charset)
, de même dans l'autre sens au lieu d'utilisernew String(byte[])
j'ai utilisénew String(byte[], Charset)
.
"Imposer l'encodage" c'est s'assurer que le Charset utilisé dans un sens sera bien le même que dans l'autre sens, ce qui est impossible à garantir si ces deux opérations sont faites par des programmes différents, qui ont de toute évidence des Charset par défaut différent (tu peux afficherCharset.defaultCharset()
et voir sa valeur).
Remarque : attention aussi à l'encodage du fichier batch, s'il est écrit en UTF-8 (par exemple), il faudra le lire en UTF-8, alors que si tu écris en ligne de commande en windows-1252, il faudra le lire en windows-1252... -
"s'assurer que le Charset utilisé dans un sens sera bien le même que dans l'autre sens"
Mais il n'y a pas d'autre sens... :import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; import java.security.NoSuchAlgorithmException; import java.util.Base64; import javax.crypto.NoSuchPaddingException; import javax.crypto.BadPaddingException; import javax.crypto.IllegalBlockSizeException; import java.security.InvalidKeyException; class Encrypt { public static void main(String _arguments[]) { try { Cipher _encrypt = Cipher.getInstance("AES"); _encrypt.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(Base64.getUrlDecoder().decode(_arguments[0]), "AES")); System.out.println(Base64.getEncoder().encodeToString(_encrypt.doFinal(_arguments[1].getBytes()))); } catch(NoSuchAlgorithmException | NoSuchPaddingException | InvalidKeyException | IllegalBlockSizeException | BadPaddingException _e) { System.err.println("Erreur lors du chiffrement : ".concat(_e.getMessage())); } } }
Je parle de ce programme et de ce programme seul, les autres n'étaient là que pour tester l'ensemble éventuellement. Mais il est aussi bien indépendant et c'est donc en l'exécutant lui, et iui seul, que son résultat est différent. Lui, il ne se charge que de_encrypt.doFinal(_arguments[1].getBytes())
où _arguments[1] (et [0]) sont écrits manuellement dans l'invite de commande aussi bien que dans le fichier batch.
Tout cela se résume donc à :
invite de commande_encrypt.doFinal("Aïe, aïe, ça écrit pô bien !".getBytes()) //--> GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA=
fichier batch_encrypt.doFinal("Aïe, aïe, ça écrit pô bien !".getBytes()) //--> 5JaO3P+T0ZAEv4+Xbc/bbGvykgT1R0zO7vquGvHF150=
Sans passer par un autre programme (ni aucune des deux autres classes, qui sont aussi des programmes indépendants et qui pourraient aussi bien ne pas exister pour l'affaire qui nous occupe) avant, pendant ou après.
Et comme je l'ai mentionné, avoir écrit le batch dans le bloc note Windows, fait "Enregistrer sous...", l'avoir appelé "ansi.bat" et avoir choisir ANSI comme encodage avant de valider et de fermer le bloc note a donné très exactement le même résultat (erroné) qu'avoir ensuite écrit le même batch dans le bloc note Windows, fait "Enregistrer sous...", l'avoir appelé "utf8.bat" et avoir choisir UTF-8 comme encodage avant de valider et de fermer.
Je te remercie chaleureusement en tout cas de m'aider à creuser tout ça, mais snif, et même ouin, pour ne pas dire grrr, je ne comprend toujours pas... -
"Mais il n'y a pas d'autre sens..."
Quand je parlais de l'autre sens j'en étais au déchiffrement, c'est à dire à un problème de cohérence entre la conversion String →byte[] (Encrypt) et byte[] → String (Decrypt).
Mais il y a peut être un autre problème avant (ce qui n'empêche pas qu'il faudra traiter celui-ci quand même...)
Ci dessous, le même programme Encrypt (normalement), mais en décomposant pas à pas les opérations.
Exécutes le des deux côtés (batch et ligne de commandes) pour voir à quel moment il y a une différence.
Tu peux me copier-coller les résultats si tu ne trouves pas le problème par toi même.
import java.nio.charset.Charset; import java.util.Arrays; import java.util.Base64; import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; public class Encrypt { public static void main(String _arguments[]) throws Exception { System.out.println("charset\t" + Charset.defaultCharset()); System.out.println("key (base64)\t" + _arguments[0]); byte[] key = Base64.getUrlDecoder().decode(_arguments[0]); System.out.println("key (bytes)\t" + Arrays.toString(key)); Cipher _encrypt = Cipher.getInstance("AES"); _encrypt.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES")); System.out.println("input (String)\t" + _arguments[1]); byte[] input = _arguments[1].getBytes(); System.out.println("input (bytes)\t" + Arrays.toString(input)); byte[] output = _encrypt.doFinal(input); System.out.println("output (bytes)\t" + Arrays.toString(output)); System.out.println("output (base64)\t" + Base64.getEncoder().encodeToString(output)); System.out.println(); System.getProperties().forEach((k, v) -> System.out.println(k + "\t" + v)); } } -
Voici la sortie en utilisant l'invite de commande :
Microsoft Windows [version 10.0.18362.778]
(c) 2019 Microsoft Corporation. Tous droits réservés.
C:\Users\moi>java -jar "C:\Users\moi\Encrypt.jar" "Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=" "Aïe, aïe, ça écrit pô bien !"
charset windows-1252
key (base64) Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=
key (bytes) [18, -114, -108, 106, 109, -29, 3, 79, -82, -75, 59, 72, -9, -122, -29, -38, 83, -35, -70, -28, -72, 39, 47, 87, 62, -39, 16, 27, 125, 9, 67, 49]
input (String) Aïe, aïe, ça écrit pô bien !
input (bytes) [65, -17, 101, 44, 32, 97, -17, 101, 44, 32, -25, 97, 32, -23, 99, 114, 105, 116, 32, 112, -12, 32, 98, 105, 101, 110, 32, 33]
output (bytes) [26, 26, 76, -81, 33, -28, 28, -98, -82, 103, -50, -46, 102, 15, 53, -23, 30, 19, 108, 124, 26, -106, 44, -104, -59, 44, 51, -116, -100, -78, 122, 80]
output (base64) GhpMryHkHJ6uZ87SZg816R4TbHwaliyYxSwzjJyyelA=
java.specification.version 13
sun.cpu.isalist amd64
sun.jnu.encoding Cp1252
java.class.path C:\Users\moi\Encrypt.jar
java.vm.vendor Oracle Corporation
sun.arch.data.model 64
user.variant
java.vendor.url https://java.oracle.com/
java.vm.specification.version 13
os.name Windows 10
sun.java.launcher SUN_STANDARD
user.country FR
sun.boot.library.path C:\Program Files\Java\jdk-13.0.1\bin
sun.java.command C:\Users\moi\Encrypt.jar Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE= Aïe, aïe, ça écrit pô bien !
jdk.debug release
sun.cpu.endian little
user.home C:\Users\moi
user.language fr
sun.stderr.encoding cp850
java.specification.vendor Oracle Corporation
java.version.date 2019-10-15
java.home C:\Program Files\Java\jdk-13.0.1
file.separator \
java.vm.compressedOopsMode 32-bit
line.separator
sun.stdout.encoding cp850
java.vm.specification.vendor Oracle Corporation
java.specification.name Java Platform API Specification
user.script
sun.management.compiler HotSpot 64-Bit Tiered Compilers
java.runtime.version 13.0.1+9
user.name moi
path.separator ;
os.version 10.0
java.runtime.name Java(TM) SE Runtime Environment
file.encoding Cp1252
java.vm.name Java HotSpot(TM) 64-Bit Server VM
java.vendor.url.bug https://bugreport.java.com/bugreport/
java.io.tmpdir C:\Users\moi\AppData\Local\Temp\
java.version 13.0.1
user.dir C:\Users\moi
os.arch amd64
java.vm.specification.name Java Virtual Machine Specification
sun.os.patch.level
java.library.path C:\Program Files\Java\jdk-13.0.1\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files (x86)\Intel\TXE Components\iCLS\;C:\Program Files\Intel\TXE Components\iCLS\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\TXE Components\DAL\;C:\Program Files (x86)\Intel\TXE Components\DAL\;C:\Program Files\Intel\TXE Components\IPT\;C:\Program Files (x86)\Intel\TXE Components\IPT\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Java\jdk-13.0.1\bin\;C:\Users\moi\AppData\Local\Microsoft\WindowsApps;;.
java.vm.info mixed mode, sharing
java.vendor Oracle Corporation
java.vm.version 13.0.1+9
sun.io.unicode.encoding UnicodeLittle
java.class.version 57.0
C:\Users\moi>
Voilà celle en utilisant un batch encodé en ANSI
charset windows-1252
key (base64) Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=
key (bytes) [18, -114, -108, 106, 109, -29, 3, 79, -82, -75, 59, 72, -9, -122, -29, -38, 83, -35, -70, -28, -72, 39, 47, 87, 62, -39, 16, 27, 125, 9, 67, 49]
input (String) A´e, a´e, þa Úcrit p¶ bien !
input (bytes) [65, -76, 101, 44, 32, 97, -76, 101, 44, 32, -2, 97, 32, -38, 99, 114, 105, 116, 32, 112, -74, 32, 98, 105, 101, 110, 32, 33]
output (bytes) [-28, -106, -114, -36, -1, -109, -47, -112, 4, -65, -113, -105, 109, -49, -37, 108, 107, -14, -110, 4, -11, 71, 76, -50, -18, -6, -82, 26, -15, -59, -41, -99]
output (base64) 5JaO3P+T0ZAEv4+Xbc/bbGvykgT1R0zO7vquGvHF150=
java.specification.version 13
sun.cpu.isalist amd64
sun.jnu.encoding Cp1252
java.class.path C:\Users\moi\Encrypt.jar
java.vm.vendor Oracle Corporation
sun.arch.data.model 64
user.variant
java.vendor.url https://java.oracle.com/
java.vm.specification.version 13
os.name Windows 10
sun.java.launcher SUN_STANDARD
user.country FR
sun.boot.library.path C:\Program Files\Java\jdk-13.0.1\bin
sun.java.command C:\Users\moi\Encrypt.jar Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE= A´e, a´e, þa Úcrit p¶ bien !
jdk.debug release
sun.cpu.endian little
user.home C:\Users\moi
user.language fr
sun.stderr.encoding cp850
java.specification.vendor Oracle Corporation
java.version.date 2019-10-15
java.home C:\Program Files\Java\jdk-13.0.1
file.separator \
java.vm.compressedOopsMode 32-bit
line.separator
sun.stdout.encoding cp850
java.vm.specification.vendor Oracle Corporation
java.specification.name Java Platform API Specification
user.script
sun.management.compiler HotSpot 64-Bit Tiered Compilers
java.runtime.version 13.0.1+9
user.name moi
path.separator ;
os.version 10.0
java.runtime.name Java(TM) SE Runtime Environment
file.encoding Cp1252
java.vm.name Java HotSpot(TM) 64-Bit Server VM
java.vendor.url.bug https://bugreport.java.com/bugreport/
java.io.tmpdir C:\Users\moi\AppData\Local\Temp\
java.version 13.0.1
user.dir C:\Users\moi\Desktop
os.arch amd64
java.vm.specification.name Java Virtual Machine Specification
sun.os.patch.level
java.library.path C:\Program Files\Java\jdk-13.0.1\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files (x86)\Intel\TXE Components\iCLS\;C:\Program Files\Intel\TXE Components\iCLS\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\TXE Components\DAL\;C:\Program Files (x86)\Intel\TXE Components\DAL\;C:\Program Files\Intel\TXE Components\IPT\;C:\Program Files (x86)\Intel\TXE Components\IPT\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Java\jdk-13.0.1\bin\;C:\Users\moi\AppData\Local\Microsoft\WindowsApps;;.
java.vm.info mixed mode, sharing
java.vendor Oracle Corporation
java.vm.version 13.0.1+9
sun.io.unicode.encoding UnicodeLittle
java.class.version 57.0
Appuyez sur une touche pour continuer...
Et enfin celle en utilisant un batch encodé en UTF-8 (contrairement à ce que je disais le résultat n'est pas le même, mais c'est quand même une erreur et je ne peux l'enregistrer que dans l'un ou l'autre)
charset windows-1252
key (base64) Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE=
key (bytes) [18, -114, -108, 106, 109, -29, 3, 79, -82, -75, 59, 72, -9, -122, -29, -38, 83, -35, -70, -28, -72, 39, 47, 87, 62, -39, 16, 27, 125, 9, 67, 49]
input (String) A+»e, a+»e, +ºa +®crit p+¦ bien !
input (bytes) [65, 43, -69, 101, 44, 32, 97, 43, -69, 101, 44, 32, 43, -70, 97, 32, 43, -82, 99, 114, 105, 116, 32, 112, 43, -90, 32, 98, 105, 101, 110, 32, 33]
output (bytes) [-92, -28, -65, 36, -110, -64, 74, 71, 95, 29, 11, -112, 15, -114, 126, -120, -43, -47, -111, 94, 10, -28, 28, -112, -11, -104, -128, 97, -17, -39, -13, 97, 4, -7, 32, -98, 46, -17, 16, -109, 15, -47, 68, 0, -83, -56, -82, 120]
output (base64) pOS/JJLASkdfHQuQD45+iNXRkV4K5ByQ9ZiAYe/Z82EE+SCeLu8Qkw/RRACtyK54
java.specification.version 13
sun.cpu.isalist amd64
sun.jnu.encoding Cp1252
java.class.path C:\Users\moi\Encrypt.jar
java.vm.vendor Oracle Corporation
sun.arch.data.model 64
user.variant
java.vendor.url https://java.oracle.com/
java.vm.specification.version 13
os.name Windows 10
sun.java.launcher SUN_STANDARD
user.country FR
sun.boot.library.path C:\Program Files\Java\jdk-13.0.1\bin
sun.java.command C:\Users\moi\Encrypt.jar Eo6Uam3jA0-utTtI94bj2lPduuS4Jy9XPtkQG30JQzE= A+»e, a+»e, +ºa +®crit p+¦ bien !
jdk.debug release
sun.cpu.endian little
user.home C:\Users\moi
user.language fr
sun.stderr.encoding cp850
java.specification.vendor Oracle Corporation
java.version.date 2019-10-15
java.home C:\Program Files\Java\jdk-13.0.1
file.separator \
java.vm.compressedOopsMode 32-bit
line.separator
sun.stdout.encoding cp850
java.vm.specification.vendor Oracle Corporation
java.specification.name Java Platform API Specification
user.script
sun.management.compiler HotSpot 64-Bit Tiered Compilers
java.runtime.version 13.0.1+9
user.name moi
path.separator ;
os.version 10.0
java.runtime.name Java(TM) SE Runtime Environment
file.encoding Cp1252
java.vm.name Java HotSpot(TM) 64-Bit Server VM
java.vendor.url.bug https://bugreport.java.com/bugreport/
java.io.tmpdir C:\Users\moi\AppData\Local\Temp\
java.version 13.0.1
user.dir C:\Users\moi\Desktop
os.arch amd64
java.vm.specification.name Java Virtual Machine Specification
sun.os.patch.level
java.library.path C:\Program Files\Java\jdk-13.0.1\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files (x86)\Intel\TXE Components\iCLS\;C:\Program Files\Intel\TXE Components\iCLS\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\TXE Components\DAL\;C:\Program Files (x86)\Intel\TXE Components\DAL\;C:\Program Files\Intel\TXE Components\IPT\;C:\Program Files (x86)\Intel\TXE Components\IPT\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Java\jdk-13.0.1\bin\;C:\Users\moi\AppData\Local\Microsoft\WindowsApps;;.
java.vm.info mixed mode, sharing
java.vendor Oracle Corporation
java.vm.version 13.0.1+9
sun.io.unicode.encoding UnicodeLittle
java.class.version 57.0
Appuyez sur une touche pour continuer...
De ce que je vois, les encodages sont les mêmes via l'invite de commande et via les batch, pourtant l'output est différent... à cause de l'input, mais dans ce cas, pourquoi, comment peut-il lire la clé sans erreur dans le même input ?
