Java: потоковое содержимое Zipfile через HTTP

Question

У меня довольно много потоковых данных (> 100 МБ), которые для сжатия я хотел бы разместить в zip-файле на http-сервере.Таким образом, этот zip-файл содержит один файл.

Теперь для java-клиента возможна потоковая передача данных через http, даже если он упакован в zipfile?

Согласно википедии, ZIPне последовательно ...

http://en.wikipedia.org/wiki/ZIP_(file_format)#Structure

Если это все еще возможно, то как?

edit: about gzip: как я уже сказал, я использую пользовательскийJava-клиент (не веб-браузер) gzip доступен в реализации Java Java?

Answer 1

Вот фрагмент кода (который работает), который клиент может использовать для чтения из сжатого потока:

static void processZippedInputStream(InputStream in, String entryNameRegex)
throws IOException
{
    ZipInputStream zin = new ZipInputStream(in);
    ZipEntry ze;
    while ((ze = zin.getNextEntry()) != null)
    {
        if (ze.getName().matches(entryNameRegex))
        {
            // treat zin as a normal input stream - ie read() from it till "empty" etc
            break;
        }
        zin.closeEntry();
    }
    zin.close();
}

Основное отличие от обычного InputStream заключается в итерации записей.Например, вы можете знать, что вам нужна первая запись, поэтому вам не нужен параметр сопоставления имен и т. Д.

Answer 2

Java поддерживает формат gzip с GZipInputStream (распаковка) и GZipOutputStream (сжатие).И zip, и gzip используют один и тот же формат сжатия внутри, основное различие заключается в метаданных: у zip он есть в конце файла, gzip в начале (и gzip поддерживает только один вложенный файл).файл легко).

Для потоковой передачи одного большого файла лучше использовать gzip, даже больше, поскольку вам не нужен доступ к метаданным.

IЯ не уверен, что HTTPConnection отправляет Accept-Encoding: gzip, а затем обрабатывает раздувание контента автоматически, если сервер доставляет его с Content-Encoding: gzip, но вы, безусловно, можете сделать это вручную, если сервер просто отправляет файл .gz как таковой (т.е.с Content-Encoding: identity).

(Кстати, обязательно читайте из потока с не слишком маленькими буферами, поскольку каждый вызов deflate будет иметь собственные издержки вызова, так как GZipInputStream Java использует собственный zlib реализация.)

Answer 3

Будет ли разумнее позволить веб-серверу выполнять архивирование? Если вы просто пытаетесь уменьшить используемую полосу пропускания, а не хотите хранить файл, заархивированный на сервере, это просто вопрос конфигурации, например, см.

http://tomcat.apache.org/tomcat-5.5-doc/config/http.html

для сжатия HTTP / 1.1 GZIP. Сервер может принудительно отправить ответ клиенту в архиве.

См. Также http://en.wikipedia.org/wiki/HTTP_compression.

Клиент получит заархивированные пакеты и обработает распаковку. Должна также быть возможность потоковой передачи файла, чтобы клиенту не понадобился весь файл, прежде чем он сможет сделать что-то полезное, потому что сервер может архивировать отдельные фрагменты.

Answer 4

Да, вы можете, Поток zip и использовать тип MIME в качестве application / zip

Если вы действительно хотите воспроизводить потоковую музыку на другом конце, тогда это не может бытьсделать это тривиально, так как вы можете распаковать только после того, как весь zip-файл доступен на клиенте.

Если вас интересует размер, вы можете либо уменьшить битрейт mp3, либо использовать форматы, такие как ogg / vorbis

Answer 5

Используйте GZIP, а затем вы можете транслировать.В любом случае Gzip использует алгоритм сжатия zip по умолчанию.