Контекст: я пытаюсь автоматизировать проверку файлов eps, чтобы определить список атрибутов, например, содержит ли файл заблокированные слои, встроенные растровые изображения и т. Д.
До сих пор мы обнаружили, что некоторые из этих вещей могут быть обнаружены посредством проверки необработанных данных eps-файла и сопровождающих их метаданных (аналогично информации, возвращаемой imagemagick .) Однако, похоже, что в созданных файлах с помощью иллюстратора 9 и выше подавляющее большинство этой информации кодируется в части файла «AI9_DataStream». Эти данные кодируются через ascii85 и сжимаются. Мы добились некоторого успеха в получении этих данных, используя: https://github.com/huandu/node-ascii85 для декодирования и узлы zlib
библиотеки для распаковки / распаковки. (Наш проект написан на node / javascript). Однако, похоже, что примерно в половине наших тестовых случаев / файлов разархивируемая часть завершается с ошибкой, вызывая Z_DATA_ERROR
/ «некорректная проверка данных».
Наш метод, отвечающий за попытку декодирования:
export const decode = eps =>
new Promise((resolve, reject) => {
const lineDelimiters = /\r\n%|\r%|\n%/g;
const internal = eps.match(
/(%AI9_DataStream)([\s\S]*?)(AI9_PrivateDataEnd)/
);
const hasDataStream = internal && internal.length >= 2;
if (!hasDataStream) resolve('');
const encoded = internal[2].replace(lineDelimiters, '');
const decoded = ascii85.decode(encoded);
try {
zlib.unzip(decoded, (err, buffer) => {
// files can crash this process, for now we need to allow it
if (err) resolve('');
else resolve(buffer.toString('utf8'));
});
} catch (err) {
reject(err);
}
});
Мне интересно, имел ли кто-либо опыт работы с этой проблемой и имел ли какое-то представление о том, что может быть причиной этого, и есть ли альтернативный путь для надежного декодирования этих данных. Информация по этой теме кажется немного скудной, так что все, что могло бы заставить нас двигаться в правильном направлении, было бы очень цениться.
Примечание: все буферы, создаваемые при декодировании ascii85, имеют один и тот же заголовок 78 9c
, который должен указывать стандартное сжатие zlib (и он фактически распаковывается в анализируемые данные примерно наполовину без ошибок)