Text 2683, 116 rader
Skriven 2005-02-23 14:58:30 av Ellen K (1:379/45)
   Kommentar till text 2681 av Adam Flinton (1:379/45)
Ärende: Re: ESB / XML / Unicode vs 8-bit characters ?
=====================================================
> From: Adam Flinton <adam_NO_@_SPAM_softfab.com>
> Ellen K. wrote:
>> On Mon, 21 Feb 2005 20:52:26 -0800, "Rich" <@> wrote in message
>> <421aba24@w3.nls.net>:
>> 
>> 
>>> I don't understand why oracle using UTF-8 wouldn't work and oracle using
> UTF-16 would.  That sounds like an oracle problem.
>> 
>> 
>> That would be no surprise to me, I am not an Oracle fan.  It drove me
>> nuts when I had to use it at Kaiser.  That parallel query processor they
>> are so proud of crashed if you looked at it cross-eyed.   My SQL Server
>> OLTP databases each have over 600 users now, one on a single-processor
>> box, the other on a dual-processor one, zero performance problems and
>> almost no tuning ever required.  If they were on Oracle we would need
>> more CPUs and a full-time DBA just to babysit it.   If I had a monster
>> multi-terabyte database that was too big for SQL Server I would go with
>> DB2 or possibly Terabyte.
>> 
>> 
>>> There are two XML issues I see.
>>> 
>>> One, and the only bug in what we have discussed, is that the encoding
> declared in the ?xml PI must match the actual encoding of the file.  You can
> use any encoding that is supported as long as your XML document is correctly
> encoded in whatever is declared.
>>> 
>>> The second issue is what encodings does your software support.  I believe
> all XML implementations to claim compliance must support UTF-8 and UTF-16.
> Most should support more.  I haven't tried Microsoft SQL Server but I would
> expect it to handle any of the encodings with support installed on that host
> machine.  Windows supports many encodings.  I just checked my machine and see
> more than 100 supported encodings.
>> 
>> 
>> Where do I look to see what encodings are supported?
>> 
>>> My suggestion is to stick with UTF-8 for the stuff you generate if you can.
> For what you have to consume from other software simply has to work.  If not
>you can go back to the folks responsible for creating it and find a way to mak
> it valid.
>> 
>> 
>> For stuff I will have to generate, the FOR XML clause doesn't have a
>> parameter for the encoding and I'm not finding anything in BooksOnline
>> about how to set the encoding, or about a default encoding for output
>> generated using FOR XML.  ???   Clearly this is something about which I
>> need to learn much more, until now I have only been consuming XML, not
>> outputting it.   Somewhere I saw that SS2005 can automatically create
>> SOAP objects, maybe that is something to investigate.
>> 
> Beware of automatically producing Soap objects as sometimes you have to
> create more than you need (e.g. if there is a schema).

Yes, in general I hate using anything that claims it can automatically do stuff
that really is better off being coded.  So far I haven't seen any API's for
creating Sonic messages, that is what I need to be able to do.  (Have you
worked with Sonic?)

> It is string. Treat it as string. get an api which can read string & an
> api which can write string.

That's what we have been doing internally, but as Rich correctly pointed out,
really we are creating the documents in whatever encoding VB6 uses, probably
Windows-1252, even though we are indicating in the header UTF-8 or UTF-16.  Is
there a way to treat it as string AND control the ACTUAL encoding?

> You could move the processing "off shore" to an app server (e.g.
> apache/IIS/Jboss/Tomcat) & use the db just as a store of tables.
> A pre-processor so to speak.

I have thankfully nothing to do with this part.  The amount of stuff I will
have to produce (as opposed to consuming) will be relatively small.  I only
know two pieces I will have to generate:   1.We are keeping the leads
distribution piece in house, I will have to create a Sonic message that carries
each new set of leads to SalesForce.  Also it looks like customer history will
only be maintained in the data warehouse, so 2.  I will also have to create a
Sonic message to deliver history of any given customer upon request.

> You can then put a bunch in as pizza boxes & use a load balancer.

Also thankfully not my responsibility.

>> Based on Sunday's experiments and the fact that Oracle's default is
>> UTF-16, it's looking to me like that would be the most foolproof, but
>> OTOH being that every character will take 2 bytes it could slow things
>> down.   I had originally planned to communicate directly with Oracle but
>> I will likely have to use Sonic for situations requiring the equivalent
>> of a distributed transaction where related data need to be written to
>> SQL Server, Oracle and one or more of the purchased apps.  Our Oracle
>> guy's strength is the Oracle Financials apps as opposed to stuff like
>> interoperability.  Sonic and the purchased apps are being installed and
>> configured by an outside consulting outfit -- I don't wanna get involved
>> with trying to make either the outside consultants or the vendors fix
>> stuff that doesn't work, I want it to work from day one and continue to
>> work going forward.  I am going to try to talk with them about this but
>> based on what I've seen so far I can't say my expectations are very
>> high.
>> 
> UTF-8 is the std.

Not for Oracle, Oracle 9.x defaults to UTF-16, and we are stuck with that
because we are using Oracle G/L, A/P and Inventory.  But as previously noted I
think forcing every character to 16 bits is likely to negatively impact
performance.  I have recommended that we test every system's output as input to
every other system and then decide.  I'm guessing maybe we can use UTF-8 for
most things, and only use UTF-16 for those things where UTF-8 doesn't work
correctly for whatever reason.

Any other ideas and/or information gratefully appreciated!

> Adam

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)