Apache Commons IO имеет удобный удобный метод IOUtils.toString () для чтения InputStream
строки в строку.
Поскольку я пытаюсь перейти от Apache Commons к Guava : есть ли эквивалент в Guava? Я просмотрел все классы в com.google.common.io
пакете и не нашел ничего более простого.
Изменить: я понимаю и ценю проблемы с кодировками. Так уж случилось, что я знаю, что все мои источники находятся в ASCII (да, ASCII, а не ANSI и т. Д.), Поэтому в этом случае кодировка для меня не проблема.
java
io
inputstream
guava
Шон Патрик Флойд
источник
источник
Charsets.US_ASCII
), вместо того, чтобы позволять вам говорить «а, какую кодировку я думаю?» что многим кажется счастливым делать. Тем более, что Java не использует значение по умолчанию, которое имеет смысл, например UTF-8.Ответы:
В своем комментарии к ответу Калума вы заявили, что собираетесь использовать
Этот код проблематичен, поскольку в перегрузке
CharStreams.toString(Readable)
указано:Это означает, что ваш
InputStreamReader
и, соответственно,InputStream
возвращаемыйsupplier.get()
, не будут закрыты после завершения этого кода.Если, с другой стороны, вы воспользуетесь тем фактом, что у вас уже есть
InputSupplier<InputStream>
и используется перегрузкаCharStreams.toString(InputSupplier<R extends Readable & Closeable>
),toString
метод будет обрабатывать как создание, так и закрытиеReader
для вас.Это именно то, что предложил Джон Скит, за исключением того, что на самом деле нет никакой перегрузки,
CharStreams.newReaderSupplier
которая принимает вInputStream
качестве входных данных ... вы должны дать емуInputSupplier
:Смысл в
InputSupplier
том, чтобы упростить вашу жизнь, позволив Guava обрабатывать части, требующие уродливогоtry-finally
блока, чтобы гарантировать правильное закрытие ресурсов.Изменить: Лично я нахожу следующее (именно так я бы написал это, просто нарушил шаги в приведенном выше коде)
быть гораздо менее подробным, чем это:
Это более или менее то, что вам нужно было бы написать, чтобы справиться с этим самостоятельно.
Изменить: февраль 2014 г.
InputSupplier
иOutputSupplier
методы, которые их используют, устарели в Guava 16.0. Их замены являютсяByteSource
,CharSource
,ByteSink
иCharSink
. Учитывая aByteSource
, теперь вы можете получить его содержимоеString
следующим образом:источник
InputStream
, и вы хотите получить его в качествеString
,CharStreams.toString(new InputStreamReader(inputStream, charset))
это лучший вариант .ByteSource
иCharSource
предназначены специально для случаев, когда у вас есть что-то, что может выступать в качестве источникаInputStream
s илиReader
s.Если у вас есть,
Readable
вы можете использоватьCharStreams.toString(Readable)
. Итак, вы, вероятно, можете сделать следующее:Заставляет вас указать набор символов, что, я думаю, вам все равно следует делать.
источник
InputSupplier<InputStream>
я настоятельно рекомендую использоватьCharStreams.newReaderSupplier(supplier, Charsets.UTF_8)
вместоnew InputStreamReader
. Причина заключается в том, что , когда , учитываяInputStreamReader
,toString
будет не близко , чтоReader
(и , следовательно , не основной поток!). ИспользуяInputSupplier
дляReader
,toString
метод выполнит закрытиеReader
за вас.ОБНОВЛЕНИЕ : оглядываясь назад, мне не нравится мое старое решение. Кроме того, сейчас 2013 год, и теперь для Java7 доступны лучшие альтернативы. Итак, вот что я использую сейчас:
или если с InputSupplier
источник
Почти. Вы можете использовать что-то вроде этого:
Лично я не думаю, что
IOUtils.toString(InputStream)
это "хорошо" - потому что он всегда использует кодировку платформы по умолчанию, что почти никогда не бывает тем, что вам нужно. Есть перегрузка, которая принимает имя кодировки, но использование имен - не лучшая идея, ИМО. Вот почему мне нравитсяCharsets.*
.РЕДАКТИРОВАТЬ: Не то, чтобы вышеупомянутое нуждается
InputSupplier<InputStream>
вstreamSupplier
. Если у вас уже есть поток, вы можете легко реализовать его:источник
Charsets.UTF_8.name()
- более устойчивый к опечаткам.Другой вариант - прочитать байты из Stream и создать из них String:
Это не «чистая» гуава, но она немного короче.
источник
ByteStreams.toByteArray()
не закрывает поток, согласно Javadoc.Основываясь на принятом ответе, вот служебный метод, который имитирует поведение
IOUtils.toString()
(а также перегруженную версию с кодировкой). Эта версия должна быть безопасной, правда?источник
Существует гораздо более короткое решение для автоматического закрытия в случае, когда входной поток поступает из ресурса пути к классам:
Использует ресурсы Guava , вдохновленные IOExplained .
источник
РЕДАКТИРОВАТЬ (2015): Okio - лучшая абстракция и инструменты для ввода-вывода на Java / Android, о которых я знаю. Я использую это все время.
FWIW вот что я использую.
Если у меня уже есть поток на руках, то:
Если я создаю поток:
В качестве конкретного примера я могу прочитать ресурс текстового файла Android следующим образом:
источник
В качестве конкретного примера, вот как я могу прочитать ресурс текстового файла Android:
источник