Apache Commons IO a une méthode pratique IOUtils.toString () pour lire un InputStream
dans une chaîne.
Puisque j'essaye de m'éloigner d'Apache Commons et de Guava : y a-t-il un équivalent dans Guava? J'ai regardé toutes les classes du com.google.common.io
package et je n'ai rien trouvé d'aussi simple.
Edit: Je comprends et apprécie les problèmes avec les jeux de caractères. Il se trouve que je sais que toutes mes sources sont en ASCII (oui, ASCII, pas ANSI etc.), donc dans ce cas, l'encodage n'est pas un problème pour moi.
java
io
inputstream
guava
Sean Patrick Floyd
la source
la source
Charsets.US_ASCII
) plutôt que de vous laisser dire "eh, quel jeu de caractères je suppose?" ce que tout le monde semble heureux de faire. D'autant plus que Java n'utilise pas de valeur par défaut logique, comme UTF-8.Réponses:
Vous avez déclaré dans votre commentaire sur la réponse de Calum que vous alliez utiliser
Ce code est problématique car les
CharStreams.toString(Readable)
états de surcharge :Cela signifie que votre
InputStreamReader
, et par extension celuiInputStream
renvoyé parsupplier.get()
, ne sera pas fermé une fois ce code terminé.Si, par contre, vous tirez parti du fait que vous semblez déjà avoir
InputSupplier<InputStream>
et utilisé la surchargeCharStreams.toString(InputSupplier<R extends Readable & Closeable>
), latoString
méthode gérera à la fois la création et la fermeture de laReader
.C'est exactement ce que Jon Skeet a suggéré, sauf qu'il n'y a en fait aucune surcharge de ce
CharStreams.newReaderSupplier
qui prend uneInputStream
entrée ... vous devez lui donner unInputSupplier
:Le but
InputSupplier
est de vous faciliter la vie en permettant à Guava de gérer les pièces qui nécessitent untry-finally
bloc laid pour s'assurer que les ressources sont correctement fermées.Edit: Personnellement, je trouve ce qui suit (c'est ainsi que je l'écrirais, je décomposais simplement les étapes du code ci-dessus)
pour être beaucoup moins verbeux que cela:
C'est plus ou moins ce que vous auriez à écrire pour gérer cela correctement vous-même.
Edit: février 2014
InputSupplier
etOutputSupplier
les méthodes qui les utilisent sont devenues obsolètes dans Guava 16.0. Leurs remplaçants sontByteSource
,CharSource
,ByteSink
etCharSink
. Étant donné aByteSource
, vous pouvez maintenant obtenir son contenuString
comme ceci:la source
InputStream
, et que vous voulez l'obtenir en tant queString
,CharStreams.toString(new InputStreamReader(inputStream, charset))
c'est la voie à suivre.ByteSource
etCharSource
sont spécifiquement pour les cas où vous avez quelque chose qui peut agir comme une source deInputStream
s ouReader
s.Si vous en avez un,
Readable
vous pouvez utiliserCharStreams.toString(Readable)
. Vous pouvez donc probablement faire ce qui suit:Vous oblige à spécifier un jeu de caractères, ce que je suppose que vous devriez faire de toute façon.
la source
InputSupplier<InputStream>
je vous recommande fortement d'utiliserCharStreams.newReaderSupplier(supplier, Charsets.UTF_8)
plutôt quenew InputStreamReader
. La raison en est que lorsque la donnéeInputStreamReader
,toString
sera pas près queReader
(et donc pas le flux sous - jacent!). En utilisant unInputSupplier
for theReader
, latoString
méthode gérera la fermeture duReader
pour vous.MISE À JOUR : Avec le recul, je n'aime pas mon ancienne solution. En outre, nous sommes maintenant en 2013 et il existe de meilleures alternatives disponibles maintenant pour Java7. Voici donc ce que j'utilise maintenant:
ou si avec InputSupplier
la source
Presque. Vous pouvez utiliser quelque chose comme ceci:
Personnellement, je ne pense pas que ce
IOUtils.toString(InputStream)
soit "sympa" - car il utilise toujours l'encodage par défaut de la plate-forme, ce qui n'est presque jamais ce que vous voulez. Il y a une surcharge qui prend le nom de l'encodage, mais utiliser des noms n'est pas une bonne idée IMO. C'est pourquoi j'aimeCharsets.*
.EDIT: Non pas que ce qui précède a besoin d'un
InputSupplier<InputStream>
comme lestreamSupplier
. Si vous avez déjà le flux, vous pouvez l'implémenter assez facilement:la source
Charsets.UTF_8.name()
- plus résistante aux fautes de frappe.Une autre option consiste à lire les octets de Stream et à créer une chaîne à partir d'eux:
Ce n'est pas de la goyave «pure», mais c'est un peu plus court.
la source
ByteStreams.toByteArray()
ne ferme pas le flux, selon le Javadoc.Sur la base de la réponse acceptée, voici une méthode utilitaire qui se moque du comportement de
IOUtils.toString()
(et une version surchargée avec un jeu de caractères). Cette version devrait être sûre, non?la source
Il existe une solution de fermeture automatique beaucoup plus courte dans le cas où le flux d'entrée provient de la ressource classpath:
Utilise des ressources de goyave , inspirées par IOExplained .
la source
EDIT (2015): Okio est la meilleure abstraction et les meilleurs outils d'E / S en Java / Android que je connaisse. Je l'utilise tout le temps.
FWIW voici ce que j'utilise.
Si j'ai déjà un flux en main, alors:
Si je crée un flux:
À titre d'exemple concret, je peux lire un fichier texte Android comme celui-ci:
la source
Pour un exemple concret, voici comment lire un fichier texte Android:
la source