Free parsing 1.3 software for linux

msgparser project is a parser for .msg Files in Java.

msgparser is a small open source Java library that parses Outlook .msg files and provides their content using Java objects.

msgparser uses the Apache POI - POIFS library to parse the message files which use the OLE 2 Compound Document format. Thus, it is merely a convenience library that covers the details of the .msg file. The implementation is based on the information provided at fileformat.info.

Examples:

This page shows how to use the msgparser library to access to content of a .msg file.

For parsing the .msg file, a MsgParser object must be created. This parser can process .msg files stored in a file or coming from an InputStream.

MsgParser msgp = new MsgParser();
Message msg = msgp.parseMsg("mail.msg");

The resulting msg object contains all necessary information (e.g., from, to, subject).

String fromEmail = msg.getFromEmail();
String fromName = msg.getFromName();
String subject = msg.getSubject();

Attachments are stored in Attachment objects.

List atts = msg.getAttachments();
for (Attachment att : atts) {
// do something with attachment
}

An attachment is either a file (which is a FileAttachment object) or another attached .msg file (i.e, an .msg file in an .msg file) (which is a MsgAttachment object).

DParser project is an simple but powerful tool for parsing. You can specify the form of the text to be parsed using a combination of regular expressions and grammar productions.
Because of the parsing technique (technically a scannerless GLR parser based on the Tomita algorithm) there are no restrictions.
The grammar can be ambiguous, right or left recursive, have any number of null productions, and because there is no seperate tokenizer, can include whitespace in terminals and have terminals which are prefixes of other terminals.
DParser handles not just well formed computer languages and data files, but just about any wacky situation that occurs in the real world.
Main features:
- Powerful GLR parsing
- Simple EBNF-style grammars and regular expression terminals
- Priorities and associativities for token and rules
- Built-in error recovery
- Speculative actions (for semantic disambiguation)
- Auto-building of parse tree (optionally)
- Final actions as you go, or on the complete parse tree
- Tree walkers and default actions (multi-pass compilation support)
- Symbol table built for ambiguous parsing
- Partial parses, recursive parsing, parsing starting with any non-terminal
- Whitespace can be specified as a subgrammar
- External (C call interface) tokenizers and external terminal scanners
- Good asymptotically efficiency
- Comes with ANSI-C, Python and Verilog grammars
- Comes with full source
- Portable C for easy compilation and linking
- BSD licence, so you can included it in your application without worrying about licensing
Enhancements:
- Removed call to exec in python interface (Brian Sabbey)
- Fix binary_op_left in python interface (Brian Sabbey)

spConfig is a C library made for parsing configuration files with a syntax similar to XML.
spConfig is a configuration file parsing library intended to allow one to add configuration file functionality to an application with relative ease. Configuration files use an XML-like syntax with some additional preprocessor-style commands.
Installation:
unpack the archive, cd to spconfig-0.1.3
./configure
make
make install
After installation, youll need to run ldconfig before you start linking to it. You probably need to be root to run it.
Enhancements:
- new build system
- [else] directive
- bugfixes

Parse::Nibbler is Perl module to parse huge files using grammars written in pure perl.

Create a parser object using the ->new method. This method is provided by the Parse::Nibbler module and should not be overridden.

The main functionality of the Parse::Nibbler module is the Register subroutine. This subroutine is used to define the rules of your grammar. The Register subroutine takes two parameters: A string and a code reference.

The string is the name of the rule (i.e. the name of the subroutine/method)

The code reference is a reference to the code to execute for this rule.

The Register subroutine will take the code reference, wrap it up in another subroutine that acts as a closure, and then installs that code reference as a subroutine with the name matching the given string.

The wrapper code (the closure) is the same for every rule. The wrapper code handles quantifiers, calls the rule, and decides what to do based on the rule passing or failing.
A rule is a code reference with a given string name that have been passed to Register. Here is an example of a rule:
Register ( Name, sub { my $p = shift; $p->AlternateValues( Jim, Scotty, Spock );
}
);

The parser object will always be passed in as the first parameter to your rule. You must pass this into any further rules or any Parse::Nibbler methods.

