If you are using ICU or Iconv directly, you wouldn't use those classes at
all. The XML parser provides a simple abstraction around transcoders, since
it supports installable transcoding systems. So, if you can live within
those simple services provided, you don't have to know which one you are
using. Basically, you call the XMLPlatformUtils::fgTransService object and
ask it to create a transcoder for you. It will create one, using whatever
transcoding service is plugged into the parser on that platform, and return
it to you via the base XMLTranscoder interface.
This allows you a lot of portability, however, given that the transcoding
services can be quite different in their capabilities and the names they use
for encodings and so forth on various platforms, you might still get a
suprise or two.
We hide the actual Unicode format that the underlying transcoder uses, so
that you always work in terms of XMLCh (which is now UTF-16.) However, that
might involve a double transcode if the underlying transcoding system
doesn't use UTF-16 as its native format. If you don't feel like you can
handle that possible double effort, performance-wise, you might have to step
out on your own and use the native services yourself. For instance, if your
file is Shift_JIS and your local transcoding service uses UCS-4 as its
format, then the parser would call the transcoding service, which would
transcode Shift_JIS into UCS-4, then our wrapper would then do a trivial
transcode of that back into UTF-16 to give back to you as XMLCh. When you
get that XMLCh from us, and transcode it to say some other Japanese
encoding, you'd hand us the XMLCh, which we'd have to do a trivial transcode
of to UCS-4, which is then handed to the transcoding service to transcode
into the target encoding.
I'm not sure how many platforms that worst case scenario happens on, but it
could happen. Linux would probably be one, since it has a 32 bit wchar_t and
so its Iconv probably uses UCS-4 format.
If you use ICU as your underlying transcoding service on all your platforms,
then you are ok since you get consistent encoding namings, consistent
results (hopefully), and it uses UTF-16 as its native format.
--------------
Dean Roddey
Software Geek Extraordinaire
Portal, Inc
[EMAIL PROTECTED]
-----Original Message-----
From: Mark A Russell [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 03, 2001 2:15 PM
To: Xerces C++ Mailing List
Subject: Using transcoder class?
This question is directly related to my previous one about "XMLCh & wchar_t
conversion on multiple platforms"
My question is, how do you use the ICUTranscoder and IconvTranscoder? I
can't seem to figure out how to get them to work. So lots of questions
below related to the specific transcoders and their usage.
IconvTranscoder: (Is this even valid? Or should it really be
IConv400Transcoder?)
1. Constructor takes an XMLCh that's suppose to have the encoding
name.
How do I determine what encoding name to use?
2. Constructor also takes an int that's suppose to be blocksize. Is
this
the sizeof(wchar_t)? If not what should it be for the different encodings?
3. Both the transcodeOne and transcodeXML functions take an
XMLByte*.
Looking through the headers it looks like an XMLByte is defined as a char.
How can I give these functions a wchar_t and get a XMLCh back without
loosing the Unicode first by converting to char*? I'm probably just not
making a connection on this one.
4. IconvTranscoder doesn't define the transcodeTo & transcodeFrom
that are
found in its base class so this doesn't seem like a valid transcoder.
Should it be the I really should be using Iconv400Transcoder (or 390)?
5. How do you convert from an XMLCh back to wchar_t with the
transcoders?
(I know its the transcodeFrom function, but that only gives an XMLByte.) How
do you get from the XMLByte to the wchar_t that you really want?
ICUTranscoder:
1. Same question as IconvTranscoder #1
2. What is the UConverter and where is it defined? (Tried looking
and cant
find its definition)
3. Same question as IconvTranscoder #2
4. Same question as IconvTranscoder #3
5. Same question as IconvTranscoder #5
In all likelihood I will be using the IconvTranscoder assuming that is the
way this should be done.
Help greatly appreciated. Thank You,
Mark A Russell
NextGen Software Engineer
CSG Systems, Inc.
E-Mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
