Tillbaka till svenska Fidonet
English   Information   Debug  
OS2BBS   0/787
OS2DOSBBS   0/580
OS2HW   0/42
OS2INET   0/37
OS2LAN   0/134
OS2PROG   0/36
OS2REXX   0/113
OS2USER-L   207
OS2   0/4786
OSDEBATE   3490/18996
PASCAL   0/490
PERL   0/457
PHP   0/45
POINTS   0/405
POLITICS   0/29554
POL_INC   0/14731
PSION   103
R20_ADMIN   1121
R20_AMATORRADIO   0/2
R20_BEST_OF_FIDONET   13
R20_CHAT   0/893
R20_DEPP   0/3
R20_DEV   399
R20_ECHO2   1379
R20_ECHOPRES   0/35
R20_ESTAT   0/719
R20_FIDONETPROG...
...RAM.MYPOINT
  0/2
R20_FIDONETPROGRAM   0/22
R20_FIDONET   0/248
R20_FILEFIND   0/24
R20_FILEFOUND   0/22
R20_HIFI   0/3
R20_INFO2   3205
R20_INTERNET   0/12940
R20_INTRESSE   0/60
R20_INTR_KOM   0/99
R20_KANDIDAT.CHAT   42
R20_KANDIDAT   28
R20_KOM_DEV   112
R20_KONTROLL   0/13258
R20_KORSET   0/18
R20_LOKALTRAFIK   0/24
R20_MODERATOR   0/1852
R20_NC   76
R20_NET200   245
R20_NETWORK.OTH...
...ERNETS
  0/13
R20_OPERATIVSYS...
...TEM.LINUX
  0/44
R20_PROGRAMVAROR   0/1
R20_REC2NEC   534
R20_SFOSM   0/340
R20_SF   0/108
R20_SPRAK.ENGLISH   0/1
R20_SQUISH   107
R20_TEST   2
R20_WORST_OF_FIDONET   12
RAR   0/9
RA_MULTI   106
RA_UTIL   0/162
REGCON.EUR   0/2056
REGCON   0/13
SCIENCE   0/1206
SF   0/239
SHAREWARE_SUPPORT   0/5146
SHAREWRE   0/14
SIMPSONS   0/169
STATS_OLD1   0/2539.065
STATS_OLD2   0/2530
STATS_OLD3   0/2395.095
STATS_OLD4   0/1692.25
SURVIVOR   0/495
SYSOPS_CORNER   0/3
SYSOP   0/84
TAGLINES   0/112
TEAMOS2   0/4530
TECH   0/2617
TEST.444   0/105
TRAPDOOR   0/19
TREK   0/755
TUB   0/290
UFO   0/40
UNIX   0/1316
USA_EURLINK   0/102
USR_MODEMS   0/1
VATICAN   0/2740
VIETNAM_VETS   0/14
VIRUS   0/378
VIRUS_INFO   0/201
VISUAL_BASIC   0/473
WHITEHOUSE   0/5187
WIN2000   0/101
WIN32   0/30
WIN95   0/4288
WIN95_OLD1   0/70272
WINDOWS   0/1517
WWB_SYSOP   0/419
WWB_TECH   0/810
ZCC-PUBLIC   0/1
ZEC   4

 
4DOS   0/134
ABORTION   0/7
ALASKA_CHAT   0/506
ALLFIX_FILE   0/1313
ALLFIX_FILE_OLD1   0/7997
ALT_DOS   0/152
AMATEUR_RADIO   0/1039
AMIGASALE   0/14
AMIGA   0/331
AMIGA_INT   0/1
AMIGA_PROG   0/20
AMIGA_SYSOP   0/26
ANIME   0/15
ARGUS   0/924
ASCII_ART   0/340
ASIAN_LINK   0/651
ASTRONOMY   0/417
AUDIO   0/92
AUTOMOBILE_RACING   0/105
BABYLON5   0/17862
BAG   135
BATPOWER   0/361
BBBS.ENGLISH   0/382
BBSLAW   0/109
BBS_ADS   0/5290
BBS_INTERNET   0/507
BIBLE   0/3563
BINKD   0/1119
BINKLEY   0/215
BLUEWAVE   0/2173
CABLE_MODEMS   0/25
CBM   0/46
CDRECORD   0/66
CDROM   0/20
CLASSIC_COMPUTER   0/378
COMICS   0/15
CONSPRCY   0/899
COOKING   32677
COOKING_OLD1   0/24719
COOKING_OLD2   0/40862
COOKING_OLD3   0/37489
COOKING_OLD4   0/35496
COOKING_OLD5   9370
C_ECHO   0/189
C_PLUSPLUS   0/31
DIRTY_DOZEN   0/201
DOORGAMES   0/2053
DOS_INTERNET   0/196
duplikat   6002
ECHOLIST   0/18295
EC_SUPPORT   0/318
ELECTRONICS   0/359
ELEKTRONIK.GER   1534
ENET.LINGUISTIC   0/13
ENET.POLITICS   0/4
ENET.SOFT   0/11701
ENET.SYSOP   33888
ENET.TALKS   0/32
ENGLISH_TUTOR   0/2000
EVOLUTION   0/1335
FDECHO   0/217
FDN_ANNOUNCE   0/7068
FIDONEWS   24094
FIDONEWS_OLD1   0/49742
FIDONEWS_OLD2   0/35949
FIDONEWS_OLD3   0/30874
FIDONEWS_OLD4   0/37224
FIDO_SYSOP   12852
FIDO_UTIL   0/180
FILEFIND   0/209
FILEGATE   0/212
FILM   0/18
FNEWS_PUBLISH   4393
FN_SYSOP   41678
FN_SYSOP_OLD1   71952
FTP_FIDO   0/2
FTSC_PUBLIC   0/13598
FUNNY   0/4886
GENEALOGY.EUR   0/71
GET_INFO   105
GOLDED   0/408
HAM   0/16069
HOLYSMOKE   0/6791
HOT_SITES   0/1
HTMLEDIT   0/71
HUB203   466
HUB_100   264
HUB_400   39
HUMOR   0/29
IC   0/2851
INTERNET   0/424
INTERUSER   0/3
IP_CONNECT   719
JAMNNTPD   0/233
JAMTLAND   0/47
KATTY_KORNER   0/41
LAN   0/16
LINUX-USER   0/19
LINUXHELP   0/1155
LINUX   0/22090
LINUX_BBS   0/957
mail   18.68
mail_fore_ok   249
MENSA   0/341
MODERATOR   0/102
MONTE   0/992
MOSCOW_OKLAHOMA   0/1245
MUFFIN   0/783
MUSIC   0/321
N203_STAT   924
N203_SYSCHAT   313
NET203   321
NET204   69
NET_DEV   0/10
NORD.ADMIN   0/101
NORD.CHAT   0/2572
NORD.FIDONET   189
NORD.HARDWARE   0/28
NORD.KULTUR   0/114
NORD.PROG   0/32
NORD.SOFTWARE   0/88
NORD.TEKNIK   0/58
NORD   0/453
OCCULT_CHAT   0/93
Möte OSDEBATE, 18996 texter
 lista första sista föregående nästa
