Anders B wrote:
<backposted />
I don't know Lua nor the specific format it uses, but based on the
file you posted, I suppose you could come up with a LUA -XML
translator quite easily, with a minimum of hair pulling (there will be
some, though), and a maximum of fun for, say, a rainny afternoom.
To write such parser, you could start with a "grammar" for the file
format, which would be something like the follwoing (again, roughly
based on the file you posted):
Items = Item+ EOF
Item = Name '=' ContentBlock
ContentBlock = '{' Content* '}'
Content = (AttributeOrIte m
| UnamedItem
| Nil
| SubItem) ','
AttributeOrItem = Name '=' (Literal | ContentBlock)
UnamedItem = ContentBlock
Nil = NIL
SubItem = Literal
Name = Identifier
| ('[' Literal ']')
Where Identifier, Literal, NIL and EOF are tokens (as well as the
symbols "{", "}", "[", "]", "," and "="). In the pseudo-grammar above,
the '+' symbol means that the preceding item may exist one or more
times; the '*' means that the preceding item is on optional sequence;
and the '|' symbol indicates alternatives.
While parsing this grammar, you could map each construct to a XML-like
element:
Item -<item name="name">... </item>
Attribute -<attribute name="name" value="value" />
Nil -<item name="" />
UnamedItem -<item name=""... </item>
SubItem -<subitem value="value" />
To build a parser from this grammar, you'd first need a Lexer which
would return each different token on demand. This is somewhat tricky,
and would be a whole lot of fun in itself (you see that my concept of
fun leaves a lot to be desired)...
Then, for each non-terminal in the grammar above (a non-terminal is
one of the names to the left of the equal sign: Items, Item,
ContentBlock, etc) you would create a parsing method responsible for
"recognizin g" the pattern to the right of the equal sign and to emit
the text of your XML structure as you go...
This kind of parser is called Recursive Descent, and is easy to build
by hand. For example, this could be the interface to your parser:
Function ParseItems As Boolean
Function ParseItem As Boolean
Function ParseContentBlo ck As Boolean
Function ParseContent As Boolean
Function ParseAttributeO rItem As Boolean
Function ParseUnamedItem As Boolean
Function ParseNil As Boolean
Function ParseSubItem As Boolean
Function ParseName(ByRef Name As String) As Boolean
To give you a glympse of the kind of code involved, see how the
ParseContentBlo ck method could be written:
<aircode>
Function ParseContentBlo ck As Boolean
'Parses a '{', followed by an optional sequence
'of Content, followed by an '}'
If Not MatchToken("{") Then Return False
Do While ParseContent
Loop
RequireToken("} ")
Return True
End Function
</aircode>
The interesting thing is that only at specific places you'll need to
be concerned with actually emiting the data to your XML structure.
Say, for instance, in ParseAttributeO rItem, which will, as its name
says, recognize an attribute or an Item and generate the according
translation:
<aircode>
Function ParseAttributeO rItem As Boolean
'Will parse a Name followed by an '='
'followed by either a Literal or a ContentBlock
Dim Name As String
If Not ParseName(Name) Then Return False
RequireToken("= ")
If CurrentToken.Is Literal Then
'Creates an attribute
Emit("<attribut e name={0} value={1} />", _
Quoted(Name), Quoted(CurrentT oken.Value))
NextToken
ElseIf CurrentToken.Is OpenBrace Then
'ContentBlock starts with an open brace
'Create a new item
Emit("<item name={0}>", Quoted(Name))
ParseContentBlo ck
Emit("</item>")
Else 'Error
Throw new ParseError("Exp ected literal or '{'")
End If
Return True
End Function
</aircode>
As you can see, it's an almost literal translation of the production
content (a production is the set of rules describing a given non-
terminal) into code.
The thing with Recursive Descent Parsers is that they are, as the name
suggests, recursive. You saw, for example, that ParseAttributeO rItem
will call ParseContentBlo ck when it sees a '{' following the '=' char.
But if you look at the production for ContentBlock, you'll see that it
calls Content, which may call AttributeOrItem recursivelly. This is
the thing that allows the parser to keep track of the different
structures generated by the parsing process, and what differentiates
parsers from, say, Regular Expressions (which usually lack this
recursion power):
<aircode>
Function ParseContent As Boolean
'will parse an AttributeOrItem or an
'UnamedItem or a Nil or a SubItem,
'followed by a ','
Dimk Ok As Boolean
If CurrentToken.Is IdentifierOrOpe nBracket Then
Ok = ParseAttributeO rItem
ElseIf CurrentToken.Is OpenBrace Then
Ok = ParseUnamedItem
ElseIf CurrentToken.Is Nil Then
Ok = ParseNil
ElseIf CurrentToken.Is Literal Then
Ok = ParseSubItem
End If
If Ok Then RequireToken(", ")
Return Ok
End Function
</aircode>
Hope this gives you some ideas.
Regards,
Branco.
I want to make a program that reads the content of a LUA array save file..
More precicely a save file from a World of Warcraft plugin called
CharacterProfil er, which dumps alot of information about your characters
into that save file.
Anyhow, I want to extract a couple of lines of it and save it into a
database and I need help on figuring out a good way of reading the file.
The problem is that the file can look pretty different depending on the
proffessions and class of the characters etc. etc..
Is it possible to get an xml parser to read it or something?
I would appriciate all angles of approaching this..
Right now im thinking about just starting with getting rid of the stuff I
dont want in the file.. Like I only want the characters from a certain
server.. Trollbane. And I only want information about characters in the
guild Sacred Order Of Azeroth...
So if I just catch the part in the file where it starts with ["Trollbane"] =
{ and counts the '{' and '}' to get the one that ends the trollbane server..
Anyway, Im attaching the whole save file so that you can take a look at it..
Hope someone can give me some ideas.
EDIT: Aww, it was to big to send with..Im uploading it to a webspacehttp://www1.shellkonto .se/artix/CharacterProfil er.lua
