Analisi di più formati / protocolli di file

7

Stiamo avviando un progetto in cui avremo bisogno di scrivere parser per una serie di formati di file binari, ognuno dei quali rappresenta dati molto simili (serie di valori temporali da diversi dispositivi di misurazione).

Dato che partiamo da zero, mi piacerebbe farlo bene e vedo due possibili approcci:

  1. scrive parser binari dedicati e generati in modo autonomo per ogni formato separatamente o

  2. rappresentano i formati binari utilizzando una grammatica e quindi utilizzano alcuni algoritmi standard per l'analisi / tokenizzazione lessicale.

Ogni volta che cerco un consiglio su come costruire un parser, trovo la maggior parte dei ragazzi che difende il secondo approccio. Tuttavia, non ho molta esperienza con grammatiche e linguaggi formali e temo che ci possa essere una curva di apprendimento prima di ottenere risultati.

Quindi, fondamentalmente ho queste domande:

  • Qual è il problema con la codifica dei parser "a mano"?
  • Esiste un "limite di dimensione" pratico di un problema quando si paga per investire nell'apprendimento dell '"approccio formale"?
  • La maggior parte degli esempi di analisi si concentrano su file testuali. Qual è il modo migliore per specificare la grammatica per un parser binario?
posta Lou 11.07.2012 - 18:19
fonte

2 risposte

4

I don't have much experience with formal grammars and languages, and I am afraid that there might be a learning curve before we get results.

Passa un paio di pomeriggi a costruire un semplice progetto per provarlo. Dato che è necessario supportare "un mucchio" di formati, è una buona scommessa che il tuo investimento nell'imparare a utilizzare strumenti che fanno esattamente ciò di cui hai bisogno paghino rapidamente.

What is the problem with coding parsers "by hand"?

I problemi sono principalmente:

  • scrivere e gestire parser a mano richiede molto tempo, è difficile e soggetto a errori

  • scrivere il codice significa che c'è un altro livello di riferimento indiretto tra le due cose che ti interessano: il formato e il parser. Se il parser non funziona correttamente, devi guardare il codice per capire perché. Se invece puoi specificare il formato come grammatica, dovrebbe essere più facile vedere dove si trova il problema (o evitare problemi in primo luogo).

Is there a practical "size limit" of a problem when it pays off to invest in learning the "formal approach"?

Sospetto che il punto in cui si trova la linea dipenda dalla tua situazione. Coding parser a mano sarà sempre più facile se non si conosce in alcun altro modo. Mentre ti trovi più a tuo agio con strumenti come flex e bisonte (o qualsiasi altra cosa tu scelga), la linea si sposterà.

Most parsing examples focus on textual files. What is the good way to specify grammar for a binary parser?

Non penso che debba essere il caso. Ad esempio, flex ti consente di specificare i caratteri di input in termini di valori ottali o esadecimali .

    
risposta data 11.07.2012 - 20:12
fonte
3

A seconda di quanto siano complessi i formati dei file, ho il sospetto che sarebbe meglio scrivere una libreria di analisi dei servizi e scrivere manualmente i lexer / parser. L'ho già fatto per analizzare i record BAF dagli interruttori telefonici e si può fare un salto abbastanza veloce (un paio di giorni). Se avessi già familiarità con strumenti di analisi come flex e bisonte, avrei seguito il suggerimento di Caleb, ma dal momento che non lo faresti suggerirei di attenersi a ciò che sai. Presumo che nessuno nel tuo team abbia familiarità con gli strumenti di analisi, quindi in questo modo tutti dovrebbero essere in grado di mantenere il codice in avanti (nessun 'single point of failure' quando si verifica un errore / errore di analisi).

    
risposta data 11.07.2012 - 20:44
fonte

Leggi altre domande sui tag