Text 2641, 590 rader
Skriven 2005-02-20 13:10:40 av Rich (1:379/45)
   Kommentar till text 2639 av Ellen K. (1:379/45)
Ärende: Re: ESB / XML / Unicode vs 8-bit characters ?
=====================================================
From: "Rich" <@>

This is a multi-part message in MIME format.

------=_NextPart_000_085D_01C5174D.937C1370
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   The Spanish accented characters are not part of ASCII.  They are part =
of Windows calls ANSI of which ASCII is the subset (0x00 to 0x7F).  Any =
character in the 0x80 to 0xFF range is not compatible between ANSI and = UTF-8.

Rich

  "Ellen K." <72322.1016@compuserve.com> wrote in message =
news:7ouh119ivmuk26icg3mqqqk2ss1lfm5c10@4ax.com...
  Should not have any non-ASCII characters, as previously noted all the
  special Spanish characters are available in the ASCII character set.
  And since the company is built on our understanding of the Hispanic
  market, I don't see any use of, say, pictograph-based languages in the
  foreseeable future.   If 10 years down the road something like that
  happens, well, by then we will no longer need compatibility with the
  current legacy system because it will long since have been replaced.

  On Sun, 20 Feb 2005 12:52:25 -0800, "Rich" <@> wrote in message
  <4218f849$1@w3.nls.net>:

  >   From what you describe below, if the values you emit to XML have =
non-ASCII characters I would expect you to have a problem.
  >
  >Rich
  >
  >  "Ellen K." <72322.1016@compuserve.com> wrote in message =
news:eanh11h4vv6b9v21fiaounii3f5dunjl3g@4ax.com...
  >  On Sat, 19 Feb 2005 23:32:37 -0800, "Rich" <@> wrote in message
  >  <42183ccd@w3.nls.net>:
  >
  >  >   The UTF in UTF-8/16/32 stands for Unicode Transformation =
