Чому використання лексера / парсера для двійкових даних так неправильно?

Я часто працюю з лексером / парсерами , на відміну від комбінатора парсера і бачу людей, які ніколи не брали клас на розбір, запитують про розбір бінарних даних. Зазвичай дані не тільки двійкові, але й контекстно-залежні. Це в основному призводить до наявності лише одного типу токена, лексеми для байта.

Чи може хтось пояснити, чому розбір бінарних даних за допомогою лексера / аналізатора настільки неправильний з достатньою чіткістю для студента CS, який не взяв клас розбору, але з опорою на теорію?

В принципі, нічого поганого немає.

На практиці,

• Більшість нетекстових форматів даних, які я знаю, не є контекстними і тому не підходять для генераторів загального парсерування. Найпоширенішою причиною є те, що вони мають поля довжини, що дають кількість присутніх у виробництві.

  Очевидно, що безконтекстна мова ніколи не заважала використовувати генератори парсеру: ми розбираємо надмножину мови, а потім використовуємо семантичні правила, щоб зменшити її до того, що ми хочемо. Цей підхід може використовуватися для нетекстових форматів, якщо результат буде детермінованим. Проблема полягає в тому, щоб знайти щось інше, ніж рахунки для синхронізації, оскільки більшість бінарних форматів дозволяють вбудовувати довільні дані; поля довжини говорять вам, скільки це.

  Потім ви можете почати грати трюки, як, наприклад, записаний вручну лексер, здатний впоратися з цим зворотним зв'язком з аналізатора (lex / yacc обробка C використовує такі типи, наприклад, для обробки typedef). Але тоді ми приходимо до другого пункту.

• більшість нетекстових форматів даних є досить простими (навіть якщо вони не є контекстними). Коли вищезгадані підрахунки ігноруються, мови є регулярними, LL1 в гіршому випадку, і, таким чином, добре підходять для методик ручного розбору. А обробка підрахунків легко для ручного розбору методів, таких як рекурсивний спуск.

Далі класифікуємо дані на три категорії: дані, які читаються людьми (зазвичай це тексти, що відрізняються від книг до програм), дані, призначені для читання на комп’ютерах, та інші дані (розбір зображень або звуку).

Для першої категорії нам потрібно переробити їх у те, що комп’ютер може використовувати. Оскільки мови, якими користуються люди, як правило, можуть бути досить чітко захоплені парсерами, ми зазвичай використовуємо для цього аналізатори.

Прикладом даних третьої категорії може бути відскановане зображення сторінки з книги, яку потрібно розібрати в текст. Для цієї категорії вам майже завжди потрібні дуже конкретні знання про ваш внесок, і тому вам потрібна конкретна програма для її розбору. Стандартна технологія розбору не приведе вас сюди дуже далеко.

Ваше запитання стосується другої категорії: якщо ми маємо дані, що є двійковими, це майже завжди продукт комп’ютерної програми, призначений для іншої комп'ютерної програми. Це негайно також означає, що формат, в якому є дані, вибирається програмою, відповідальною за їх створення.

Комп'ютерні програми майже завжди виробляють дані у форматі, який має чітку структуру. Якщо ми проаналізуємо деякий вхід, ми, по суті, намагаємося з’ясувати структуру введення. З двійковими даними ця структура, як правило, дуже проста і легко розбирається за допомогою комп'ютерів.

Іншими словами, це звичайно трохи марно розібратися в структурі входу, для якого ви вже знаєте структуру. Оскільки синтаксичний аналіз не є безкоштовним (це вимагає часу і додає складності вашій програмі), саме тому використання лексерів / аналізаторів на бінарних даних "так неправильно".

$a + b \times (c - d) + e$(+ a (* b (- c d)) e)a b c d - * + e +. Звичайні математичні позначення мають більше надмірності, ніж Lisp (що вимагає більшої кількості дужок, але отримує змінні артури безкоштовно, тому потрібно менше символів для вираження виразів за допомогою великих артій) або RPL (який ніколи не потребує дужок). Така надмірність рідко корисна для комп'ютерів - і там, де вона є, що може виникнути помилки в даних, логіка виправлення помилок зазвичай тримається окремо від функціонального значення даних, наприклад, використовуючи коди виправлення помилок, які застосовуються до довільних послідовності байтів незалежно від того, що вони представляють.

Бінарні формати зазвичай розроблені як компактні, що означає кілька простих мовних функцій, таких як врівноважені дужки, які можна висловити без контекстних граматик. Крім того, часто корисно, щоб двійкові уявлення даних були канонічними, тобто мати єдине представлення кожного об'єкта. Це виключає часом зайві функції, такі як дужки. Інший, менш похвальний наслідок меншої надмірності - це те, що якщо кожен вхід синтаксично правильний, він економить на перевірці помилок.

Ще один фактор проти нетривіальних аналізаторів бінарних даних полягає в тому, що багато бінарних форматів розроблені так, щоб вони були проаналізовані кодом низького рівня, який любить працювати в постійній пам'яті з невеликими накладними витратами. Фіксовані розміри бажані, коли застосовні, щоб дозволити довільне повторення елемента. Такий формат, як TLV, який дозволяє ліворуч-правому аналізатору спершу виділити потрібний об'єм пам'яті для об'єкта, а потім прочитати представлення об'єкта. Розбір зліва направо є перевагою, оскільки дозволяє обробляти дані в міру надходження, без проміжного буфера.