Переход непосредственно к байтовому смещению в файле значительно быстрее, чем поиск магического числа. Кроме того, нет никакой гарантии, что магическое число не будет найдено где-либо еще в данных, что может привести к тому, что реализация прочитает неверные данные, если начнет читать из недопустимого, но «предполагаемого правильного» расположения.
После некоторой дополнительной реализации этого, я думаю, самое важное, на что следует обратить внимание, это то, что «данные специального назначения могут находиться в поле расширяемого сектора данных zip64» (после конца записи центрального каталога в Zip64). Может существовать несколько таких полей, каждое из которых начинается с идентификатора заголовка в 2 байта, за которым следует размер данных 4 байта, за которым следуют фактические «данные специального назначения», что позволяет использовать несколько 2 ^ 32 байтов (4 ГБ) данных. , Хотя это может показаться экстремальным, это, безусловно, может привести к необходимости разбивать диски между локатором и «концом записи центрального каталога Zip64». Большие объемы данных здесь не только потребуют больше времени для сканирования сигнатуры, но и случайная вероятность случайного обнаружения минимальной 4-байтовой / 32-битной сигнатуры "zip64 end of central directory" будет увеличиваться с длиной данных.
«Единственный способ найти локатор - найти магическое число для локатора» - это неправда. Если он существует, он должен быть непосредственно перед «Концом записи центрального каталога». Чтение 20 байтов оттуда, а затем чтение следующих 4 байтов должно дать «конец zip64 сигнатуры центрального dir-локатора», который можно использовать как проверку работоспособности (а не сканировать ее).