Format.  You can find these defined in section 2.5 of =
http://www.unicode.org/versions/Unicode4.0.0/ch02.pdf.
  >
  >  THANK YOU SO MUCH!!!    :)
  >  >
  >  >   It's not clear to me how you are creating the XML from the =
templates.  If ANSI data is emitted into an XML document declared as = UTF-8
then you would have problems only for non-ASCII characters.  UTF-8 = and
Windows-1252 are identical for 0x00 to 0x7F which is ASCII in both.
  >
  >  I don't have a copy of a template here at home, but I have them =
create
  >  it by string concatenation because that seems to be the only way to =
be
  >  able to have CDATA attributes, which I have to have because in the
  >  legacy data numeric-appearing identifiers are actually 10-character
  >  strings with leading spaces, and if these are not specified as =
CDATA
  >  the spaces go lost even with "xml:space=3D"preserve"" included in =
the
  >  header.  Here is a code snippet from one of my apps that creates an =
XML
  >  document which is passed as a parameter to a SQL Server stored
  >  procedure:
  >
  >  >      strXM =3D "<?xml version =3D" & Chr(34) & "1.0" & Chr(34) & =
"  encoding=3D" & Chr(34) & "UTF-8" & Chr(34) & "?>" & vbCrLf _
  >  >        & "<ROOT xml:space=3D" & Chr(34) & "preserve" & Chr(34) & =
">" & vbCrLf
  >  >
  >  >      Do While Not .EOF
  >  >        strXM =3D strXM & "<M><A>" & !Ofc & "</A><B><![CDATA[" & =
!Contract & "]]></B><C>" & !TCode & "</C><D>" & !Date & "</D>" _
  >  >                & "<E><![CDATA[" & !TransNo & "]]></E></M>" & =
vbCrLf
  >  >        .MoveNext
  >  >      Loop
  >  >
  >  >      strXM =3D strXM & "</ROOT>"
  >
  >  (The vbCrLf's are there so if there is a problem the document can =
be
  >  printed to a text file and be easier for humans to read -- SQL =
Server
  >  ignores them.  The single-character aliases for entity and =
attribute
  >  names are for performance -- for most of the stuff we use these for =
it
  >  doesn't really matter because we are only sending a few rows, but =
the
  >  first time I did it it was for something that was sending about =
5000
  >  rows and there it made a huge difference, so I stuck with it.  We
  >  comment both the front-end code and the stored procedure with the
  >  mappings of these aliases.)
  >
  >  >   I do not know how SQL Server maps from char to nchar, =
specifically what conversion is performed.  Also, in some (maybe all =
released) versions of SQL Server nchar and nvarchar are encoded in = UCS-2. 
UCS-2 is a 16-bit encoding like UTF-16.  It dates back to when = Unicode was
defined as having 2**16 characters instead of the 2**20+ = that it has now. 
You can not express characters >=3D U+10000 in UCS-2 = not that you care about
these.
  >
  >  Thankfully, no.   :)
  >  >
  >  >   I don't know if whether those systems you describe being =
written in java make a difference.  They can do what they want.  The = native
java string is Unicode though I don't remember if it is UCS-2 or = UTF-16.  My
guess is that it was once the former and is now the latter.  = One of the
documents on this on sun's site suggests that java used UCS-2 = until the
recently released 1.5 which is the first to use UTF-16.
  >
  >  The Java native string being unicode is exactly what made me start
  >  worrying -- when I was learning Java a couple of years ago (because =
I
  >  wanted to port an app to it so as to be able to run it right on the =
Unix
  >  box where the Oracle database was) I was horrified the first time I
  >  tried reading back what I had written to a text file when I saw =
spaces
  >  between all the characters.
  >  >
  >  >Rich
  >  >
  >  >  "Ellen K." <72322.1016@compuserve.com> wrote in message =
news:aqag115606i9g8bmh3lst66une1f1sotth@4ax.com...
  >  >  UTF-8 is unicode?!?   Sheesh, all this time I thought it meant =
8-bit.
  >  >  In fact I could swear I read that somewhere.
  >  >
  >  >  My question was coming from the database perspective, where I =
always use
  >  >  char and varchar, as opposed to nchar and nvarchar.  I give the
  >  >  front-end guys little templates for creating the XML documents =
for all
  >  >  my SQL Server stored procedures that take XML input, and I =
