Chiffrer un fichier compatible windows

Forum d'aide générale sur Slackware
ecforum
Messages : 32
Inscription : 18 août 2017, 10:04

Chiffrer un fichier compatible windows

Message par ecforum » 24 juin 2018, 11:14

Bonjour,

C'est absolument HS dans un forum Slackware mais si vous avez une connaissance la dessus, ça m'aiderait...
Je voudrais envoyer un fichier chiffré en pièce jointe d'un mail.
Ceux qui reçoivent sont généralement sous Windows.
Voilà comment je fais mon archive :

Code : Tout sélectionner

7z a -p -tzip archive.zip fichiers
J'utilise -tzip car .zip est une extension que Windows prend en charge.

On m'a encore répondu la semaine dernière que ça indique "mot de passe incorrect".
J'ai testé sur un windows 7 : ca marchait pour moi.
J'ai eu des problèmes avec les lettres accentuées dans le mot de passe, donc je n'utilise que des lettres et des chiffres.

Ma commande est-elle correcte ?
Y a-t-il autre chose que les lettres accentuées qui poserait problème ?
Ou bien est-ce juste dû aux gens qui reçoivent le fichier (que ça gonfle peut-être) ?

Merci

Marc56
Messages : 2
Inscription : 25 juin 2018, 09:38

Re: Chiffrer un fichier compatible windows

Message par Marc56 » 25 juin 2018, 09:50

Hello,

Chez moi, ça marche, (sauf que ce n'est pas par 7z que je dois appeler 7-zip, mais, mais 7za (je n'ai pas fait d'alias))

Code : Tout sélectionner

7za a -p -tzip logfile.zip logfile
avec un 7z compilé du jour depuis les sources du site original
https://www.7-zip.org/download.html

Ma config: Slackware 14.2 x64 dans Virtual box

Code : Tout sélectionner

marc:~ $ 7za --help

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=fr_FR.UTF-8,Utf16=on,HugeFiles=on,64 bits,1 CPU x64)

marc:~ $ uname -a
Linux slackware.workgroup 4.9.67 #2 SMP Tue Dec 5 16:29:07 CST 2017 x86_64 Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz GenuineIntel GNU/Linux
Le fichier zip, transféré ensuite sur Windows 10 est parfaitement décompactable que ce soit dans le gestionnaire de fichier ou dans un autre (Total Commander), le mot de passe est demandé et accepté.
Je suis en UTF-8 partout

Marc
(Nouveau ici, mais très ancien utilisateur de Slackware)
;)

ecforum
Messages : 32
Inscription : 18 août 2017, 10:04

Re: Chiffrer un fichier compatible windows

Message par ecforum » 26 juin 2018, 07:45

Bonjour,

Merci pour ta réponse.
Moi je suis en "locale=en_US,Utf16=on". Wikipedia dit que utf16 est utilisé par Windows.
Je n'y connais rien, je dois dire.
Je vais avoir la possibilité dans les jours à venir de vérifier chez la dernière personne qui m'a dit ne pas pouvoir dézipper. Je vais voir...

En tout cas, rien de stupide dans ma commande.

Merci

Avatar de l’utilisateur
Thomas
Administrateur
Messages : 214
Inscription : 08 janvier 2017, 07:14

Re: Chiffrer un fichier compatible windows

Message par Thomas » 26 juin 2018, 08:00

Salut,

La norme est d'être en UTF-8, tu devrais peut-être y passer, non ?
LANG=fr_FR.UTF-8 (ou en_US.UTF-8 si tu préfères)
Thomas Bourdon

Didier Spaier
Messages : 69
Inscription : 29 janvier 2017, 21:07

Re: Chiffrer un fichier compatible windows

Message par Didier Spaier » 26 juin 2018, 14:31

Je confirme ce qu'à dit Thomas.

Selon Microsoft, cf. https://msdn.microsoft.com/en-us/librar ... s.85).aspx
Unicode-enabled functions are described in Conventions for Function Prototypes. These functions use UTF-16 (wide character) encoding, which is the most common encoding of Unicode and the one used for native Unicode encoding on Windows operating systems.
...
For compatibility with 8-bit and 7-bit environments, Unicode can also be encoded as UTF-8 and UTF-7, respectively. While Unicode-enabled functions in Windows use UTF-16, it is also possible to work with data encoded in UTF-8 or UTF-7, which are supported in Windows as multibyte character set code pages.
Il ne devrait donc pas y avoir de problème de conversion.

J'ajoute que contrairement à ce qu'ils écrivent UTF-16 n'est pas "l'encodage Unicode le plus communément utilisé", c'est bien UTF-8.

En outre l'utilisation de UTF-16 conduit pratiquement doubler la taille des fichiers textes les plus courants (en langues ouest européennes).

Démonstration:

Code : Tout sélectionner

didier[~]$ LANG=C echo "ceci est un texte"|iconv -t utf-8 > text.utf8
didier[~]$ LANG=C echo "ceci est un texte"|iconv -t utf-16 > text.utf16
didier[~]$ ls -l text*
-rw-r--r-- 1 didier users 38 juin  26 14:16 text.utf16
-rw-r--r-- 1 didier users 18 juin  26 14:16 text.utf8
didier[~]$ 
Pour info, les 38 (et non 36) octets de l'encodage en UTF-6 sont dus à l'ajout d'une "marque de l'ordre des octets) ou BOM, inutile dans le cas de UTF-8.

