JavaScript. Работа с большими файлами в браузере. Часть 1/2: Чтение файлов

[GCU]

Почему отказались от блока (чанка) PNG? Кажется графические редакторы сохраняют неизвестные блоки внутри PNG, а вот "хвост" могут и потерять

[Mingun]

Вот тоже интересно, если автор всё равно свой чанк в PNG засовывает, то зачем данные в конец файла пихать? Почему их в этом чанке и не разместить?

[Alex_BBB]

Хранить вложения в PNG чанках не стал из-за ограничения на длину названия. Можно целиком всю DGRM data со свой структурой в один чанк положить. Но самодельные чанки тоже вырезают. Поэтому не знаю как лучше. Может вообще на свои .dgrm файлы перейти. И пользователей не путать, и вырезаться данные не будут и файлы меньше весить.

[Mingun]

Не понял, ограничение на длину названия чего? Типа чанка? Так а зачем вам длинное, достаточно какой-то уникальный для себя придумать. А внутри чанка ограничений никаких и нет, это же полностью ваша структура. Ну и если кто-то вырезает самодельные чанки из PNG, то уж и хвост-то им точно отрезать не проблема, так что всё равно не видно смысла в выбранной вами реализации.

[Alex_BBB]

Так а зачем вам длинное, достаточно какой-то уникальный для себя придумать.

Да. В моем комменте выше это отметил.

У чанка есть ограничение на размер - поле с размером чанка 4 байта. Много больших вложений могут не поместиться.

[subzey]

В этом случае делайте так же, как IDAT: если все данные не влезают в один 2 Гб чанк, создайте второй

[Alex_BBB]

Можно. А зачем? Чем PNG чанк лучше чем писать в конец файла?

[GCU]

Есть стандартный чанк iTXt, который хорошо подходит для хранения сжатого текста UTF-8 (JSON)

Чем стандартный чанк хорош - для него есть готовые библиотеки, из коробки получаем сжатие deflate, проверку целостности и частичную поддержку редакторами

[subzey]

Промахнулся и не туда ответил. Сорри. «Чем лучше чанки, чем дописывать в конец?»

Всяким минификаторам и библиотекам можно сказать не трогать чанк. Например: Пнгшка генерится с упором на скорость, а потом хочется сжать её получше для долгосрочного хранения.

Любое количество чанков хорошо дружит между собой, а «вконецфайла» всего один. Например: Пользователь захочет криптографически подписывать содержимое, а подписывалка тоже пишет данные в конце файла. Потенциальный конфликт.

Кастомные чанки можно двигать вперёд и назад. Например: Можно передвинуть важные данные поближе к началу, и при загрузке по сети или другом стриминге не загружать остаток файла.

Наконец, если формат и так предоставляет возможность хранить метаданные, то почему бы и нет?

[Rxd]

А для чего вы храните данные в png, а не используете любой другой формат?