always
  >  >  specify UTF-8 in the header... and my char and varchar columns =
always
  >  >  end up normal, so since you're now telling me UTF-8 is really =
unicode, I
  >  >  guess that would answer my question for XML data I would be =
getting from
  >  >  the apps...?    Or would the answer be different if the incoming =
XML is
  >  >  some other encoding?
  >  >
  >  >  To simulate getting nvarchar data from somewhere, I just tried =
creating
  >  >  two dummy tables, one with an nvarchar column and the other with =
a
  >  >  varchar column, typed stuff into the nvarchar one, then inserted =
to the
  >  >  varchar one select from the nvarchar one and it looks normal. =20
  >  >
  >  >  If all this means I was worrying about nothing, excellent!   =
OTOH, is
  >  >  there something I should be worrying about that I didn't ask?
  >  >
  >  >  The only pieces whose names I know so far are Sonic and =
SalesForce, both
  >  >  of which are written in Java, if that makes any difference.  I =
know
  >  >  there is at least one other external piece but I think that is =
the next
  >  >  phase.
  >  >
  >  >  On Sat, 19 Feb 2005 21:37:15 -0800, "Rich" <@> wrote in message
  >  >  <421821c1$1@w3.nls.net>:
  >  >
  >  >  >   You need to be more specific than "8-bit characters".  There =
are many 8-bit character encodings.  If you are using Windows to = generate
your data you most likely are using Windows-1252 which is the = default 8-bit
character set for U.S. English in Windows.  Windows = supports many 8-bit
encodings so you could be using something else too.
  >  >  >
  >  >  >   Unicode is a character set not an encoding.  There are =
multiple encodings the main ones being UTF-8, UTF-16, and UTF-32.  You = can
use any of these for XML as well as non-Unicode encodings.  For =
interoperability you should use Unicode preferably UTF-8.
  >  >  >
  >  >  >   What comes out when the XML is parsed depends on the XML =
parser.  XML is logically expressed in Unicode.  The Windows XML parsers =
provide a Unicode interface.  Other parsers could do differently.
  >  >  >
  >  >  >Rich
  >  >  >
  >  >  >
  >  >  >  "Ellen K." <72322.1016@compuserve.com> wrote in message =
news:4o2g11pu048kafbdilg46u77vs5ls0be55@4ax.com...
  >  >  >  Our new enterprise system is going to be built around an =
Enterprise
  >  >  >  Service Bus.  I don't have the full specs yet but as I =
understand it the
  >  >  >  main apps (starting with SalesForce) are going to be out on =
the internet
  >  >  >  and the Sonic ESB will be the messaging piece.  There will  =
be an
  >  >  >  Operational Data Store in house that will get updated every =
night on a
  >  >  >  batch basis from the main apps. =20
  >  >  >
  >  >  >  My data warehouse will continue to be the data warehouse and =
will remain
  >  >  >  in house.  The dimensions will stay the same but I might have =
to create
  >  >  >  separate measures for the data from the new apps and then =
create views
  >  >  >  to keep everything transparent to the users.  =20
  >  >  >
  >  >  >  I'm thinking if we're going to have an ODS in house already, =
I may as
  >  >  >  well do the ETL from there.   But I'm worrying that the new =
data will
  >  >  >  probably be unicode (because Java defaults to that and =
SalesForce is
  >  >  >  written in Java).  Right now I am storing everything (except =
our blobs
  >  >  >  of course) in 8-bit characters.  =20
  >  >  >
  >  >  >  Anyone here who's up on this stuff, can the XML that goes =
back and forth
  >  >  >  convert between unicode and 8-bit characters, or am I gonna =
have to
  >  >  >  redefine all my data?   For example, if unicode data is put =
into an XML
  >  >  >  document that specifies UTF-8, what comes out when the =
document is
  >  >  >  parsed?  How about vice versa?  If this is too simplistic to =
work, what
  >  >  >  is needed?
  >  >  >
  >  >  >  (We actually have no substantive need for unicode -- we are =
bilingual
  >  >  >  Spanish but all the special Spanish characters exist in the =
ascii
  >  >  >  character set.)

------=_NextPart_000_085D_01C5174D.937C1370
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.3790.1289" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; The Spanish accented =
characters are=20
not part of ASCII.&nbsp; They are part of Windows calls ANSI of which = ASCII
is=20
the subset (0x00 to 0x7F).&nbsp; Any character in the 0x80 to 0xFF range = is
not=20
compatible between ANSI and UTF-8.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Rich</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV>"Ellen K." &lt;<A=20
  =
