Comments 80
Передавать мы как раз можем. Мы не можем читать, но это уже проблемы клиента. А передавать мы можем — файлы не зависят друг от друга, и мы можем добавлять их на лету.
> во времена создания формата zip файлы размером 1.3 Гб даже не предполагались [...] еще раз указывает на недостаточную продуманность структуры формата.
Ну да, ну да. В 1990 году кто-то не подумал про файлы размером в миллион дискет. Кошмар! А в 2020 кто-то думает о том, что int64 может закончиться? Что ядро линукса принципиально не способно адресовать вигинтиллион йоттабайтов памяти? На костёр, на костёр немедленно! Сначала надо продумать, чтобы потомки через 3000 лет не писали про нас статьи!
При этом создатель ZIP был школьником\студентом которому были доступны 640 Кб которых как известно должно было хватить всем (с)
Тогда IBM 0681 как и сейчас квантовые компьютеры - доступны очень узкому кругу. Если бы PK так широко мыслил то думаю первым что бы он сделал - оформил патент а потом бы уже думал как адресовать гигабайты правильно
Кажется, мы тут рассуждаем о причинах, а не оправданиях.
CD стоял у приятеля на 386SX в начале 90х, а DVD формат массово появился лет через десять, "из-за чего CD и пользовался популярностью" :)
Почему странная, я помню что этот CD еще в саундбластер подключался шлейфом, в не в материнку, собственно он его потом вместе с саундбластером и продал. В 94 у него уже пень был, а в 98 пень уже был и у меня, за целых 200$ купленный
Я купил ранней весной 1995 года в "Мультимедиа Клубе" CD-ROM Matsushita (с интерфейсом Panasonic) за 285 долл. В соседнем санрайзе такой же стоил 300. Привод был двухскоростной. Подключал его к Sound Galaxy NX2, купленной там же (не помню, тогда же или двумя неделями раньше). Это было время, когда все эти штуки продавались в огромных красивых коробках
Ща почитал эту статью на википедии и вспомнил что у него был как раз этот упомянутый "Multimedia Upgrade Kit"
CD-ROM были сравнительно доступны ещё в условном 1994, даже в России. И в тот же Myst или Command&Conquer можно было ну хотя бы на 486 сносно играть.
Вот пишущие CD-приводы - те да, были дорогими до начала 2000-х.
Мало какие форматы сравнимы по удобству. Такое ощущение, что разработчики предусмотрели вообще всё!
{Не лично Вам. Комментарий подходящий... ))}
Формат TIFF (контейнер для растровых, сеточных/табличных данных) довольно неплохо документирован. Также есть стандартный путь расширения. Так появился GeoTIFF. Причём, в ячейке растра (сетки, таблицы) можно хранить, как целые, так и вещественные данные (для полей значений, например, превышения над уровнем референц-эллипсоида, температуры, концентрации какого-то минерала в почве и пр.).
При этом, из-за его заложенной расширяемости существует правило: не знаем что за данные под конкретным тегом скрыты — не читаем.
Поэтому, даже файл с кучей метаданных не все программы могут полностью прочитать. Зато, хотя бы показать должен почти любой визуализатор.
И тут... больше вопросов не к создателям формата, а к программистам. Так, в TIFF можно записать изображение, сжатое алгоритмом JPEG, но не все программисты делают так, что это изображение можно прочитать, т. к. ограничиваются интерпретацией только базовых примитивных схем кодирования растров/сеток.
А потому у многих недалёких программистов есть предубеждение ,что формат TIFF плохой, ограниченный и устаревший. Это, как сказать, что авоська или холщовая сумка устарела и твердотельные диски из магазина можно носить домой только в пластиковом нанопакете. )) Хотя их можно перенести и в авоське. ))
А если вспомнить тайлы и пирамидальные слои в TIFF, то можно сказать, что это ОТЛИЧНЫЙ формат, который позволяет очень быстро оперировать с растрами/сетками в графических программах при визуализации.
Отсюда, все программисты делятся на тех, кто предусматривает дальнейшее использование изделия, и на тех, у кого нет времени, нет желания что-то доделывать, нет квалификации, чтобы предусмотреть дальнейшие пути развития.
А так... Делить программистов на создателей формата и неких загадочных пользователей — контрпродуктивно. Все они программисты. ))
Со всем согласен, кроме последнего абзаца) пользователи -- это вполне реальные пользователи, в случае с TIFF -- дизайнеры, полиграфисты.
Почему они? Формат получился тяжеловесный, с кучей параметров и сложной реализацией и интерпретацией, которую далеко не все осилили, поэтому пользователям пришлось годами договариваться между собой "формат используем, но в такой-то версии, без сжатия, без слоёв".
При этом не было общепринятой договоренности про какой-то fallback, поэтому в броузерах его поддерживать особо и не пытались -- слишком сложно.
Зато для обмена между дизайнерскими системами, в CMYK, без сжатия -- самое то.
Возможно, это неплохой пример нарушения причинно-следственной связи.
Удобство развилось исходя из доступности именно такого формата, а не какого-то другого.
Примерно как "у кошки дырочки на шкурке там же где глаза!"
https://bash.im/quote/397561
А как же проблемы с кодировкой (с её отсутствием)?
Пожатые на Linux файлы с кириллицей в UTF-8 превратятся после распаковки на Windows с CP1251 в кракозябры. Ну и наоборот.
"В какой локали запаковывали - в такой и распаковывайте" - очень удобно!
Сейчас уже и Windows c UTF-8 по умолчанию может оказаться.
В историческом контексте оно может и хорошо, что когда-нибудь все файлы будут в UTF-8 и проблема уйдет для новых архивов, но в конкретный момент времени Windows-админы, не знавшие проблем пока ZIP-архивы только между Windows с CP1251 пересылались, хлебанут проблем с архивами -)
Казалось бы, такой известный формат, так все его повсюду используют, что может пойти не так?)))
А как же проблемы с кодировкой (с её отсутствием)?
Нет кодировки — нет проблем.
А то придумают тоже — кодировки какие-то, локали еще…
PS. напомнило "если в телефоне фирмы не указан код страны, то фирма — американская; если и код города — то московская". Кодировка — обычная ™
В том самом appnote (в относительно новых ревизиях) четко специфицирован юникод-флаг в 11м бите. Если выставлен - значит, utf8, если нет - то cp437. Известные мне линуксовые архиваторы юникод-флаг корректно выставляют. В общем, это уже давно проблема не формата, а конкретных реализаций.
Каменный топор – как не нужно делать инструменты.
Перезаписывать весь архив долго не только на дискетах. Когда у меня в цикле добавлялись файлы в 5-гигабайтный архив и он каждый раз переписывался полностью, это было очень долго.
Файлы нулевого байтаМашинный перевод такой машинный…
В оригинале — «Zero-byte files», и это лучше перевести как «Файлы нулевого размера»
И да, ещё есть ID3-тэги для метаданных. 1й версии в конце файла, с фиксированным набором полей фиксированной длины, 2й версии в начале, хитрого формата и с кучей возможностей. Между фреймами может быть мусор. В конце и в начале файла может быть мусор. Я почти уверен, что можно сделать rarjpegmp3, причём засунув одну половину mp3 в exif в jpeg, а другую в архив без сжатия.
В общем, да, mp3 — не лучший формат файла.
Я почти уверен, что можно сделать rarjpegmp3, причём засунув одну половину mp3 в exif в jpeg, а другую в архив без сжатия.
В бытность FIDO ходил один DOS.MP3 (та самая известная песенка). Но на самом деле это был архив с МР3 без сжатия. Как итог - плееры его играли без проблем, т.к. о формате судили по расширению файла, а оболочки "проваливались" в него, так как анализировали содержимое файла, и показывали DOS.MP3 файл внутри DOS.MP3 файла, снося крышу новичкам и неискушённым.
Хм, у меня где-то сохранился файл с таким именем… надо будет проверить, а ну как в нем есть-таки zip-заголовок.
По сравнению с файлом, который было невозможно прочитать с CD, это всё цветочки.
А ягодки - это файл с именем con
Так до сих пор нельзя! Вин10, какой-то там летний апдейт 20H1.
А диски же изначально для музыки создавались. Может там не критично..
Сравните ситуацию: нельзя (зарезервированное имя файла из-за совместимости с DOS) и можно (нигде в документации запрета нет), но файл с определённой сигнатурой внутри не прочитается.
На самом деле такие файлы крайне маловероятны (по ссылке описано, как файл получился и почему эта сигнатура ломает чтение с диска). Но вообще это просто баг в стандарте. В DVD такого уже, кажется, нет.
Не то то чтобы плохой, но не совсем подходящий для тех целей, для которых его начали применять.
MP3-файл - это MPEG с одним только звуковым потоком. MPEG - стриминговый формат, и он рассчитан на то, чтобы поток можно было начать читать с произвольного места, не имея доступа к началу или к концу файла. При этом в нем могут перемежаться потоки видео, аудио и метаданных. Предполагается, что при перемотке декодер тыкается приблизительно в нужное место, а дальше ищет синхропоследовательности знакомых ему типов фреймов.
Но вот ID3 второй версии - это реально больной формат, нет ему оправданий.
Что, если есть некая
local file record, на которую центральный каталог не ссылается?
Стеганография
Жаль что статья кончилась так быстро, мне так хотелось почитать раздел про пароли на архив
а почему, товарищи из Windows, решили встроить в ос формат zip ? какая выгода?
раз так все плохо?
Раньше были. Потом авторов подразогнали и осталось самое простое - переводить чужие тексты.
У тех, кто для себя постановил публиковать 2-3 поста ежедневно, оригинальных текстов почти не встречается.
Да и вообще, какой-то дайджест перепечаток.
С другой стороны, если тема интересна и видишь, что перевод корявый, всегда можно пойти прочесть оригинал, а так может никогда бы и не наткнулся на него
Ведь обычно работают с SFX на той же системе, которой он был создан, DOS/WIN или Linux. Хотя можно было бы и поддержать исполняемый формат большинства популярных SFX, их полагаю не так много. И для этого необязательно вносить поправки в описание формата.
Насчет обязательности к каждому типу записи придавать размер. В случае с архивом тут немаловажно учитывать влияние на итоговый размер. В общем случае достаточно указывать размер в файловых записях чтобы можно было перейти на следующий файл, если у текущего файла не знаем как обработать полностью его подзаписи.
Чего ещё хотели от замшелого легаси времён 640 и 720 кБ? :)
смещение до центрального каталога равно 1,347,093,766?
Это смещение 0x504b0506
Эм, если архив пишется в формате LSB, то искомое смещение должно быть равно 0x06054b50=101010256 (любопытное число, красивое такое). Все равно слишком много для тех времен, но уже более вменяемое.
Справедливости ради - старый XLS по упоротости (даже без OLE Compound) вполне гармонично вписывается в эту компанию.
ADD: если подумать, то все сложные форматы при чтении вызывают определённый WTF/мин. И только старый однобитный TXT и такой же старый COM просты и понятны. Но TXT обзавёлся BOM, а COM (тот, старый, который глузился и выполнялся as is и был ограничен по размеру) нафиг уже никому не нужен.
Скажу больше - явовский jar это тоже zip, в который упакованы все файлы программы вместе с манифестом
А еще есть проблема 2038 года, ZIP она тоже затрагивает.
Даже не знаю, каким занудой надо быть, чтобы быть недовольным форматом файла из 89-го года, который еще и стал открыт для бесплатного использования.
12 лет назад наступал на те же грабли ;-) Помню, тогда написал о проблеме разработчикам, но ответа не получил. Так чего уж кулаками махать спустя 30 лет... )))
По ссылке выше есть зипчик с другим зипчиком в качестве комментариев. Разные архиваторы видели либо оригинальный архив, либо комментарий. Любопытно, что 7zip, который 12 лет назад открывал файл из комментария (т.е. сканировал файл с конца), сегодня открывает файл из основного архива (т.е. уже сканирует сначала). Win10 (она нативно умеет в зип) считает что файл битый.
Я правильно понимаю, что в архиве могут быть файлы отсутствующие в Central Directory? И при листинге списка файлов, стандартными распаковщиками типа InfoZip?, они будут не видны, а при распаковке не будут извлечены?
Zip – как не нужно создавать формат файлов