Por que o uso de um lexer / analisador em dados binários é tão errado?

Costumo trabalhar com lexer / parsers , ao contrário de um combinador de analisador e vejo pessoas que nunca tiveram aula em análise, perguntam sobre a análise de dados binários. Normalmente, os dados não são apenas binários, mas também sensíveis ao contexto. Isso basicamente leva a ter apenas um tipo de token, um token para byte.

Alguém pode explicar por que analisar dados binários com um lexer / parser é tão errado com clareza suficiente para um estudante de CS que não tenha participado de uma aula de análise, mas com base na teoria?

Em princípio, não há nada errado.

Na prática,

• a maioria dos formatos de dados não textuais que conheço não são livres de contexto e, portanto, não são adequados para geradores de analisadores comuns. O motivo mais comum é que eles possuem campos de comprimento, fornecendo o número de vezes que uma produção precisa estar presente.

  Obviamente, ter uma linguagem sem contexto nunca impediu o uso de geradores de analisadores: analisamos um superconjunto da linguagem e depois usamos regras semânticas para reduzi-la ao que queremos. Essa abordagem pode ser usada para formatos não textuais, se o resultado for determinístico. O problema é encontrar algo mais do que conta para sincronizar, pois a maioria dos formatos binários permite que dados arbitrários sejam incorporados; campos de comprimento informam quanto é.

  Você pode então começar a fazer truques, como ter um lexer gravado manualmente, capaz de lidar com isso com o feedback do analisador (o manuseio lex / yacc de C usa esse tipo de truque para lidar com typedef, por exemplo). Mas então chegamos ao segundo ponto.

• a maioria dos formatos de dados não textuais é bastante simples (mesmo que não sejam livres de contexto). Quando as contagens mencionadas acima são ignoradas, os idiomas são regulares, na pior das hipóteses, LL1 e, portanto, são adequados para técnicas de análise manual. E o manuseio das contagens é fácil para técnicas de análise manual, como descida recursiva.

Vamos categorizar os dados em três categorias: dados legíveis por seres humanos (geralmente textos, variando de livros a programas), dados destinados a serem lidos por computadores e outros dados (analisando imagens ou sons).

Para a primeira categoria, precisamos processá-los em algo que um computador possa usar. Como os idiomas usados ​​pelos seres humanos geralmente podem ser capturados relativamente bem pelos analisadores, geralmente usamos analisadores para isso.

Um exemplo de dados na terceira categoria seria uma imagem digitalizada de uma página de um livro que você deseja analisar em texto. Para esta categoria, você quase sempre precisa de um conhecimento muito específico sobre sua entrada e, portanto, precisa de um programa específico para analisá-la. A tecnologia de análise padrão não o levará muito longe aqui.

Sua pergunta é sobre a segunda categoria: se temos dados binários, quase sempre é um produto de um programa de computador, destinado a outro programa de computador. Isso imediatamente significa também que o formato em que os dados estão é escolhido pelo programa responsável por sua criação.

Programas de computador quase sempre produzem dados em um formato que possui uma estrutura clara. Se analisarmos alguma entrada, estamos essencialmente tentando descobrir a estrutura da entrada. Com dados binários, essa estrutura geralmente é muito simples e fácil de analisar pelos computadores.

Em outras palavras, normalmente é um desperdício descobrir a estrutura de uma entrada para a qual você já conhece a estrutura. Como a análise não é gratuita (leva tempo e adiciona complexidade ao seu programa), é por isso que o uso de lexers / analisadores em dados binários é "tão errado".

$a + b \times (c - d) + e$(+ a (* b (- c d)) e)a b c d - * + e +. A notação matemática usual tem mais redundância que Lisp (que requer mais parênteses, mas obtém aridades variáveis ​​de graça, requer menos símbolos para expressar expressões usando grandes aridades) ou RPL (que nunca precisa de parênteses). Essa redundância raramente é útil para computadores - e onde está, que é quando pode haver erros nos dados, a lógica de correção de erros geralmente é mantida separada do significado funcional dos dados, por exemplo, usando códigos de correção de erros aplicáveis ​​a métodos arbitrários. seqüências de bytes, independentemente do que elas representam.

Os formatos binários são geralmente projetados para serem compactos, o que significa poucos recursos simples de linguagem, como parênteses balanceados, que são expressáveis ​​por gramáticas sem contexto. Além disso, é frequentemente útil que representações binárias de dados sejam canônicas, ou seja, tenham uma única representação de cada objeto. Isso exclui recursos às vezes redundantes, como parênteses. Outra consequência menos recomendável de ter menos redundância é que, se todas as entradas estiverem sintaticamente corretas, elas economizam na verificação de erros.

Outro fator contra analisadores não triviais para dados binários é que muitos formatos binários são projetados para serem analisados ​​por código de baixo nível que gosta de operar na memória constante com pouca sobrecarga. Os tamanhos fixos são preferidos, quando aplicável, para permitir a repetição arbitrária de um elemento. Um formato como TLV que permite que um analisador da esquerda para a direita aloque a quantidade certa de memória para um objeto primeiro e, em seguida, leia a representação do objeto. A análise da esquerda para a direita é uma vantagem, pois permite que os dados sejam processados ​​da maneira que vêm, sem buffer intermediário.