[xmlsec] non us-ascii filenames in user locale

[Igor Zlatkovic]

On 22.06.2004 17:47, Aleksey Sanin wrote:

> 
>> Agreed, application must deal with locales.
> 
> Good :)
> 
>> Current xmlsec don't allow me to replace file IO from an application.
> 
> Of course, it does :)
>     http://xmlsoft.org/xmlio.html
>     http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>     
> If I understand you correctly, the problem is that you have a UCS2
> (or UCS4) unicode filename that has all these zeros in the middle.
> Now you want to call LibXML2/xmlsec IO functions and you are in trouble
> because these functions need zero-terminated ASCII strings and
> later they use fopen() function that needs the ASCII string in the
> "current locale" (which might not be the locale that was used to
> create the filename).
> 
> I guess, the only option I have for you is to do the following:
> 1) Convert the UCS filename into UTF8 on application level.
> 2) Replace the libxml2/xmlsec IO "file:" protocol handlers with custom
> ones that convert filenames back from UTF8 to UCS2/4 and then use
> "_wfopen" function instead of "fopen".
> 
> Igor, it might make sense to do the item 2) on Windows platform
> all the time. I.e. LibXML2 assumes that the filename is in UTF8, then
> it converts it to unicode and uses _wfopen function instead of fopen
> (again, this is *only* for windows). This approach solves all the
> localization problems with "current locale" required for fopen.

Okay, but according to MSDN that will restrict libxml source to NT-based 
Windows. I have no problem with this restriction in binaries, but the 
source...

> BTW, if you haven't seen this paper, I strongly recommend it as a brief
> introduction to Unicode mess:
>     http://www.joelonsoftware.com/articles/Unicode.html

Thanks, I allready had a less brief introduction to the Unicode mess:
    http://www.unicode.org/versions/Unicode4.0.1/

Ciao,
Igor