Hello,

I have a question about how to work with this library when dealing with 
extended characters.

I recently upgraded from old versions of libxml and libxmlsec.
libxml 2.6.9 --> 2.7.7
libxmlsec 1.2.5 --> 1.2.16

We are using a fairly boilerplate copy of the recipe for encrypting the xml and 
then decrypting it on the other end of the communication line.  The old version 
of these libraries would refrain from converting the XML encoding of 
characters.  The new version of these libraries seems to be translating these 
encodings back to their wide character format, and this then crashes the system.

What I would like to do, is figure out which API flag can be used to retain the 
encoding.  Possibly I also need to switch to wchar buffers or something else, 
because calling free on the regular buffer seems to corrupt memory.

For instance, if a section of the XML has this:
        <RoleID>รก</RoleID>

before going into xmlsec it gets translated into this by a perl function:
        <RoleID>&#xe1;</RoleID>

At the top of the xml block, I tried specifying an encoding of "US-ASCII" and I 
was hoping this would keep the libraries from converting it back.  I need the 
encoding to stay in place because it needs to be converted only at the final 
destination code.  I tried also setting "US-ASCII" as the encoding value on the 
call to xmlSecTmplEncDataCreate, but no matter what value I set on that field, 
even an invalid one, it doesn't seem to change the behavior.

I'm hoping someone on this list can help me with a clue to point me in the 
right direction.

It would also be very good to get a pointer to the documentation that specifies 
how to set a value for the xmlChar options, and what options are accepted.  I 
searched through lots of documentation at:
http://www.aleksey.com/xmlsec/api/

and found no reference on how to configure those options, just that they 
existed and expected some value in an xmlChar.

Thanks!
Russ.


==============================
Russell Beall
Systems Programmer IV
Enterprise Identity Management
University of Southern California
[email protected]<mailto:[email protected]>
==============================


_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec

Reply via email to