Qu'est-ce qui fait que grep considère un fichier comme étant binaire?

J'ai quelques dumps de base de données d'un système Windows sur ma boîte. Ce sont des fichiers texte. J'utilise cygwin pour les remercier. Ceux-ci semblent être des fichiers de texte brut; Je les ouvre avec des éditeurs de texte tels que le bloc-notes et le wordpad. Ils ont l'air lisibles. Cependant, quand je lance grep sur eux, il dira binary file foo.txt matches.

J'ai remarqué que les fichiers contiennent des NULcaractères ascii , qui, à mon avis, sont des artefacts du dump de la base de données.

Alors, qu'est-ce qui fait que grep considère ces fichiers comme étant binaires? Le NULpersonnage? Y at-il un drapeau sur le système de fichiers? Que dois-je changer pour que grep me montre les correspondances de lignes?

S'il y a un NULcaractère n'importe où dans le fichier, grep le considérera comme un fichier binaire.

Il pourrait y avoir une solution de rechange comme celle-ci cat file | tr -d '\000' | yourgreppour éliminer tous les éléments null en premier, puis pour effectuer une recherche dans le fichier.

grep -a a travaillé pour moi:

$ grep --help
[...]
 -a, --text                equivalent to --binary-files=text

Vous pouvez utiliser l' stringsutilitaire pour extraire le contenu du texte de tout fichier, puis l'envoie à grep, comme ceci: strings file | grep pattern.

GNU grep 2.24 RTFS

Conclusion: 2 et 2 cas seulement:

• NUL, par exemple printf 'a\0' | grep 'a'

• erreur de codage selon C99 mbrlen(), par exemple:

  export LC_CTYPE='en_US.UTF-8'
  printf 'a\x80' | grep 'a'
  

  car \x80ne peut pas être le premier octet d'un point Unicode UTF-8 : UTF-8 - Description | en.wikipedia.org

De plus, comme l'a mentionné Stéphane Chazelas, qu'est-ce qui fait que grep considère un fichier comme étant binaire? | Unix et Linux Stack Exchange , ces vérifications ne sont effectuées que jusqu’à la première lecture de tampon de longueur TODO.

Seulement jusqu'à la première lecture du tampon

Ainsi, si une erreur NUL ou une erreur d'encodage se produit au milieu d'un fichier très volumineux, il se peut qu'il s'agisse d'une erreur.

J'imagine que c'est pour des raisons de performance.

Ex: ceci imprime la ligne:

printf '%10000000s\n\x80a' | grep 'a'

mais cela ne veut pas:

printf '%10s\n\x80a' | grep 'a'

La taille réelle de la mémoire tampon dépend de la façon dont le fichier est lu. Par exemple comparer:

export LC_CTYPE='en_US.UTF-8'
(printf '\n\x80a') | grep 'a'
(printf '\n'; sleep 1; printf '\x80a') | grep 'a'

Avec la sleep, la première ligne est transmise à grep même si elle ne dure qu'un octet, car le processus passe en veille, et la deuxième lecture ne vérifie pas si le fichier est binaire.

RTFS

git clone git://git.savannah.gnu.org/grep.git 
cd grep
git checkout v2.24

Recherchez où le message d'erreur stderr est codé:

git grep 'Binary file'

Nous amène à /src/grep.c:

if (!out_quiet && (encoding_error_output
                    || (0 <= nlines_first_null && nlines_first_null < nlines)))
    {
    printf (_("Binary file %s matches\n"), filename);

Si ces variables étaient bien nommées, nous en sommes essentiellement à la conclusion.

encoding_error_output

La recherche rapide pour encoding_error_outputindique que le seul chemin de code pouvant le modifier passe par buf_has_encoding_errors:

clen = mbrlen (p, buf + size - p, &mbs);
if ((size_t) -2 <= clen)
  return true;

alors juste man mbrlen.

nlines_first_null et nlines

Initialisé comme:

intmax_t nlines_first_null = -1;
nlines = 0;

alors quand un nul est trouvé 0 <= nlines_first_nulldevient vrai.

TODO quand peut-il nlines_first_null < nlinesêtre faux? Je suis paresseux.

POSIX

Ne définit pas les options binaires grep - recherche dans un fichier un motif | pubs.opengroup.org , et GNU grep ne le documente pas, RTFS est donc le seul moyen.

Un de mes fichiers texte était soudainement considéré comme binaire par grep:

$ file foo.txt
foo.txt: ISO-8859 text

La solution a été de le convertir en utilisant iconv:

iconv -t UTF-8 -f ISO-8859-1 foo.txt > foo_new.txt

Le fichier /etc/magicou /usr/share/misc/magiccontient une liste de séquences que la commande fileutilise pour déterminer le type de fichier.

Notez que le binaire peut simplement être une solution de secours. Parfois, les fichiers avec un codage étrange sont également considérés comme binaires.

grepsur Linux a quelques options pour gérer les fichiers binaires comme --binary-filesou-U / --binary

Un de mes étudiants a eu ce problème. Il y a un bug grepdans Cygwin. Si le fichier contient des caractères non-ascii, grepet egrepvoir comme binaire.

En réalité, en répondant à la question "Qu'est-ce qui fait que grep considère un fichier comme étant binaire?", Vous pouvez utiliser iconv:

$ iconv < myfile.java
iconv: (stdin):267:70: cannot convert

Dans mon cas, il y avait des caractères espagnols qui apparaissaient correctement dans les éditeurs de texte mais grep les considérait comme binaires; iconvla sortie m'a pointé vers les numéros de ligne et de colonne de ces caractères

Dans le cas de NULcaractères, iconvles considérera comme normaux et n'imprimera pas ce type de sortie, donc cette méthode ne convient pas

J'ai eu le même problème. J'avais l'habitude vi -b [filename]de voir les caractères ajoutés. J'ai trouvé les caractères de contrôle ^@et ^M. Puis dans vi tapez :1,$s/^@//gpour supprimer les ^@caractères. Répétez cette commande pour ^M.

Avertissement: pour obtenir les caractères de contrôle "bleus", appuyez sur Ctrl+ vpuis Ctrl+ Mou Ctrl+ @. Puis enregistrez et quittez vi.