Je dois examiner un fichier texte de 82,7 Go ( !). Qu'est-ce qui peut l'ouvrir ?

Avec les éditeurs de texte sur disque, le fichier n'est pas entièrement chargé en mémoire - ce que vous voyez sur l'interface utilisateur est un aperçu du contenu que l'éditeur a chargé en mémoire. J'ai utilisé UltraEdit avec succès dans le passé pour analyser des fichiers journaux volumineux. Ses outils de recherche basés sur les expressions régulières et ses signets de localisation sont particulièrement utiles. Il charge le fichier rapidement, et vous pouvez faire des recherches basées sur des expressions régulières. L'url vous conduit à une page de téléchargement où vous pouvez télécharger une version d'essai de 30 jours. Il existe également d'autres éditeurs de texte sur disque.

Comme cela fait quelques années, j'ai installé UltraEdit et ouvert le plus gros fichier que j'avais. C'était un fichier binaire de 64 Go et il s'est ouvert instantanément. J'ai lancé une recherche pour un terme et cela a pris environ 90 secondes. J'ai mis en évidence la taille du fichier avec un rectangle rouge en bas à droite. Le Mac est un MBP 2018 avec 8 Go de RAM et fonctionne sous Mojave.

Tu ne le ferais pas.

Même un fan de Tolkien ne veut pas 82,7 Go de quoi que ce soit. Vous n'en voulez que certains morceaux, vous le saurez quand vous le verrez.

Et même envisager un outil qui analyse l'ensemble du fichier est une perte de temps, littéralement ; il va passer 15 minutes à lire le fichier en supposant 100MB/sec. C'est beaucoup plus lent si l'analyse est complexe.

Le terminal est votre ami

L'avantage de cette solution est que OS X est construit au-dessus d'Unix. C'est en grande partie pour cela qu'Apple a acheté NeXT et que Steve Jobs est revenu. Cela signifie que vous pouvez utiliser toute la suite d'outils Unix, qui sont extrêmement bien rodés et très bien supportés ici.

Il existe des dizaines de façons de le faire sans perl, mais comme perl est intégré à MacOS et qu'il est infiniment extensible, je préfère commencer par là (plutôt que de le faire dans un outil plus simple, de vouloir améliorer quelque peu la requête, de se heurter aux limites de cet outil et de devoir la refaire dans un autre outil). Donc quelque chose comme ceci dans un fichier appelé, disons "xx" :

 $len = -s "filename.log";            # variable becomes length of file
 open ($IN,  "<", "filename.log"); 
 seek ($IN, $len - 10_000_000, 0);    # perl allows _ in numbers for readability

 while (<$IN>) {         # <> reads a line.  Default variable is metavariable $_
   print;                # with no argument, default is metavariable $_
 }

Il ne lira pas tout le fichier, mais se contentera de le rechercher à l'emplacement spécifié (à 10 Mo de la fin), puis lira et imprimera tout ce qui se trouve à la fin. Il ne fera que l'imprimer à l'écran, donc pour l'envoyer dans le fichier, faites ceci lorsque vous l'appelez :

 perl xx > tailfile.txt

Vous avez maintenant un fichier tailfile.txt de 10 Mo que vous pouvez ouvrir avec autre chose.

Il y a des moyens plus simples de faire juste que mais supposez que vous réalisiez "Attendez, je veux faire plus. Je ne veux que des erreurs et des avertissements". Vous changez donc la commande print en

 print if /error/i or /warning/i;    # // matches text, defaults to $_ 

Cela aussi peut être accompli avec des outils plus simples si vous passez suffisamment de temps à fouiller dans la documentation. Mais ensuite, vous décidez que vous avez besoin de voir ces trois lignes après l'erreur. Comme ça... vous avez dépassé les outils plus simples, mais c'est trivial en Perl. Vous pouvez simplement continuer à shimmer Perl pour toujours. Il y a un langage de programmation complet là-dedans. Orienté objet et tout.

Un fichier de cette taille est probablement redondant à 99,999999 % (littéralement), la clé est donc de supprimer les lignes qui apparaissent des milliards de fois, avec un certain degré de similitude, et d'examiner ce qui reste.

Sous Linux, il y a un utilitaire appelé petit conçu pour analyser d'énormes fichiers journaux, qui fait cela. Un exemple d'utilisation est petit --hash /var/log/kern.log . L'utilitaire peut probablement être trouvé ou construit pour Mac.

Il traite chaque ligne du fichier pour supprimer les éléments qui rendent la ligne unique ; par exemple, il retire la date de chaque ligne et remplace toutes les chaînes de chiffres par un seul caractère #. Chaque ligne générique est ensuite hachée pour devenir une empreinte digitale permettant de détecter des lignes similaires.

Le résultat est que chaque ligne n'est affichée qu'une seule fois avec un compte d'occurrences, ce qui réduit considérablement la taille des données. Tout ce qui sort de l'ordinaire est susceptible d'apparaître clairement, et on peut alors le rechercher spécifiquement, en utilisant les utilitaires de certaines des autres réponses ici.

Je ne sais pas si cet utilitaire particulier est assez performant pour quelque chose de cette taille. Je parierais que oui, car il dispose d'options pour tracer des graphiques de l'ordre de mois ou d'années d'entrée, et n'aurait pas besoin de stocker grand-chose à part un petit nombre d'empreintes digitales. Dans le pire des cas, vous pourriez écrire le vôtre : pour chaque ligne d'entrée, la généraliser en une empreinte digitale, la hacher, et l'ajouter à une base de données de hash+empreinte digitale+compte, indexée par hash.

EDIT : petit semble utiliser plus de CPU et de mémoire que souhaité, j'ai donc écrit ma propre implémentation simple : https://github.com/curtmcd/hashlog . Il ne fait qu'un seul passage dans le fichier journal ; il traite à environ 6,5 sec/GB sur mon serveur Ubuntu personnel.

Définitivement Hex Fiend. Il ouvre les fichiers SANS utiliser la RAM. Il lit simplement sur le disque. Les performances sont absolument incroyables. J'ai déjà examiné des vidages de mot de passe de 500 Go avec lui.

https://ridiculousfish.com/hexfiend/