Java BufferedReader vers le haut d'un fichier texte?

Question

J'ai actuellement 2 BufferedReader initialisés sur le même fichier texte. Quand j'ai fini de lire le fichier texte avec le premier BufferedReader , j'utilise le second pour faire passer le fichier à nouveau par le haut. Plusieurs passages dans le même fichier sont nécessaires.

Je connais reset () , mais il doit être précédé de l'appel de mark () et mark () doit connaître le taille du fichier, quelque chose que je ne devrais pas avoir à me soucier.

Des idées? Paquets? Libs? Code?

Merci TJ

Answer 1

Quel est l'inconvénient de créer simplement un nouveau BufferedReader à lire en haut? Je m'attendrais à ce que le système d'exploitation mette le fichier en cache s'il est suffisamment petit.

Si les performances vous préoccupent, avez-vous prouvé que c'était un goulot d'étranglement? Je ferais simplement la chose la plus simple sans m'inquiéter jusqu'à ce que vous ayez une raison spécifique de le faire. Je veux dire, vous pouvez simplement lire le tout dans la mémoire et ensuite faire les deux passes sur le résultat, mais encore une fois, ce sera plus compliqué que de simplement lire à nouveau avec un nouveau lecteur.

Answer 2

Les lecteurs mis en mémoire tampon sont conçus pour lire un fichier séquentiellement. Ce que vous recherchez, c'est le java.io.RandomAccessFile.html" rel="noreferrer"> java.io.RandomAccessFile.html" rel="noreferrer"> java.io.RandomAccessFile , puis vous pouvez utiliser seek () pour vous amener où vous voulez dans le fichier.

Le lecteur à accès aléatoire est implémenté comme suit:

try{
     String fileName = "c:/myraffile.txt";
     File file = new File(fileName);
     RandomAccessFile raf = new RandomAccessFile(file, "rw");
     raf.readChar();
     raf.seek(0);
} catch (FileNotFoundException e) {
     // TODO Auto-generated catch block
     e.printStackTrace();
} catch (IOException e) {
     // TODO Auto-generated catch block
     e.printStackTrace();
}

Le "rw" est un caractère de mode qui est détaillé ici .

La raison pour laquelle les lecteurs à accès séquentiel sont configurés de cette manière est qu'ils peuvent mettre en oeuvre leurs tampons et que rien ne peut être changé sous leurs pieds. Par exemple, le lecteur de fichier attribué au lecteur en mémoire tampon ne doit être utilisé que par ce lecteur en mémoire tampon. Si un autre emplacement risquait de l’affecter, vous pourriez avoir une opération incohérente puisqu'un lecteur a avancé sa position dans le lecteur de fichiers alors que l’autre voulait qu’il reste identique, maintenant vous utilisez l’autre lecteur et il se trouve dans un emplacement indéterminé.

Answer 3

La meilleure façon de procéder consiste à modifier votre algorithme, de manière à ce que vous n'ayez PAS besoin de la deuxième passe. J’ai utilisé cette approche à plusieurs reprises, lorsque j’avais à traiter avec d’énormes fichiers (mais pas terribles, c’est-à-dire quelques Go) qui ne correspondaient pas à la mémoire disponible.

Cela peut être difficile, mais le gain de performances en vaut généralement la peine

Answer 4

À propos de la marque / réinitialisation:

La méthode mark de BufferedReader utilise un paramètre readAheadLimit qui limite la capacité de lecture après une marque avant que la réinitialisation ne devienne impossible. Réinitialiser ne signifie pas réellement une recherche de système de fichiers (0), elle cherche simplement à l'intérieur du tampon. Pour citer le Javadoc:

  

readAheadLimit - Limite le nombre de caractères pouvant être lus tout en préservant la marque. Après avoir lu autant de caractères, toute tentative de réinitialisation du flux peut échouer. Une valeur limite supérieure à la taille du tampon d'entrée entraîne l'attribution d'un nouveau tampon dont la taille n'est pas inférieure à la limite. Par conséquent, les grandes valeurs doivent être utilisées avec précaution.

Answer 5

"Toute l'entreprise à propos de mark () et reset () dans BufferedReader sent le mauvais dessin."

pourquoi ne pas étendre cette classe et lui demander de faire un mark () dans le constructeur () puis un chercheur (0) dans la méthode topOfFile ().

BR,
~ A