[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HTTPAPI (Web Service) sending an XML string as an input parameter to a web service 'brackets'
- From: Scott Klement <sk@xxxxxxxxxxxxxxxx>
- To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: HTTPAPI (Web Service) sending an XML string as an input parameter to a web service 'brackets'
- Date: Mon, 16 Nov 2009 12:36:47 -0600
Hi Kevin,
> D var_LBracket s 1 inz(x'BA')
> D var_XMLMsg s 32767A varying
> D var_RBracket s 1 inz(x'BB')
>
> /free
> http_SetCCSIDs(1208: 0);
I'm guessing from your description that your job's CCSID is 65535, and
that it's default CCSID is 37. After about an hour of research this
morning, I think your source code is NOT in CCSID 37, but rather is in
CCSID 1137. (Which is Devanagari EBCDIC -- working in India lately?!)
Here's the thing... the bracket characters are at a different code
point in every code page -- In English that means that every flavor of
EBCDIC has a different hex value for brackets.
In CCSID 1137, the hex value for [ is x'AD' and the hex value for ] is
x'BD'. However, in CCSID 37, the brackets are x'BA' and x'BB', respectively.
Here's the problem. If you have put a [ in your source code, and your
terminal is set up as 1137, guess what you just put there? You put a
x'AD'. Nothing wrong with that, as long as the system knows that your
source code is 1137.
However, you were telling HTTPAPI that your source code is 37. In CCSID
37, x'AD' is the Ý character (a capital Y with a right-slanting accent)
so if your data is x'AD' but you tell the system that it's 37, then the
system will think it's that Ý character! And when it converts it to
ASCII/UTF-8 it will translate it to the corresponding Ý (cap Y with
accdent) in ASCII or UTF-8.
One of the biggest problems with EBCDIC is that the bracket characters
are "variant", meaning that they are inconsistent from one code page to
another. They are in many different spots depending on the CCSID.
Anyway, if you didn't want to hard-code hex values, you could've done this:
HTTP_setCCSID(1208: 1137);
In this case, I used 1137 as an example because it seemed to fit the
symptoms (it took me a long time to find one that matched the symptoms
-- it could be another one, I sure as heck didn't try to look at every
single CCSID available on the system)
And the way you have it coded right now (with setCCSIDs(1208:0), that
is) can be problematic, too.. why? Because there might be OTHER
characters that are different in CCSID 37 from CCSID 1137. You've fixed
the brackets by hard-coding them to their hex values... but what about
anything else that differs between 37 and 1137? You just haven't run
into them yet!
Worse, you have HTTP_setCCSIDs() telling it that your code is in CCSID
0. 0 is a special value that means "the job's current CCSID" so if you
run this in a job that's a different CCSID, it'll break again. For
example, if run from a job with CCSID 285 (UK), it'll expect the open
bracket to be x'B1' and you've hard-coded it to x'BA'. So if you are
going to hard-code the hex values of the brackets, I suggest ALSO
hard-coding the CCSID to 37.
But a better suggestion is to create your data in Unicode. RPG natively
supports UCS-2, so if you code UCS-2 in your program and tell HTTPAPI to
translate the UCS-2 (13488) to UTF-8 (1208) you won't have problems.
Do keep in mind that your terminal and your job have mismatched CCSIDs,
so don't attempt to type the bracket characters by hand, instead use the
Unicode hex values.
D var_LBracket C const(u'005b')
D var_RBracket C const(u'005d')
D SOAP S 5000C VARYING
/free
SOAP = %ucs2('<?xml version="1.0" encoding="UTF-8"?>'
+ '<soapenv:Envelope'
+ '
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"'
+ ' xmlns:dom="http://dom.w3c.org">'
+ '<soapenv:Header/>'
+ '<soapenv:Body>'
+ '<dom:performAction>'
+ '<!')
+ var_LBracket + %ucs2('CDATA') + var_LBracket
+ %trim(%ucs2(var_XmlMsg))
... etc ...
HTTP_setCCSIDs(1208: 13488);
Switching to using Unicode isn't really that painful, and you don't have
to worry about the hex values changing in Unicode. The hex values will
be consistent everywhere in the world.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------