[xml] encoding problems using xmlSaveFormatFileTo()


me again... 8)
While testing an application to write XML docs from scratch using
i've some troubles regarding the character encoding support of libxml.
I've read the documentation to that subject and the reference to the
that i use and thought i got it so far, since i'm currently working with
encoding (that is supported by default).
But now i'm unshure if i got something wrong (it wouldn't be the first
time... 8).

That's what i'm doing:

/* Build a new document */
docPtr = xmlNewDoc(XML_DEFAULT_VERSION);

/* encode entities for new node content */
char* contentBuff = " Some content < & > aou äöü AOU ÄÖÜ ß üöä ";
tmpBuff = xmlEncodeEntitiesReentrant(docPtr, BAD_CAST contentBuff);

/* Add node */
xmlNewChild(docPtr, NULL, "aNode", tmpBuff);

/*** create output buffer ***/
outputBufferPtr = xmlOutputBufferCreateIO(writeCallback,
closeCallback, (void*)&fileDesc, NULL);

/* save doc to disk */
xmlSaveFormatFileTo(outputBufferPtr, docPtr, "iso-8859-1", 0);

That's what i get:

<?xml version="1.0" encoding="iso-8859-1"?>
<aNode>Some content &lt; &amp; &gt; aou 䶼 AOU Ä-Ü ß Ã¼öä </aNode>

So, some of the german umlaute are encoded correctly, some not (but
and some as well as (!).
Debugging shows that xmlEncodeEntitiesReentrant() correctly replaces the
german umlaute with their character references, so i've thought about the
xmlCharEncodingHandlerPtr parameter in xmlOutputBufferCreateIO(),
but the library reference manual keeps silent about it...
I've hoped that passing NULL to xmlOutputBufferCreateIO() would invoke the
libxml default encoding handler!? Is this the mistake or something else is
going wrong?

Thanx for your effort & Ciao, Markus

Mit freundlichen Gruessen - Kind regards
Markus Henke

________________________Addressed by:________________________
 ORDAT GmbH & Co. KG  -  Serversystems / eCom 
 Dipl.-Inf. (FH) Markus Henke  Fon: +49 (641) 7941-0
 Rathenaustr. 1                Fax: +49 (641) 7941-132
 35394 Gießen                  mailto:markus henke ordat com
 See:                          http://www.ordat.com
              ...this behavior is by design...
 <<Markus Henke.vcf>> 

Attachment: Markus Henke.vcf
Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]