| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" |
| "http://www.w3.org/TR/REC-html40/loose.dtd"> |
| <html> |
| <head> |
| <title>Libxml Input/Output handling</title> |
| <meta name="GENERATOR" content="amaya V3.2.1"> |
| <meta http-equiv="Content-Type" content="text/html"> |
| </head> |
| |
| <body bgcolor="#ffffff"> |
| <h1 align="center">Libxml Input/Output handling</h1> |
| |
| <p>Location: <a |
| href="http://xmlsoft.org/xmlio.html">http://xmlsoft.org/xmlio.html</a></p> |
| |
| <p>Libxml home page: <a href="http://xmlsoft.org/">http://xmlsoft.org/</a></p> |
| |
| <p>Mailing-list archive: <a |
| href="http://xmlsoft.org/messages/">http://xmlsoft.org/messages/</a></p> |
| |
| <p>Version: $Revision: 1.4 $</p> |
| |
| <p>Table of Content:</p> |
| <ol> |
| <li><a href="#General">General overview</a></li> |
| <li><a href="#basic">The basic buffer type</a></li> |
| <li><a href="#Input">Input I/O handlers</a></li> |
| <li><a href="#Output">Output I/O handlers</a></li> |
| <li><a href="#entities">The entities loader</a></li> |
| <li><a href="#Example">Example of customized I/O</a></li> |
| </ol> |
| |
| <h2><a name="General">General overview</a></h2> |
| |
| <p>The module <code><a |
| href="http://xmlsoft.org/html/libxml-xmlio.html">xmlIO.h</a></code> |
| provides the interfaces to the libxml I/O system. This consists of 4 main |
| parts:</p> |
| <ul> |
| <li>Entities loader, this is a routine which tries to fetch the entities |
| (files) based on their PUBLIC and SYSTEM identifiers. The default loader |
| don't look at the public identifier since libxml do not maintain a |
| catalog. You can redefine you own entity loader by using |
| <code>xmlGetExternalEntityLoader()</code> and |
| <code>xmlSetExternalEntityLoader()</code>. <a href="#entities">Check the |
| example</a>.</li> |
| <li>Input I/O buffers which are a commodity structure used by the parser(s) |
| input layer to handle fetching the informations to feed the parser. This |
| provides buffering and is also a placeholder where the encoding convertors |
| to UTF8 are piggy-backed.</li> |
| <li>Output I/O buffers are similar to the Input ones and fulfill similar |
| task but when generating a serialization from a tree.</li> |
| <li>A mechanism to register sets of I/O callbacks and associate them with |
| specific naming schemes like the protocol part of the URIs. |
| <p>This affect the default I/O operations and allows to use specific I/O |
| handlers for certain names.</p> |
| </li> |
| </ul> |
| |
| <p>The general mechanism used when loading http://rpmfind.net/xml.html for |
| example in the HTML parser is the following:</p> |
| <ol> |
| <li>The default entity loader calls <code>xmlNewInputFromFile()</code> with |
| the parsing context and the URI string.</li> |
| <li>the URI string is checked against the existing registered handlers using |
| their match() callback function, if the HTTP module was compiled in, it is |
| registered and its match() function will succeeds</li> |
| <li>the open() function of the handler is called and if successful will |
| return an I/O Input buffer</li> |
| <li>the parser will the start reading from this buffer and progressively |
| fetch information from the resource, calling the read() function of the |
| handler until the resource is exhausted</li> |
| <li>if an encoding change is detected it will be installed on the input |
| buffer, providing buffering and efficient use of the conversion |
| routines</li> |
| <li>once the parser has finished, the close() function of the handler is |
| called once and the Input buffer and associed resources are |
| deallocated.</li> |
| </ol> |
| |
| <p>The user defined callbacks are checked first to allow overriding of the |
| default libxml I/O routines.</p> |
| |
| <h2><a name="basic">The basic buffer type</a></h2> |
| |
| <p>All the buffer manipulation handling is done using the |
| <code>xmlBuffer</code> type define in <code><a |
| href="http://xmlsoft.org/html/libxml-tree.html">tree.h</a> </code>which is |
| a resizable memory buffer. The buffer allocation strategy can be selected to |
| be either best-fit or use an exponential doubling one (CPU vs. memory use |
| tradeoff). The values are <code>XML_BUFFER_ALLOC_EXACT</code> and |
| <code>XML_BUFFER_ALLOC_DOUBLEIT</code>, and can be set individually or on a |
| system wide basis using <code>xmlBufferSetAllocationScheme()</code>. A number |
| of functions allows to manipulate buffers with names starting with the |
| <code>xmlBuffer...</code> prefix.</p> |
| |
| <h2><a name="Input">Input I/O handlers</a></h2> |
| |
| <p>An Input I/O handler is a simple structure |
| <code>xmlParserInputBuffer</code> containing a context associated to the |
| resource (file descriptor, or pointer to a protocol handler), the read() and |
| close() callbacks to use and an xmlBuffer. And extra xmlBuffer and a charset |
| encoding handler are also present to support charset conversion when |
| needed.</p> |
| |
| <h2><a name="Output">Output I/O handlers</a></h2> |
| |
| <p>An Output handler <code>xmlOutputBuffer</code> is completely similar to an |
| Input one except the callbacks are write() and close().</p> |
| |
| <h2><a name="entities">The entities loader</a></h2> |
| |
| <p>The entity loader resolves requests for new entities and create inputs for |
| the parser. Creating an input from a filename or an URI string is done through |
| the xmlNewInputFromFile() routine. The default entity loader do not handle |
| the PUBLIC identifier associated with an entity (if any). So it just calls |
| xmlNewInputFromFile() with the SYSTEM identifier (which is mandatory in |
| XML).</p> |
| |
| <p>If you want to hook up a catalog mechanism then you simply need to override |
| the default entity loader, here is an example:</p> |
| <pre>#include <libxml/xmlIO.h> |
| |
| xmlExternalEntityLoader defaultLoader = NULL; |
| |
| xmlParserInputPtr |
| xmlMyExternalEntityLoader(const char *URL, const char *ID, |
| xmlParserCtxtPtr ctxt) { |
| xmlParserInputPtr ret; |
| const char *fileID = NULL; |
| /* lookup for the fileID depending on ID */ |
| |
| ret = xmlNewInputFromFile(ctxt, fileID); |
| if (ret != NULL) |
| return(ret); |
| if (defaultLoader != NULL) |
| ret = defaultLoader(URL, ID, ctxt); |
| return(ret); |
| } |
| |
| int main(..) { |
| ... |
| |
| /* |
| * Install our own entity loader |
| */ |
| defaultLoader = xmlGetExternalEntityLoader(); |
| xmlSetExternalEntityLoader(xmlMyExternalEntityLoader); |
| |
| ... |
| }</pre> |
| |
| <h2><a name="Example">Example of customized I/O</a></h2> |
| |
| <p>This example come from <a href="http://xmlsoft.org/messages/0708.html">a |
| real use case</a>, xmlDocDump() closes the FILE * passed by the application |
| and this was a problem. The <a |
| href="http://xmlsoft.org/messages/0711.html">solution</a> was to redefine a |
| new output handler with the closing call deactivated:</p> |
| <ol> |
| <li>First define a new I/O ouput allocator where the output don't close the |
| file: |
| <pre>xmlOutputBufferPtr |
| xmlOutputBufferCreateOwn(FILE *file, xmlCharEncodingHandlerPtr encoder) { |
| xmlOutputBufferPtr ret; |
| |
| if (xmlOutputCallbackInitialized == 0) |
| xmlRegisterDefaultOutputCallbacks(); |
| |
| if (file == NULL) return(NULL); |
| ret = xmlAllocOutputBuffer(encoder); |
| if (ret != NULL) { |
| ret->context = file; |
| ret->writecallback = xmlFileWrite; |
| ret->closecallback = NULL; /* No close callback */ |
| } |
| return(ret); <br> |
| |
| |
| } </pre> |
| </li> |
| <li>And then use it to save the document: |
| <pre>FILE *f; |
| xmlOutputBufferPtr output; |
| xmlDocPtr doc; |
| int res; |
| |
| f = ... |
| doc = .... |
| |
| output = xmlOutputBufferCreateOwn(f, NULL); |
| res = xmlSaveFileTo(output, doc, NULL); |
| </pre> |
| </li> |
| </ol> |
| |
| <p><a href="mailto:daniel@veillard.com">Daniel Veillard</a></p> |
| |
| <p>$Id: xmlio.html,v 1.4 2001/01/29 08:22:12 veillard Exp $</p> |
| </body> |
| </html> |