Страницы справочника OS X

Эта страница руководства для  версии 10.9 Mac OS X

Читать страницы руководства

HTML::TreeBuilder(3)                 User Contributed Perl Documentation                HTML::TreeBuilder(3)



NAME
       HTML::TreeBuilder - Parser that builds a HTML syntax tree

SYNOPSIS
         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;
         }

DESCRIPTION
       (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.

METHODS AND ATTRIBUTES
       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.

       $root = HTML::TreeBuilder->new_from_file(...)
           This "shortcut" constructor merely combines constructing a new object (with the "new" method,
           below), and calling $new->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.

       $root = HTML::TreeBuilder->new_from_content(...)
           This "shortcut" constructor merely combines constructing a new object (with the "new" method,
           below), and calling for(...){$new->parse($_)} and $new->eof 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).  Example usages:
           HTML::TreeBuilder->new_from_content(@lines), or HTML::TreeBuilder->new_from_content($content)

       $root = HTML::TreeBuilder->new()
           This creates a new HTML::TreeBuilder object.  This method takes no attributes.

       $root->parse_file(...)
           [An important method inherited from HTML::Parser, which see.  Current versions of HTML::Parser
           can take a filespec, or a filehandle object, like *FOO, or some object from class IO::Handle,
           IO::File, IO::Socket) or the like.  I think you should check that a given file exists before
           calling $root->parse_file($filespec).]

       $root->parse(...)
           [A important method inherited from HTML::Parser, which see.  See the note below for
           $root->eof().]

       $root->eof()
           This signals that you're finished parsing content into this tree; this runs various kinds of
           crucial cleanup on the tree.  This is called for you when you call $root->parse_file(...), but
           not when you call $root->parse(...).  So if you call $root->parse(...), then you must call
           $root->eof() once you've finished feeding all the chunks to parse(...), and before you actually
           start doing anything else with the tree in $root.

       "$root->parse_content(...)"
           Basically a happly alias for "$root->parse(...); $root->eof".  Takes the exact same arguments as
           "$root->parse()".

       $root->delete()
           [An important method inherited from HTML::Element, which see.]

       $root->elementify()
           This changes the class of the object in $root from HTML::TreeBuilder to the class used for all
           the rest of the elements in that tree (generally HTML::Element).  Returns $root.

           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.

       @nodes = $root->guts()
       $parent_for_nodes = $root->guts()
           In list context (as in the first case), this method returns the topmost non-implicit nodes in a
           tree.  This is useful when you're parsing HTML code that you know doesn't expect an HTML
           document, but instead just a fragment of an HTML document.  For example, if you wanted the parse
           tree for a file consisting of just this:

             <li>I like pie!

           Then you would get that with "@nodes = $root->guts();".  It so happens that in this case, @nodes
           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.

       @nodes = $root->disembowel()
       $parent_for_nodes = $root->disembowel()
           The "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".)

       $root->implicit_tags(value)
           Setting this attribute to true will instruct the parser to try to deduce implicit elements and
           implicit end tags.  If it is false you get a parse tree that just reflects the text as it stands,
           which is unlikely to be useful for anything but quick and dirty parsing.  (In fact, I'd be
           curious to hear from anyone who finds it useful to have implicit_tags set to false.)  Default is
           true.

           Implicit elements have the implicit() attribute set.

       $root->implicit_body_p_tag(value)
           This controls an aspect of implicit element behavior, if implicit_tags is on:  If a text element
           (PCDATA) or a phrasal element (such as "<em>") is to be inserted under "<body>", two things can
           happen: if implicit_body_p_tag is true, it's placed under a new, implicit "<p>" tag.  (Past DTDs
           suggested this was the only correct behavior, and this is how past versions of this module
           behaved.)  But if implicit_body_p_tag is false, nothing is implicated -- the PCDATA or phrasal
           element is simply placed under "<body>".  Default is false.

       $root->no_expand_entities(value)
           This attribute controls whether entities are decoded during the initial parse of the source.
           Enable this if you don't want entities decoded to their character value. e.g. '&amp;' is decoded
           to '&' by default, but will be unchanged if this is enabled.  Default is false (entities will be
           decoded.)

       $root->ignore_unknown(value)
           This attribute controls whether unknown tags should be represented as elements in the parse tree,
           or whether they should be ignored.  Default is true (to ignore unknown tags.)

       $root->ignore_text(value)
           Do not represent the text content of elements.  This saves space if all you want is to examine
           the structure of the document.  Default is false.

       $root->ignore_ignorable_whitespace(value)
           If set to true, TreeBuilder will try to avoid creating ignorable whitespace text nodes in the
           tree.  Default is true.  (In fact, I'd be interested in hearing if there's ever a case where you
           need this off, or where leaving it on leads to incorrect behavior.)

       $root->no_space_compacting(value)
           This determines whether TreeBuilder compacts all whitespace strings in the document (well,
           outside of PRE or TEXTAREA elements), or leaves them alone.  Normally (default, value of 0), each
           string of contiguous whitespace in the document is turned into a single space.  But that's not
           done if no_space_compacting is set to 1.

           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.

       $root->p_strict(value)
           If set to true (and it defaults to false), TreeBuilder will take a narrower than normal view of
           what can be under a "p" element; if it sees a non-phrasal element about to be inserted under a
           "p", it will close that "p".  Otherwise it will close p elements only for other "p"'s, headings,
           and "form" (although the latter may be removed in future versions).

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

       $root->store_comments(value)
           This determines whether TreeBuilder will normally store comments found while parsing content into
           $root.  Currently, this is off by default.

       $root->store_declarations(value)
           This determines whether TreeBuilder will normally store markup declarations found while parsing
           content into $root.  This is on by default.

       $root->store_pis(value)
           This determines whether TreeBuilder will normally store processing instructions found while
           parsing content into $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.

       $root->warn(value)
           This determines whether syntax errors during parsing should generate warnings, emitted via Perl's
           "warn" function.

           This is off (false) by default.

       $h->element_class
           This method returns the class which will be used for new elements.  It defaults to HTML::Element,
           but can be overridden by subclassing or esoteric means best left to those will will read the
           source and then not complain when those esoteric means change.  (Just subclass.)

       DEBUG
           Are we in Debug mode?

       comment
           Accept a "here's a comment" signal from HTML::Parser.

       declaration
           Accept a "here's a markup declaration" signal from HTML::Parser.

       done
           TODO: document

       end Either: Acccept an end-tag signal from HTML::Parser Or: Method for closing currently open
           elements in some fairly complex way, as used by other methods in this class.

           TODO: Why is this hidden?

       process
           Accept a "here's a PI" signal from HTML::Parser.

       start
           Accept a signal from HTML::Parser for start-tags.

           TODO: Why is this hidden?

       stunt
           TODO: document

       stunted
           TODO: document

       text
           Accept a "here's a text token" signal from HTML::Parser.

           TODO: Why is this hidden?

       tighten_up
           Legacy

           Redirects to HTML::Element:: delete_ignorable_whitespace

       warning
           Wrapper for CORE::warn

           TODO: why not just use carp?

HTML AND ITS DISCONTENTS
       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.

TRANSLATIONS?
       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/>").

BUGS
       * 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.

BUG REPORTS
       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, to the HTML::Tree bug queue at "bug-html-tree at rt.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.

SEE ALSO
       HTML::Tree; HTML::Parser, HTML::Element, HTML::Tagset

       HTML::DOMbo

COPYRIGHT
       Copyright 1995-1998 Gisle Aas, 1999-2004 Sean M. Burke, 2005 Andy Lester, 2006 Pete Krawczyk, 2010
       Jeff Fearn.

       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.

AUTHOR
       Current Author:      Jeff Fearn "<jfearn@cpan.org>".

       Original HTML-Tree author:      Gisle Aas.

       Former Authors:      Sean M. Burke.       Andy Lester.       Pete Krawczyk "<petek@cpan.org>".



perl v5.12.5                                     2013-08-25                             HTML::TreeBuilder(3)