Comments 14
Поясните, пожалуйста, а откуда перевод каретки в строке из 8 символов?
Было бы интересно тоже самое, но для LH4
6. 03
— операционная система Unix (нужна для LF/CLRF).
Это известный факт, что Win/Mac/Linux по разному кодируют конец строки в текстовых файлах. Но зачем об этом знать архиватору общего назначения (zip) и как-то учитывать?
Я думаю, чтобы правильно интерпретировать перевод строки, когда декодирует файл на винде, который был закодирован на юниксе.
Зачем?
Задача архиватора восстановить файл байт-в-байт.
Думаю это задача алгоритма сжатия и алгоритма декомпрессии.
А где вы прочли про байт в байт?
Не увидел этого в документации к gzip.
Впрочем, проще дождаться ответа автора, раз он сам написал, что для LF/CLRF, чем гадать)
>> Задача архиватора восстановить файл байт-в-байт.
Это оглядываясь с глубины знаний в 30 лет. Видимо в начале 90-х было совсем неочевидно, что требуется сжимать что-то кроме текстовых данных. Сиюминутная задача решалась сиюминутными методами.
https://datatracker.ietf.org/doc/html/rfc1952#page-5
PS: gzip это не архиватор, а компрессор потоковых данных. Возможно поэтому добавили перевод строки. Хотя странно для окончания потока есть спец. символы ETX (End of Text, Ctrl-C), EOT (End Of Transmission, Ctrl-Z).
deleted
08(00001000)
— бит 3 установлен, значит будет присутствовать имя файла.
Здесь могут быть еще контрольная сумма, комментарий и вообще произвольные дополнительные поля. Если это не учитывать тогда декодер тупо рухнет при попытке распаковать нечто, что не является упакованными данными.
Не знал что гзип кодирует имя файла, а зачем ? оно же не используется нигде
Слово “архив” в вашем переводе встречается неоднократно, в то же время в оригинале статьи — ровно 0 раз. Оно и понятно, gzip — не архиватор. gzip — компрессор, “сжиматель”. И не файлов, а потока данных. Это — принципиальные отличия, давайте не будем их валить в кучу.
Распаковываем файл gzip вручную