href=3D"mailto:72322.1016@compuserve.com">72322.1016@compuserve.com</A>&g=
t;=20
  wrote in message <A=20
  =
href=3D"news:7ouh119ivmuk26icg3mqqqk2ss1lfm5c10@4ax.com">news:7ouh119ivmu=
k26icg3mqqqk2ss1lfm5c10@4ax.com</A>...</DIV>Should=20
  not have any non-ASCII characters, as previously noted all =
the<BR>special=20
  Spanish characters are available in the ASCII character set.<BR>And =
since the=20
  company is built on our understanding of the Hispanic<BR>market, I =
don't see=20
  any use of, say, pictograph-based languages in the<BR>foreseeable=20
  future.&nbsp;&nbsp; If 10 years down the road something like =
that<BR>happens,=20
  well, by then we will no longer need compatibility with the<BR>current =
legacy=20
  system because it will long since have been replaced.<BR><BR>On Sun, =
20 Feb=20
  2005 12:52:25 -0800, "Rich" &lt;@&gt; wrote in message<BR>&lt;<A=20
  =
href=3D"mailto:4218f849$1@w3.nls.net">4218f849$1@w3.nls.net</A>&gt;:<BR><=
BR>&gt;&nbsp;&nbsp;=20
  From what you describe below, if the values you emit to XML have =
non-ASCII=20
  characters I would expect you to have a=20
  problem.<BR>&gt;<BR>&gt;Rich<BR>&gt;<BR>&gt;&nbsp; "Ellen K." &lt;<A=20
  =
href=3D"mailto:72322.1016@compuserve.com">72322.1016@compuserve.com</A>&g=
t;=20
  wrote in message <A=20
  =
href=3D"news:eanh11h4vv6b9v21fiaounii3f5dunjl3g@4ax.com">news:eanh11h4vv6=
b9v21fiaounii3f5dunjl3g@4ax.com</A>...<BR>&gt;&nbsp;=20
  On Sat, 19 Feb 2005 23:32:37 -0800, "Rich" &lt;@&gt; wrote in=20
  message<BR>&gt;&nbsp; &lt;<A=20
  =
href=3D"mailto:42183ccd@w3.nls.net">42183ccd@w3.nls.net</A>&gt;:<BR>&gt;<=
BR>&gt;&nbsp;=20
  &gt;&nbsp;&nbsp; The UTF in UTF-8/16/32 stands for Unicode =
Transformation=20
  Format.&nbsp; You can find these defined in section 2.5 of <A=20
  =
href=3D"http://www.unicode.org/versions/Unicode4.0.0/ch02.pdf">http://www=
.unicode.org/versions/Unicode4.0.0/ch02.pdf</A>.<BR>&gt;<BR>&gt;&nbsp;=20
  THANK YOU SO MUCH!!!&nbsp;&nbsp;&nbsp; :)<BR>&gt;&nbsp; =
&gt;<BR>&gt;&nbsp;=20
  &gt;&nbsp;&nbsp; It's not clear to me how you are creating the XML =
from the=20
  templates.&nbsp; If ANSI data is emitted into an XML document declared =
as=20
  UTF-8 then you would have problems only for non-ASCII =
characters.&nbsp; UTF-8=20
  and Windows-1252 are identical for 0x00 to 0x7F which is ASCII in=20
  both.<BR>&gt;<BR>&gt;&nbsp; I don't have a copy of a template here at =
home,=20
  but I have them create<BR>&gt;&nbsp; it by string concatenation =
because that=20
  seems to be the only way to be<BR>&gt;&nbsp; able to have CDATA =
attributes,=20
  which I have to have because in the<BR>&gt;&nbsp; legacy data=20
  numeric-appearing identifiers are actually 10-character<BR>&gt;&nbsp; =
strings=20
  with leading spaces, and if these are not specified as =
CDATA<BR>&gt;&nbsp; the=20
  spaces go lost even with "xml:space=3D"preserve"" included in =
the<BR>&gt;&nbsp;=20
  header.&nbsp; Here is a code snippet from one of my apps that creates =
an=20
  XML<BR>&gt;&nbsp; document which is passed as a parameter to a SQL =
Server=20
  stored<BR>&gt;&nbsp; procedure:<BR>&gt;<BR>&gt;&nbsp;=20
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; strXM =3D "&lt;?xml version =3D" =
&amp; Chr(34)=20
  &amp; "1.0" &amp; Chr(34) &amp; "&nbsp; encoding=3D" &amp; Chr(34) =
