[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'



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
-----------------------------------------------------------------------