Je résolvais un défi où j'ai trouvé un fichier de données sans extension de fichier. La filecommande montre qu'il s'agit d'un data file (application/octet-stream). La hdcommande affiche GNP. dans la dernière ligne. Donc, si j'inverse ce fichier, j'obtiendrai le fichier au format .PNG , j'ai cherché partout mais je n'ai pas trouvé de solution expliquant comment inverser le contenu d'un fichier binaire.
Réponses:
Avec xxd(de vim) et tac(de GNU coreutils, également tail -rsur certains systèmes):
< file.gnp xxd -p -c1 | tac | xxd -p -r > file.png
Dans zsh(le seul shell capable de traiter en interne les données binaires (sauf si vous voulez considérer l'approche de codage base64 de ksh93 )):
zmodload zsh/mapfile
(LC_ALL=C; printf %s ${(s::Oa)mapfile[file.gnp]} > file.png)
LC_ALL=C: les caractères sont des octets$mapfile[file.gnp]: contenu du file.gnpfichiers::: divise la chaîne en ses constituants d'octetOa: inverser Ole arder sur l' indice de rray ce tableauzshn'est pas le seul shell capable de gérer des données binaires.
Voici une façon d'inverser un fichier binaire en utilisant ksh93. J'ai laissé le code "lâche" pour le rendre plus facile à comprendre.
#!/bin/ksh93
typeset -b byte
redirect 3< image.gpj || exit 1
eof=$(3<#((EOF)))
read -r -u 3 -N 1 byte
printf "%B" byte > image.jpg
3<#((CUR - 1))
while (( $(3<#) > 0 ))
do
read -r -u 3 -N 1 byte
printf "%B" byte >> image.jpg
3<#((CUR - 2))
done
read -r -u 3 -N 1 byte
printf "%B" byte >> image.jpg
redirect 3<&- || echo 'cannot close FD 3'
exit 0
readci-dessus ne devrait rien lire car il se fait à la fin du fichier.
straceet ksh93semble se comporter très bizarrement, où il cherche partout dans le fichier et lit de grandes quantités à l'époque. Peut-être une variante de github.com/att/ast/issues/15
stracele script pour voir ce que je veux dire. ksh93lit les fichiers des milliers de fois. Par exemple, avant de lire le premier octet, il recherche 64 Ko à la fin du fichier, lit 64 Ko, puis recherche avant le dernier octet et lit 1 octet et fait quelque chose de similaire pour chaque octet. Notez que ce que vous pouvez faire avec ces chaînes encodées en base64 est limité, donc si vous lisez plus d'un octet à la fois, il sera plus difficile d'extraire les octets individuels de cela.
Avec perl:
perl -0777pe '$_=reverse $_' [input_file]
Test de performance:
dd if=/dev/urandom of=/tmp/a bs=1M count=1
LC_ALL=C tac -rs $'.\\|\n' /tmp/a > /tmp/r
time perl -0777pe '$_=reverse $_' /tmp/a | diff -q - /tmp/r
time xxd -p -c1 /tmp/a | tac | xxd -p -r | diff -q - /tmp/r
time perl -0777 -F -ape '$_=reverse@F' /tmp/a | diff -q - /tmp/r
time LC_ALL=C tac -rs $'.\\|\n' /tmp/a | diff -q - /tmp/r
Résultat:
perl -0777 -Fla plus lente.xxdest la plus lente.Remarque: les délais diffdoivent être les mêmes pour toutes les solutions, car la sortie doit être la même.
perl. Je n'avais pas réalisé à l'époque que reverseje pouvais aussi inverser les chaînes, donc le fractionnement n'avait pas beaucoup de sens et votre version est bien meilleure.
J'ai essayé ce qui suit:
tac -rs '.' input.gnp > output.png
L'idée est de forcer 'tac' en utilisant n'importe quel caractère comme séparateur. J'ai essayé cela sur un fichier binaire et cela semblait fonctionner mais toute confirmation serait appréciée.
Le principal avantage est qu'il ne charge pas le fichier en mémoire.
tac8.28) lorsque l'entrée contient des caractères de nouvelle ligne. printf '1\n2' | tac -rs . | od -vAn -tcsorties \n 2 1au lieu de 2 \n 1. Vous auriez également besoin LC_ALL=Cou .pourriez faire correspondre des caractères multi-octets.
LC_ALL=C tac -rs $'.\\|\n'semble fonctionner cependant.