Que 0 (nombre d'octets lus) renvoyé par InputStream.read signifie? Comment gérer cette situation?Qu'est-ce que 0 renvoyé par InputStream.read() signifie? Comment gérer cela?
Mise à jour: Je veux dire read(byte[] b) ou read(byte[] b, int off, int len) méthodes qui retournent le nombre d'octets lus.
La seule situation dans laquelle un InputStream peut revenir 0 d'un appel à read(byte[]) est lorsque le byte[] passé en a une longueur de 0:
byte[] buf = new byte[0];
int read = in.read(buf); // read will contain 0
Comme spécifié par cette partie du JavaDoc:
Si la longueur de b est égal à zéro, aucun octets sont lus et 0 est renvoyé
Ma conjecture: vous avez utilisé available() pour voir la taille du tampon et il a retourné 0. Notez qu'il s'agit d'une mauvaise utilisation de available(). JavaDoc indique explicitement que:
Il n'est jamais correct d'utiliser la valeur de retour de cette méthode pour allouer un tampon destiné à contenir toutes les données dans ce flux.
Selon l'API Java Doc:
http://java.sun.com/j2se/1.4.2/docs/api/java/io/InputStream.html#read(byte[])
Il ne peut se produire si l'octet [] vous avez passé a zéro élément (nouvel octet [0]).
Dans d'autres situations, il doit retourner au moins un octet. Ou -1 si EOF atteint. Ou une exception.
Bien sûr: cela dépend de l'implémentation réelle de l'InputStream que vous utilisez !!! (il pourrait être un mauvais)
Jetez un oeil à l'implémentation de javax.sound.AudioInputStream # read (octet [] b, int off, int len) ... beurk. Ils ont complètement enfreint la sémantique java.io.InputStream standard et retournent une taille de lecture de 0 si vous demandez moins d'une trame entière de données.
Alors malheureusement; le conseil commun (et api spec) devrait éviter de devoir traiter le retour de zéro quand len> 0 mais même pour les classes fournies par JDK, vous ne pouvez pas vous fier à cela pour les InputStreams de types arbitraires.
Encore une fois, beurk.
InputStream de UrlConnection.getInputStream() semble également enfreint la sémantique java.io.InputStream standard et renvoie une taille de lecture de 0 lors de la gestion de fichiers volumineux. Quelqu'un peut-il confirmer cela? – okwap
^Oui, ce qui est confirmé, je suis venu à cette question lors de la recherche du même problème exact de UrlConnection.getInputStream lire renvoyant un zéro 0 – taimur
J'observé le même comportement (lecture 0 octets) quand je construis une fenêtre de sortie de la console de swing et fait un lecteur-fil pour stdout et stderr via le code suivant:
this.pi = new PipedInputStream();
po = new PipedOutputStream((PipedInputStream)pi);
System.setOut(new PrintStream(po, true));
Lorsque l'application swing « principale » sorties, et mon La fenêtre de la console est toujours ouverte. Je lis 0 depuis this.pi.read(). Les données lues ont été placées dans la fenêtre de la console, ce qui a entraîné une condition de concurrence. Ignorer simplement le résultat et ne pas mettre à jour la fenêtre de la console a résolu le problème.
Je suis d'accord: > Cette méthode est bloquée jusqu'à ce que les données d'entrée soient disponibles, la fin du fichier est détectée ou une exception est générée. > Si la longueur de b est zéro, aucun octet n'est lu et 0 est retourné; sinon, il y a une tentative de lecture d'au moins un octet. > Si aucun octet n'est disponible car le flux se trouve à la fin du fichier, la valeur -1 est renvoyée; sinon, au moins un octet est lu et stocké dans b. Merci! –