From: Igor Zlatkovic (igor@stud.fh-frankfurt.de)
Date: Fri Feb 02 2001 - 07:28:09 EST
Hello.
Conversions under other libraries, such as Microsoft NLS implementation
found in Win32 is about the same. A conversion between any two encoding
standards requires you to go through wide charracters. For example, there is
no direct conversion between UTF-8 and SHIFT-JIS, you have to convert UTF-8
to wide char, then convert the resulting wide char to SHIFT-JIS. This is not
the downside of ICU, it is the common case everywhere. It can never be
different, for writing conversions from any to any encoding would be a
nightmare in its own right.
I haven't tried ICU seriously yet. I shall do that before I make any further
statements about it.
Igor
----- Original Message -----
From: "Dave Madole" <dmadole@cddb.com>
>
> I use the ICU (International Components for Unicode) libraries from IBM
>
> http://oss.software.ibm.com/icu/
>
> to encode element content. One must convert the element content from
utf-8
> to utf-16(native byte order) then convert from utf-16 to whatever
> character encoding (sjis, big-5) one wants, then base64 encode the
> content. This works and satisfies the w3c requirement that the XML itself
> must be utf-8 or utf-16. I found that ICU more completely addressed my
> needs than iconv. The only downside is that you must convert whatever
your
> source encoding is to native byte order utf-16 before converting it to
your
> destination encoding. The API seems to be modeled on iconv and is very
> easy to use.
>
> This obviates messing with libxml, although it becomes a bit of a memory
> management nightmare.
>
> Dave
>
---- Message from the list xml@rpmfind.net Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@rpmfind.net
This archive was generated by hypermail 2b29 : Fri Feb 02 2001 - 10:51:20 EST