In the above example, the rule, "Name" is Registered. "Name" calls one of the builtin methods, AlternateValues, defined below. Once a rule is Registered, other rules can call it:
Register ( MedicalDiagnosis, sub { my $p = shift; $p->AlternateValues("Hes", "Shes"); $p->ValueIs("dead"); $p->ValueIs(","); $p->Name; $p->ValueIs("!"); } );

This code registers a rule called "MedicalDiagnosis". It uses some builtin methods, but it also calls the rule just registered, "Name".

Once a user defines a rule, they can use it in other rules by simply calling it as they would call a method.

Rules registered with the Parse::Nibbler module can be called with quantifiers. Quantifiers are passed into the Rule when you call it in your grammar by passing in a string that matches the format described here.

Quantifiers allow you to specify the quantity of rules present. Quantifiers also allow you to specify whether multiple rules have separators.

Quantifiers are specified using the following string format:

{quantifier}

This indicates that there are zero or one Name rules expected: $p->Name({?});
This indicates that there are zero or more Name rules expected: $p->Name({*});
This indicates that there are one or more Name rules expected: $p->Name({+});
This indicates that there are exactly three Name rules expected: $p->Name({3});
This indicates there are 1 to 3 Name rules expected: $p->Name({1:3});
This indicates there are at least 2 Name rules expected: $p->Name({2:);

Separators are specified using the following string format:

/separator/

This indicates 1 or more Name rules, each separated by a comma:

$p->Name({1:}/,/);

It is the job of the Register function to make sure this additional functionality is provided transparently and automagically to you.

If you call a rule with no quantifier and no separator, the rule will assume the quantifier is 1 and there is no separator.

Additional Parse::Nibbler methods are provided to simplify rule definition and to provide smart, automatic error handling, etc. You grammars should only call other rules that you defined, or these methods explained below.

(Note: these methods do not take quantifiers)
############### Method: ValueIs ###############
Parameters: One parameter, required. A string containing the expected value.
Example: $p->ValueIs( stringvalue );
Description:
This method will look at the next lexical and determine if its value matches that of the stringvalue given as a parameter. If it does not match, an exception is raised and the rule fails.
If the values do match, then the parser stores the lexical, and the rule continues.
####################### Method: AlternateValues #######################
Parameters: A list of string parameters, at least two values.
Example: $p-AlternateValues( value1, value2 );
Description:
This method behaves like the ValueIs method, except that it will recieve a list of allowed alternate expected values. The first match that succeeds causes the rule to pass and return.
If no match occurs, then an exception is raised and the rule aborts.
If a match does occur, the parser stores the lexical, and the rule continues.
############## Method: TypeIs ##############
Parameters: One parameter, required. A string containing the expected type.
Description:
This method will look at the next lexical item, and determine if the lexical type matches the type given as a parameter.
Valid type values depend on the Lexer that you use, but possible values may include "Identifier" and "Number", etc.
Use this in a case where your rule requires an identifier type, for example, but it does not care what the name of the identifier is for the rule.
If a match occurs, the parser stores the lexical and the rule continues.
If a match does not occur, an exception is raised, and the rule aborts.
###################### Method: AlternateRules ######################
Parameters: A list of string parameters, at least two.
Example: $p->AlternateRules( Rule1, Rule2 );
Description:
You can describe rule alternation in your rule by calling this method. The method takes a list of strings whose string values match the names of the valid alternate rule names.
In the above example, the McCoy rule is either a declaration of profession or a medical diagnosis. These are two rules that are defined in the same package. The AlternateRules method allows you to define multiple rules that may be valid at the same point in the text.
If a rule in the parameter list succeeds, the AlternateRule method succeeds, and returns immediately.
If no rule succeeds, an exception is thrown, and the rule aborts.
This rule expects either a "DeclareProfession" rule or a "MedicalDiagnosis" rule to be present.
Register ( McCoy, sub { my $p = shift; $p->AlternateRules( DeclareProfession, MedicalDiagnosis ); } );
You can specify quantifiers as part of the alternate rule strings.
$p->AlternateRules( DeclareProfession({+}), MedicalDiagnosis );
The above example indicates that you can have one or more DeclareProfession rules OR ALTERNATELY you can have exactly one MedicalDiagnosis rule.

EXPORT

Register, used to register the rules in your grammar.