Seb
Messages : 78
Inscription : 22 février 2017, 19:07

Re: Chiffrer un fichier compatible windows

Message par Seb » 26 juin 2018, 19:15

Je doute fortement que tu sois en UTF-16, ecforum. Si c'était le cas tu ne pourrais même pas lire les fichiers de configuration dans un terminal. Comme le montre Didier, un caractère utf-16 fait minimum deux octets, aussi l'ASCII où tout est codé sur un octet n'a-t-il aucun sens. Si tu veux connaître ta locale, essaie:

Code : Tout sélectionner

$ locale
LANG=fr_FR.utf8
LC_CTYPE="fr_FR.utf8"
LC_NUMERIC="fr_FR.utf8"
LC_TIME="fr_FR.utf8"
LC_COLLATE=C
LC_MONETARY="fr_FR.utf8"
LC_MESSAGES="fr_FR.utf8"
LC_PAPER="fr_FR.utf8"
LC_NAME="fr_FR.utf8"
LC_ADDRESS="fr_FR.utf8"
LC_TELEPHONE="fr_FR.utf8"
LC_MEASUREMENT="fr_FR.utf8"
LC_IDENTIFICATION="fr_FR.utf8"
LC_ALL=
Comme tu le vois, la commande te donne toutes les variables d'environnement liées à la localisation (cf. man setlocale). Pour avoir les locales françaises disponibles:

Code : Tout sélectionner

locale -a | grep fr_
fr_BE
fr_BE.utf8
fr_BE@euro
fr_CA
fr_CA.utf8
fr_CH
fr_CH.utf8
fr_FR
fr_FR.utf8
fr_FR@euro
fr_LU
fr_LU.utf8
fr_LU@euro

Marc56
Messages : 2
Inscription : 25 juin 2018, 09:38

Re: Chiffrer un fichier compatible windows

Message par Marc56 » 27 juin 2018, 11:02

Il arrive parfois que l'on mette (ou ajoute) exprès un BOM sur des fichiers UTF-8, notamment si un doit partager un fichier avec un éditeur sous Windows et que celui-ci, en absence de BOM, ouvre en ascii et affiche donc n'importe quoi au premier caractère > 127

Windows "travaille" en interne en Unicode, mais stock la plupart des fichiers en UTF-8. Grace à cela, les fichiers texte ne voient pas leur taille systématiquement doubler. Seuls les caractères dont le code ascii est supérieur à 127 se voient codés sur 2 à 4 octets, et tout ce qui est < 127 reste lisible même sur les plus vieux outils.

Le BOM permet alors à l’éditeur de basculer directement l'affichage dès l'ouverture sans devoir balayer tout le fichier à la recherche d'un éventuel indicateur d'un caractère UTF-8

En tout cas merci à cette belle invention qu'est l'UTF-8, on n'a plus à s’énerver pour se connecter via putty entre codes console, terminal, transtyage etc et grande facilité aussi pour faire de Linux un serveur Windows avec Samba et ne plus devoir faire des pirouettes pour les noms de fichiers Windows avec des accents.

Cela dit, pour en revenir à la question initiale, cela ne devrait avoir aucune influence si le mot de passe donné dans l'archive a été fait avec des caractères entre 32 et 127

;)

Seb
Messages : 78
Inscription : 22 février 2017, 19:07

Re: Chiffrer un fichier compatible windows

Message par Seb » 28 juin 2018, 15:40

Le BOM sert aussi sous firefox. Je ne sais pas pourquoi, mais je n'ai plus la détection auto des encodages occidentaux dans les dernières versions. :?

Pour les échanges de fichiers textes avec MS, il y avait aussi les problèmes de fin de ligne : \r\n sous Windows, et \n sous Linux/Unix, qui amenait le contenu des fichiers Linux a être affichés sur une seule longue ligne. Je ne sais pas si c'est toujours d'actualité.

ecforum
Messages : 32
Inscription : 18 août 2017, 10:04

Re: Chiffrer un fichier compatible windows

Message par ecforum » 11 juillet 2018, 15:39

Bonjour,

Désolé pour le délai (semaine chargée, puis déplacement vers mes vacances...).
J'avais lu vos réponses . Pour le problème de mot de passe, en l'occurence, c'était une erreur de saisie de mon correspondant...
Sur mon desktop, vous avez raison, je suis en utf-8.
En fait c'est la commande donnée par Mar56 "7z --help" qui m'a retourné "locale=en_US,Utf16=on".
Mais de mémoire, "locale" ne retournait que du utf8.
Sur mon portable c'est encore différent... locale ne retourne que du en_us sans aucun utf (14.2 par défaut).

Bon, il faudra que je me documente sur le sujet (pas passionnant...) pour éviter d'avoir des doutes lors d'échange avec windows.

Merci pour vos réponses.

Répondre