Réponses:
Vous pouvez utiliser
openssl dgst -sha256 <file>Testé sur LibreSSL 2.6.4 sur macOS 10.14 (Mojave).
Avant Mojave, vous pouvez utiliser openssl sha -sha256 <file>ou openssl sha256 <file>.
Pour vérifier les options de ligne de commande pour la commande sha OpenSSL: openssl sha -help.
OS X est livré avec une commande shasum .
> which shasum
/usr/bin/shasum
Vous pouvez utiliser:
> shasum -a 256 <file>Plus de détails:
> shasum --help
Usage: shasum [OPTION]... [FILE]...
Print or check SHA checksums.
With no FILE, or when FILE is -, read standard input.
-a, --algorithm 1 (default), 224, 256, 384, 512, 512224, 512256
-b, --binary read in binary mode
-c, --check read SHA sums from the FILEs and check them
-t, --text read in text mode (default)
-p, --portable read in portable mode
produces same digest on Windows/Unix/Mac
-0, --01 read in BITS mode
ASCII '0' interpreted as 0-bit,
ASCII '1' interpreted as 1-bit,
all other characters ignored
The following two options are useful only when verifying checksums:
-s, --status don't output anything, status code shows success
-w, --warn warn about improperly formatted checksum lines
-h, --help display this help and exit
-v, --version output version information and exit
When verifying SHA-512/224 or SHA-512/256 checksums, indicate the
algorithm explicitly using the -a option, e.g.
shasum -a 512224 -c checksumfile
The sums are computed as described in FIPS-180-4. When checking, the
input should be a former output of this program. The default mode is to
print a line with checksum, a character indicating type (`*' for binary,
` ' for text, `?' for portable, `^' for BITS), and name for each FILE.
Report shasum bugs to mshelor@cpan.org
which shashumne
/usr/binavec des options. Je devrai vérifier que c'est le cas plus tard aujourd'hui. Mettra à jour la réponse si cela provenait effectivement de l'installation XCL.
shasumrenvoie un hachage différent de openssl sha -sha256 <file>(ce dernier étant le hachage correct). Une idée pourquoi?
shasumest un script Perl, utilisé Digest::SHApour calculer la valeur de hachage. Pour le même fichier, je reçois exactement le même SHA avec shasumou opensslpour un SHA-256calcul de hachage. Voir: gist.github.com/ianchesal/82a064b8971eb5e717ce84f3ded6dbfd
Pour clarifier la réponse utile de @ John - qui vous permet de comparer un hachage donné avec son fichier en une seule commande:
Entrez shasum -a 256 -c <<<,
suivi d'un espace optionnel,
suivi d'un simple tick ( '),
suivi du hachage à comparer,
suivi d'un espace,
suivi d'un caractère mode, basé sur la façon dont le hachage initial a été généré:
rien , si le hachage a été créé avec -tou aucune option (mode texte, qui est la valeur par défaut)
astérisque ( *), si le hachage a été créé avec -b(mode binaire)
point d'interrogation ( ?), si le hachage a été créé avec -p(mode portable)
caret ( ^), si le hachage a été créé avec -0(mode bits)
suivi du chemin d'accès au fichier,
suivi d'un tick simple de fermeture ( ').
Comme dans la répartition suivante, avec des délimitations entre parenthèses autour des parties de hachage et de chemin de fichier, et des crochets autour de la partie facultative "caractère de mode". ( N'incluez pas les parenthèses ni les crochets dans la vie réelle, ils sont juste là pour rendre les parties faciles à voir! )
shasum -a 256 -c <<< '(hashToCompare) [mode character](filepath)'En panne :
La commande réelle shasum estshasum -a 256 -c
-a 256dit shasumd'utiliser sha256 .
-cdit shasumde "vérifier" l'entrée fournie.
Le <<<est un jeu de caractères spéciaux Unix / Linux, appelé opérateur de "redirection". C'est pour introduire quelque chose dans une commande antérieure. En l'utilisant, nous disons que nous allons fournir une chaîne d'informations que la shasumcommande utilisera en tant qu'entrée.
La chaîne d'informations d'entrée doit comporter des ticks simples d'ouverture et de fermeture, tels que 'some string here', ou dans ce cas, le hachage, le caractère de mode et le chemin de fichier à vérifier.
La partie de hachage à l'intérieur de la chaîne n'a besoin de rien de spécial, mais elle doit être suivie d'un espace.
La partie de caractère de mode peut être rien, un astérisque ( *), un point d'interrogation ( ?) ou un caret ( ^). Cela indique shasumle mode avec lequel le hachage a été généré. (Remarque: aucun caractère, représentant le mode texte, est shasumla valeur par défaut.)
La filepath partie, est le chemin réel du fichier à vérifier.
Voici donc un exemple concret qui compare un fichier de téléchargement MAMP particulier à sa prétendue valeur SHA-256 . Le *caractère de mode était requis pour que cette vérification fonctionne:
shasum -a 256 -c <<< 'f05ede012b8a5d0e7c9cf17fee0fa1eb5cd8131f3c703ed14ea347f25be11a28 *MAMP_MAMP_PRO_5.2.pkg'Remarque: le résultat de cette commande (pour mon exemple de fichier) est soit -
D'ACCORD:
MAMP_MAMP_PRO_5.2.pkg: OK
ou
ÉCHOUÉ:
MAMP_MAMP_PRO_5.2.pkg: FAILED
shasum: AVERTISSEMENT: 1 somme de contrôle calculée ne correspond pas
shasum -c <<< '7cb77378a0749f2a9b7e09ea62ffb13febf3759f *sample.txt'renvoie le message *sample.txt: FAILED open or read. Sans l'astérisque, sample.txt: OK. Je n'ai pas encore trouvé la base de l'utilisation de l'astérisque ailleurs. Pourriez-vous clarifier?
--binaryoption)? A partir de la page de manuel: "Lors de la vérification, l’entrée doit être une sortie précédente de ce programme. Le mode par défaut consiste à imprimer une ligne avec une somme de contrôle, un caractère indiquant le type ( *pour binaire,` pour texte, Upour UNIVERSAL, ^pour BITS, etc.). ?pour portable), et nom pour chaque fichier. " Ainsi, les caractères entre la somme de contrôle et le nom de fichier dépendent du mode défini lors de la création de la somme de contrôle?