Question

Le Documentation Sun pour DataInput.skipBytes déclare qu'il "tente de sauter n octets de données du flux d'entrée, en supprimant les octets ignorés.Cependant, il peut sauter un nombre plus petit d'octets, éventuellement zéro.Cela peut résulter d'un certain nombre de conditions ;atteindre la fin du fichier avant que n octets n'aient été ignorés n'est qu'une possibilité."

  1. À part atteindre la fin du fichier, pourquoi pourrait-il skipBytes() pas sauter le bon nombre d'octets ?(Le DataInputStream J'utilise soit j'emballerai un FileInputStream ou un PipedInputStream.)

  2. Si je veux vraiment sauter n octets et lancer un EOFException si cela me fait aller à la fin du fichier, dois-je utiliser readFully() et ignorer le tableau d'octets résultant ?Ou existe-t-il une meilleure façon ?

Était-ce utile?

La solution

1) Il se peut qu'il n'y ait pas beaucoup de données disponibles à lire (l'autre extrémité du canal n'a peut-être pas encore envoyé autant de données) et la classe d'implémentation peut être non bloquante (c'est-à-direil renverra simplement ce qu'il peut, plutôt que d'attendre suffisamment de données pour répondre à la demande).

Cependant, je ne sais pas si des implémentations se comportent réellement de cette manière, mais l'interface est conçue pour le permettre.

Une autre option consiste simplement à fermer le fichier à mi-chemin de la lecture.

2) Soit readFully() (qui attendra toujours suffisamment d’entrées sinon échouera) ou appellera skipBytes() dans une boucle.Je pense que la première solution est probablement meilleure, à moins que la gamme ne soit vraiment vaste.

Autres conseils

Je suis tombé sur ce problème aujourd'hui.Il s'agissait de lire une connexion réseau sur une machine virtuelle, j'imagine donc qu'il pourrait y avoir plusieurs raisons à cela.Je l'ai résolu en forçant simplement le flux d'entrée à sauter des octets jusqu'à ce qu'il ait sauté le nombre d'octets que je souhaitais :

int byteOffsetX = someNumber; //n bytes to skip
int nSkipped = 0;

nSkipped = in.skipBytes(byteOffsetX);
while (nSkipped < byteOffsetX) {
    nSkipped = nSkipped + in.skipBytes(byteOffsetX - nSkipped);
}

Josh Bloch l'a annoncé récemment.Cela est cohérent dans la mesure où il n'est pas garanti qu'InputStream.read lise autant d'octets qu'il le pourrait.Cependant, c’est totalement inutile en tant que méthode API.InputStream devrait probablement aussi avoir readFully.

Il s'avère que readFully() ajoute plus de performances que ce que j'étais prêt à supporter.

En fin de compte, j'ai fait un compromis :J'appelle skipBytes() une fois, et si cela renvoie moins que le bon nombre d'octets, j'appelle readFully() pour les octets restants.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top