&amp; "UTF-8"=20
  &amp; Chr(34) &amp; "?&gt;" &amp; vbCrLf _<BR>&gt;&nbsp;=20
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp; "&lt;ROOT =
xml:space=3D"=20
  &amp; Chr(34) &amp; "preserve" &amp; Chr(34) &amp; "&gt;" &amp;=20
  vbCrLf<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do=20
  While Not .EOF<BR>&gt;&nbsp; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  strXM =3D strXM &amp; "&lt;M&gt;&lt;A&gt;" &amp; !Ofc &amp;=20
  "&lt;/A&gt;&lt;B&gt;&lt;![CDATA[" &amp; !Contract &amp;=20
  "]]&gt;&lt;/B&gt;&lt;C&gt;" &amp; !TCode &amp; "&lt;/C&gt;&lt;D&gt;" =
&amp;=20
  !Date &amp; "&lt;/D&gt;" _<BR>&gt;&nbsp;=20
  =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
  &amp; "&lt;E&gt;&lt;![CDATA[" &amp; !TransNo &amp;=20
  "]]&gt;&lt;/E&gt;&lt;/M&gt;" &amp; vbCrLf<BR>&gt;&nbsp;=20
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .MoveNext<BR>&gt;&nbsp; =

  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Loop<BR>&gt;&nbsp; =
&gt;<BR>&gt;&nbsp;=20
  &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; strXM =3D strXM &amp;=20
  "&lt;/ROOT&gt;"<BR>&gt;<BR>&gt;&nbsp; (The vbCrLf's are there so if =
there is a=20
  problem the document can be<BR>&gt;&nbsp; printed to a text file and =
be easier=20
  for humans to read -- SQL Server<BR>&gt;&nbsp; ignores them.&nbsp; The =

  single-character aliases for entity and attribute<BR>&gt;&nbsp; names =
are for=20
  performance -- for most of the stuff we use these for it<BR>&gt;&nbsp; =
doesn't=20
  really matter because we are only sending a few rows, but =
the<BR>&gt;&nbsp;=20
  first time I did it it was for something that was sending about=20
  5000<BR>&gt;&nbsp; rows and there it made a huge difference, so I =
stuck with=20
  it.&nbsp; We<BR>&gt;&nbsp; comment both the front-end code and the =
stored=20
  procedure with the<BR>&gt;&nbsp; mappings of these=20
  aliases.)<BR>&gt;<BR>&gt;&nbsp; &gt;&nbsp;&nbsp; I do not know how SQL =
Server=20
  maps from char to nchar, specifically what conversion is =
performed.&nbsp;=20
  Also, in some (maybe all released) versions of SQL Server nchar and =
nvarchar=20
  are encoded in UCS-2.&nbsp; UCS-2 is a 16-bit encoding like =
UTF-16.&nbsp; It=20
  dates back to when Unicode was defined as having 2**16 characters =
instead of=20
  the 2**20+ that it has now.&nbsp; You can not express characters =
&gt;=3D U+10000=20
  in UCS-2 not that you care about these.<BR>&gt;<BR>&gt;&nbsp; =
Thankfully,=20
  no.&nbsp;&nbsp; :)<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;&nbsp;&nbsp; I =
don't=20
  know if whether those systems you describe being written in java make =
a=20
  difference.&nbsp; They can do what they want.&nbsp; The native java =
string is=20
  Unicode though I don't remember if it is UCS-2 or UTF-16.&nbsp; My =
guess is=20
  that it was once the former and is now the latter.&nbsp; One of the =
documents=20
  on this on sun's site suggests that java used UCS-2 until the recently =

  released 1.5 which is the first to use UTF-16.<BR>&gt;<BR>&gt;&nbsp; =
The Java=20
  native string being unicode is exactly what made me =
start<BR>&gt;&nbsp;=20
  worrying -- when I was learning Java a couple of years ago (because=20
  I<BR>&gt;&nbsp; wanted to port an app to it so as to be able to run it =
right=20
  on the Unix<BR>&gt;&nbsp; box where the Oracle database was) I was =
horrified=20
  the first time I<BR>&gt;&nbsp; tried reading back what I had written =
to a text=20
  file when I saw spaces<BR>&gt;&nbsp; between all the =
characters.<BR>&gt;&nbsp;=20
  &gt;<BR>&gt;&nbsp; &gt;Rich<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; =
