|
HTML::TreeBuilder - Parser that builds a HTML syntax tree |
HTML::TreeBuilder - Parser that builds a HTML syntax tree
foreach my $file_name (@ARGV) {
my $tree = HTML::TreeBuilder->new; # empty tree
$tree->parse_file($file_name);
print "Hey, here's a dump of the parse tree of $file_name:\n";
$tree->dump; # a method we inherit from HTML::Element
print "And here it is, bizarrely rerendered as HTML:\n",
$tree->as_HTML, "\n";
# Now that we're done with it, we must destroy it.
$tree = $tree->delete;
}
(This class is part of the HTML::Tree dist.)
This class is for HTML syntax trees that get built out of HTML source. The way to use it is to:
1. start a new (empty) HTML::TreeBuilder object,
2. then use one of the methods from HTML::Parser (presumably with
$tree->parse_file($filename) for files, or with
$tree->parse($document_content) and $tree->eof if you've got
the content in a string) to parse the HTML
document into the tree $tree.
(You can combine steps 1 and 2 with the ``new_from_file'' or ``new_from_content'' methods.)
2b. call $root->elementify() if you want.
3. do whatever you need to do with the syntax tree, presumably involving traversing it looking for some bit of information in it,
4. and finally, when you're done with the tree, call $tree->delete() to
erase the contents of the tree from memory. This kind of thing
usually isn't necessary with most Perl objects, but it's necessary for
TreeBuilder objects. See HTML::Element for a more verbose
explanation of why this is the case.
Objects of this class inherit the methods of both HTML::Parser and HTML::Element. The methods inherited from HTML::Parser are used for building the HTML tree, and the methods inherited from HTML::Element are what you use to scrutinize the tree. Besides this (HTML::TreeBuilder) documentation, you must also carefully read the HTML::Element documentation, and also skim the HTML::Parser documentation -- probably only its parse and parse_file methods are of interest.
Most of the following methods native to HTML::TreeBuilder control how
parsing takes place; they should be set before you try parsing into
the given object. You can set the attributes by passing a TRUE or
FALSE value as argument. E.g., $root->implicit_tags returns the current
setting for the implicit_tags option, $root->implicit_tags(1) turns that
option on, and $root->implicit_tags(0) turns it off.
new_from_file(...)parse_file(...) on
it. Returns the new object. Note that this provides no way of
setting any parse options like store_comments (for that, call new, and
then set options, before calling parse_file). See the notes (below)
on parameters to parse_file.
new_from_content(...)new_from_content($content)
new()parse_file(...)parse(...)eof()eof()
once you've finished feeding all the chunks to parse(...), and
before you actually start doing anything else with the tree in $root.
delete()elementify()For most purposes, this is unnecessary, but if you call this after
(after!!)
you've finished building a tree, then it keeps you from accidentally
trying to call anything but HTML::Element methods on it. (I.e., if
you accidentally call $root->parse_file(...) on the
already-complete and elementified tree, then instead of charging ahead
and wreaking havoc, it'll throw a fatal error -- since $root is
now an object just of class HTML::Element which has no parse_file
method.
Note that elementify currently deletes all the private attributes of $root except for ``_tag'', ``_parent'', ``_content'', ``_pos'', and ``_implicit''. If anyone requests that I change this to leave in yet more private attributes, I might do so, in future versions.
guts()guts()<li>I like pie!
Then you would get that with @nodes = $root->guts();.
It so happens that in this case, @notes will contain just one
element object, representing the ``li'' node (with ``I like pie!'' being
its text child node). However, consider if you were parsing this:
<hr>Hooboy!<hr>
In that case, $root->guts() would return three items:
an element object for the first ``hr'', a text string ``Hooboy!'', and
another ``hr'' element object.
For cases where you want definitely one element (so you can treat it as
a ``document fragment'', roughly speaking), call guts() in scalar
context, as in $parent_for_nodes = $root->guts(). That works like
guts() in list context; in fact, guts() in list context would
have returned exactly one value, and if it would have been an object (as
opposed to a text string), then that's what guts in scalar context
will return. Otherwise, if guts() in list context would have returned
no values at all, then guts() in scalar context returns undef. In
all other cases, guts() in scalar context returns an implicit 'div'
element node, with children consisting of whatever nodes guts()
in list context would have returned. Note that that may detach those
nodes from $root's tree.
disembowel()disembowel()disembowel() method works just like the guts() method, except
that disembowel definitively destroys the tree above the nodes that
are returned. Usually when you want the guts from a tree, you're just
going to toss out the rest of the tree anyway, so this saves you the
bother. (Remember, ``disembowel'' means ``remove the guts from''.)
implicit_tags(value)Implicit elements have the implicit() attribute set.
implicit_body_p_tag(value)ignore_unknown(value)ignore_text(value)ignore_ignorable_whitespace(value)no_space_compacting(value)Setting no_space_compacting to 1 might be useful if you want to read in a tree just to make some minor changes to it before writing it back out.
This method is experimental. If you use it, be sure to report any problems you might have with it.
p_strict(value)For example, when going thru this snippet of code,
<p>stuff <ul>
TreeBuilder will normally (with p_strict false) put the ``ul'' element
under the ``p'' element. However, with p_strict set to true, it will
close the ``p'' first.
In theory, there should be strictness options like this for other/all elements besides just ``p''; but I treat this as a specal case simply because of the fact that ``p'' occurs so frequently and its end-tag is omitted so often; and also because application of strictness rules at parse-time across all elements often makes tiny errors in HTML coding produce drastically bad parse-trees, in my experience.
If you find that you wish you had an option like this to enforce content-models on all elements, then I suggest that what you want is content-model checking as a stage after TreeBuilder has finished parsing.
store_comments(value)$root. Currently, this is off by default.
store_declarations(value)$root. Currently,
this is off by default.
It is somewhat of a known bug (to be fixed one of these days, if anyone needs it?) that declarations in the preamble (before the ``html'' start-tag) end up actually under the ``html'' element.
store_pis(value)$root -- assuming a
recent version of HTML::Parser (old versions won't parse PIs
correctly). Currently, this is off (false) by default.
It is somewhat of a known bug (to be fixed one of these days, if anyone needs it?) that PIs in the preamble (before the ``html'' start-tag) end up actually under the ``html'' element.
warn(value)warn function.
This is off (false) by default.
HTML is rather harder to parse than people who write it generally suspect.
Here's the problem: HTML is a kind of SGML that permits ``minimization'' and ``implication''. In short, this means that you don't have to close every tag you open (because the opening of a subsequent tag may implicitly close it), and if you use a tag that can't occur in the context you seem to using it in, under certain conditions the parser will be able to realize you mean to leave the current context and enter the new one, that being the only one that your code could correctly be interpreted in.
Now, this would all work flawlessly and unproblematically if: 1) all the rules that both prescribe and describe HTML were (and had been) clearly set out, and 2) everyone was aware of these rules and wrote their code in compliance to them.
However, it didn't happen that way, and so most HTML pages are difficult if not impossible to correctly parse with nearly any set of straightforward SGML rules. That's why the internals of HTML::TreeBuilder consist of lots and lots of special cases -- instead of being just a generic SGML parser with HTML DTD rules plugged in.
The techniques that HTML::TreeBuilder uses to perform what I consider very robust parses on everyday code are not things that can work only in Perl. To date, the algorithms at the center of HTML::TreeBuilder have been implemented only in Perl, as far as I know; and I don't foresee getting around to implementing them in any other language any time soon.
If, however, anyone is looking for a semester project for an applied programming class (or if they merely enjoy extra-curricular masochism), they might do well to see about choosing as a topic the implementation/adaptation of these routines to any other interesting programming language that you feel currently suffers from a lack of robust HTML-parsing. I welcome correspondence on this subject, and point out that one can learn a great deal about languages by trying to translate between them, and then comparing the result.
The HTML::TreeBuilder source may seem long and complex, but it is rather well commented, and symbol names are generally self-explanatory. (You are encouraged to read the Mozilla HTML parser source for comparison.) Some of the complexity comes from little-used features, and some of it comes from having the HTML tokenizer (HTML::Parser) being a separate module, requiring somewhat of a different interface than you'd find in a combined tokenizer and tree-builder. But most of the length of the source comes from the fact that it's essentially a long list of special cases, with lots and lots of sanity-checking, and sanity-recovery -- because, as Roseanne Rosannadanna once said, ``it's always something''.
Users looking to compare several HTML parsers should look at the
source for Raggett's Tidy
(<http://www.w3.org/People/Raggett/tidy/>),
Mozilla
(<http://www.mozilla.org/>),
and possibly root around the browsers section of Yahoo
to find the various open-source ones
(<http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Browsers/>).
* Framesets seem to work correctly now. Email me if you get a strange parse from a document with framesets.
* Really bad HTML code will, often as not, make for a somewhat objectionable parse tree. Regrettable, but unavoidably true.
* If you're running with implicit_tags off (God help you!), consider that $tree->content_list probably contains the tree or grove from the parse, and not $tree itself (which will, oddly enough, be an implicit 'html' element). This seems counter-intuitive and problematic; but seeing as how almost no HTML ever parses correctly with implicit_tags off, this interface oddity seems the least of your problems.
When a document parses in a way different from how you think it
should, I ask that you report this to me as a bug. The first thing
you should do is copy the document, trim out as much of it as you can
while still producing the bug in question, and then email me that
mini-document and the code you're using to parse it, at sburke@cpan.org.
Include a note as to how it
parses (presumably including its $tree->dump output), and then a
careful and clear explanation of where you think the parser is
going astray, and how you would prefer that it work instead.
the HTML::Tree manpage; the HTML::Parser manpage, the HTML::Element manpage, the HTML::Tagset manpage
Copyright 1995-1998 Gisle Aas; copyright 1999-2002 Sean M. Burke. This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
This program is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose.
Original author Gisle Aas <gisle@aas.no>; current maintainer Sean M. Burke, <sburke@cpan.org>
|
HTML::TreeBuilder - Parser that builds a HTML syntax tree |