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


13

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?


Meu palpite é que o lexer provavelmente não consegue encontrar tokens menores que um byte / palavra. Se você precisar dele, Erlang tem um excelente suporte para binários de análise: user.it.uu.se/~pergu/papers/JFP_06.pdf
Dave Clarke

3
Não acho que sua suposição seja verdadeira. Obviamente, dados não livres de contexto apresentam problemas (que geralmente podem ser contornados), mas você pode fornecer gramáticas para palavras binárias. Provavelmente, você não poderá usar geradores de analisadores populares, pois eles assumem a entrada de texto. Essa é outra questão, no entanto.
Raphael

@ BuyCoder: Muitos exemplos clássicos de gramática usam alfabetos binários, por exemplo, . S0 0S10S
Raphael

1
A propósito: "tendo apenas um tipo de token, um token para byte". - bem, não, isso daria tokens de bytes. 28
Raphael

5
@ BuyCoder: todos os dados gerados por outro programa podem ser descritos por uma gramática. Porém, pode não ser livre de contexto.
Raphael

Respostas:


10

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.


"as línguas são regulares" Se ", mas também sensível ao contexto", foi usado para significar que os dados binários são uma gramática, esclarecerei na resposta. Isso chega a parte do problema; as pessoas tendem a pensar em gramáticas ou idiomas regulares depois que você Parser de menção.
Guy Coder 30/03

7

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".


2
Essa é uma boa perspectiva, mas sinto que não responde à pergunta.
Raphael

LANGSEC: Language-theoretic Securityoferece uma perspectiva interessante. Um dos artigos fala sobre "máquinas estranhas": analisadores ad hoc de um formato conhecido, formando as instalações de manipulação de entrada de um sistema. Eles podem não funcionar realmente como pretendido. Devido a suposições incorretas, a máquina defeituosa executará transições imprevistas de estado, com dados especialmente criados, executando cálculos que não deveriam ser possíveis. Isso cria um vetor de ataque. O uso de gramáticas formais produziria algoritmos comprovadamente corretos.
Matheus Moreira

0

uma+b×(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.


Qual é o objetivo dos dois primeiros parágrafos? Mesmo se você não tiver redundância, precisará de um analisador. Além disso, o primeiro parágrafo está errado: há exemplos em que todas as palavras são permitidas, mas você analisa para obter a estrutura (por exemplo, previsão da estrutura secundária do RNA).
Raphael

@ Rafael Um analisador não trivial geralmente implica redundância (sim, como você aponta, há exceções). Eu não tinha considerado linguagens que não foram projetadas nem para humanos nem para computadores, este é um exemplo interessante. Os dois primeiros parágrafos discutem diferenças típicas entre os formatos binários e legíveis por humanos (o que significa que se você procurar exceções, as encontrará).
Gilles 'SO- stop be evil'
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.