&gt;&nbsp; "Ellen=20
  K." &lt;<A=20
  =
href=3D"mailto:72322.1016@compuserve.com">72322.1016@compuserve.com</A>&g=
t;=20
  wrote in message <A=20
  =
href=3D"news:aqag115606i9g8bmh3lst66une1f1sotth@4ax.com">news:aqag115606i=
9g8bmh3lst66une1f1sotth@4ax.com</A>...<BR>&gt;&nbsp;=20
  &gt;&nbsp; UTF-8 is unicode?!?&nbsp;&nbsp; Sheesh, all this time I =
thought it=20
  meant 8-bit.<BR>&gt;&nbsp; &gt;&nbsp; In fact I could swear I read =
that=20
  somewhere.<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;&nbsp; My question was =
coming=20
  from the database perspective, where I always use<BR>&gt;&nbsp; =
&gt;&nbsp;=20
  char and varchar, as opposed to nchar and nvarchar.&nbsp; I give=20
  the<BR>&gt;&nbsp; &gt;&nbsp; front-end guys little templates for =
creating the=20
  XML documents for all<BR>&gt;&nbsp; &gt;&nbsp; my SQL Server stored =
procedures=20
  that take XML input, and I always<BR>&gt;&nbsp; &gt;&nbsp; specify =
UTF-8 in=20
  the header... and my char and varchar columns always<BR>&gt;&nbsp; =
&gt;&nbsp;=20
  end up normal, so since you're now telling me UTF-8 is really unicode, =

  I<BR>&gt;&nbsp; &gt;&nbsp; guess that would answer my question for XML =
data I=20
  would be getting from<BR>&gt;&nbsp; &gt;&nbsp; the =
apps...?&nbsp;&nbsp;&nbsp;=20
  Or would the answer be different if the incoming XML is<BR>&gt;&nbsp;=20
  &gt;&nbsp; some other encoding?<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; =
&gt;&nbsp; To=20
  simulate getting nvarchar data from somewhere, I just tried=20
  creating<BR>&gt;&nbsp; &gt;&nbsp; two dummy tables, one with an =
nvarchar=20
  column and the other with a<BR>&gt;&nbsp; &gt;&nbsp; varchar column, =
typed=20
  stuff into the nvarchar one, then inserted to the<BR>&gt;&nbsp; =
&gt;&nbsp;=20
  varchar one select from the nvarchar one and it looks normal.&nbsp;=20
  <BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;&nbsp; If all this means I was =
worrying=20
  about nothing, excellent!&nbsp;&nbsp; OTOH, is<BR>&gt;&nbsp; =
&gt;&nbsp; there=20
  something I should be worrying about that I didn't ask?<BR>&gt;&nbsp;=20
  &gt;<BR>&gt;&nbsp; &gt;&nbsp; The only pieces whose names I know so =
far are=20
  Sonic and SalesForce, both<BR>&gt;&nbsp; &gt;&nbsp; of which are =
written in=20
  Java, if that makes any difference.&nbsp; I know<BR>&gt;&nbsp; =
&gt;&nbsp;=20
  there is at least one other external piece but I think that is the=20
  next<BR>&gt;&nbsp; &gt;&nbsp; phase.<BR>&gt;&nbsp; &gt;<BR>&gt;&nbsp;=20
  &gt;&nbsp; On Sat, 19 Feb 2005 21:37:15 -0800, "Rich" &lt;@&gt; wrote =
in=20
  message<BR>&gt;&nbsp; &gt;&nbsp; &lt;<A=20
  =
href=3D"mailto:421821c1$1@w3.nls.net">421821c1$1@w3.nls.net</A>&gt;:<BR>&=
gt;&nbsp;=20
  &gt;<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp;&nbsp; You need to be more =
specific=20
  than "8-bit characters".&nbsp; There are many 8-bit character =
encodings.&nbsp;=20
  If you are using Windows to generate your data you most likely are =
using=20
  Windows-1252 which is the default 8-bit character set for U.S. English =
in=20
  Windows.&nbsp; Windows supports many 8-bit encodings so you could be =
using=20
  something else too.<BR>&gt;&nbsp; &gt;&nbsp; &gt;<BR>&gt;&nbsp; =
&gt;&nbsp;=20
  &gt;&nbsp;&nbsp; Unicode is a character set not an encoding.&nbsp; =
There are=20
  multiple encodings the main ones being UTF-8, UTF-16, and =
