[xmlsec] non us-ascii filenames in user locale
igor at zlatkovic.com
Tue Jun 22 11:53:35 PDT 2004
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 :)
> 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
> BTW, if you haven't seen this paper, I strongly recommend it as a brief
> introduction to Unicode mess:
Thanks, I allready had a less brief introduction to the Unicode mess:
More information about the xmlsec