UTF-32.&nbsp; You=20
  can use any of these for XML as well as non-Unicode encodings.&nbsp; =
For=20
  interoperability you should use Unicode preferably =
UTF-8.<BR>&gt;&nbsp;=20
  &gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp;&nbsp; What comes =
out when=20
  the XML is parsed depends on the XML parser.&nbsp; XML is logically =
expressed=20
  in Unicode.&nbsp; The Windows XML parsers provide a Unicode =
interface.&nbsp;=20
  Other parsers could do differently.<BR>&gt;&nbsp; &gt;&nbsp;=20
  &gt;<BR>&gt;&nbsp; &gt;&nbsp; &gt;Rich<BR>&gt;&nbsp; &gt;&nbsp;=20
  &gt;<BR>&gt;&nbsp; &gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; =
"Ellen=20
  K." &lt;<A=20
  =
href=3D"mailto:72322.1016@compuserve.com">72322.1016@compuserve.com</A>&g=
t;=20
  wrote in message <A=20
  =
href=3D"news:4o2g11pu048kafbdilg46u77vs5ls0be55@4ax.com">news:4o2g11pu048=
kafbdilg46u77vs5ls0be55@4ax.com</A>...<BR>&gt;&nbsp;=20
  &gt;&nbsp; &gt;&nbsp; Our new enterprise system is going to be built =
around an=20
  Enterprise<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; Service Bus.&nbsp; I =
don't have=20
  the full specs yet but as I understand it the<BR>&gt;&nbsp; &gt;&nbsp; =

  &gt;&nbsp; main apps (starting with SalesForce) are going to be out on =
the=20
  internet<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; and the Sonic ESB will be =
the=20
  messaging piece.&nbsp; There will&nbsp; be an<BR>&gt;&nbsp; &gt;&nbsp; =

  &gt;&nbsp; Operational Data Store in house that will get updated every =
night=20
  on a<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; batch basis from the main =
apps.&nbsp;=20
  <BR>&gt;&nbsp; &gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; My =
data=20
  warehouse will continue to be the data warehouse and will =
remain<BR>&gt;&nbsp;=20
  &gt;&nbsp; &gt;&nbsp; in house.&nbsp; The dimensions will stay the =
same but I=20
  might have to create<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; separate =
measures for=20
  the data from the new apps and then create views<BR>&gt;&nbsp; =
&gt;&nbsp;=20
  &gt;&nbsp; to keep everything transparent to the users.&nbsp;&nbsp;=20
  <BR>&gt;&nbsp; &gt;&nbsp; &gt;<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; I'm =

  thinking if we're going to have an ODS in house already, I may=20
  as<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; well do the ETL from =
there.&nbsp;&nbsp;=20
  But I'm worrying that the new data will<BR>&gt;&nbsp; &gt;&nbsp; =
&gt;&nbsp;=20
  probably be unicode (because Java defaults to that and SalesForce=20
  is<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; written in Java).&nbsp; Right =
now I am=20
  storing everything (except our blobs<BR>&gt;&nbsp; &gt;&nbsp; =
&gt;&nbsp; of=20
  course) in 8-bit characters.&nbsp;&nbsp; <BR>&gt;&nbsp; &gt;&nbsp;=20
  &gt;<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; Anyone here who's up on this =
stuff,=20
  can the XML that goes back and forth<BR>&gt;&nbsp; &gt;&nbsp; =
&gt;&nbsp;=20
  convert between unicode and 8-bit characters, or am I gonna have=20
  to<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; redefine all my =
data?&nbsp;&nbsp; For=20
  example, if unicode data is put into an XML<BR>&gt;&nbsp; &gt;&nbsp;=20
  &gt;&nbsp; document that specifies UTF-8, what comes out when the =
document=20
  is<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; parsed?&nbsp; How about vice=20
  versa?&nbsp; If this is too simplistic to work, what<BR>&gt;&nbsp; =
&gt;&nbsp;=20
  &gt;&nbsp; is needed?<BR>&gt;&nbsp; &gt;&nbsp; &gt;<BR>&gt;&nbsp; =
&gt;&nbsp;=20
  &gt;&nbsp; (We actually have no substantive need for unicode -- we are =

  bilingual<BR>&gt;&nbsp; &gt;&nbsp; &gt;&nbsp; Spanish but all the =
special=20
  Spanish characters exist in the ascii<BR>&gt;&nbsp; &gt;&nbsp; =
&gt;&nbsp;=20
  character set.)<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_085D_01C5174D.937C1370--

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