|
Richard,
If your data is already in UTF-8, there's no need to call my RPG
wrapper (yajl_buf_load_tree) you can simply call the C routine
directly (yajl_tree_parse)
-SK
On 4/3/17 9:01 AM, la Croix, Richard
wrote:
Thanks Scott,
>> http_setOption('network-ccsid': '1208');
This is exactly what I was looking for. Somehow I misunderstood
the meaning of 'network-ccsid'. :-(
>> But, there are hundreds of thousands of characters that
simply don't exist in EBCDIC
I know, but luckily I currently have to deal with only a tiny
subset and they all have EBCDIC equivalents (western
characters). For that setting the network ccsid and passing the
variable to yajl_buf_load_tree works fine.
However at some later point I will have to store untranslated
Unicode data too. I tried passing an untranslated string to
yajl_buf_load_tree (by setting 'local-ccsid': '1208') and get
untranslated out, but that didn't work. I assume because
yajl_buf_load_tree expects EBCDIC input. Is there an option to
tell yajl to process Unicode directly?
I agree with you that the 'new way' looks easier.
Regards,
Richard
-----Ursprüngliche Nachricht-----
Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von
Scott Klement
Gesendet: Freitag, 31. März 2017 21:09
An: FTPAPI/HTTPAPI mailing list
Betreff: Re: [Ftpapi] Problem with utf-8 data received using
new http_string() procedure and YAJL.
Richard,
It's not clear to me what you are looking for. Do you want
HTTPAPI to
assume the remote data is UTF-8 (by default it assumes
ISO-8859-1)...
If so, you can do:
http_setOption('network-ccsid': '1208');
In this case, your RPG variable will get (by default) it's
data in the
EBCDIC CCSID of your job, but it will be translated from UTF-8
rather
than ASCII. That should solve the issue for the particular
characters
in your examples.
But, there are hundreds of thousands of characters that simply
don't
exist in EBCDIC. What if you wanted the data to be returned to
your
program un-translated, so that it is still in the original
UTF-8? In
that case you could do this:
http_setOption('network-ccsid': '1208');
http_setOption('local-ccsid': '1208');
In this case, since the two CCSIDs are the same, it will not
translate
the data at all.
The "old" way to do this is with http_setCCSIDs() (which will
also still
work). For example, the older way to set the network CCSID is:
http_SetCCSIDs(1208: 0);
or to set both network/local so that there's no translation:
http_setCCSIDs(1208: 1208);
So that does the same thing as the above... I just think
http_setOption() is easier to read.
-SK
On 3/31/2017 11:11 AM, la Croix, Richard wrote:
>
> Hello all,
>
> I am having a problem with utf-8 data received using the
new
> http_string procedure.
>
> When I use http_stmf() I can first set the ccsid for the
output file
> to 1208 (using http_setOption('file-ccsid': '1208')), as
JSON data
> should always be utf-8 (ccsid 1208).
>
> I can then process the file with yajl_stmf_load_tree()
and the utf-8
> strings are converted correctly.
>
> I would like to skip the detour via the ifs and directly
process the
> string as received using the http_string() procedure.
However when I
> pass the output from http_string() to
yajl_buf_load_tree() the JSON
> fields containing utf-8 data come out wrong (e.g.
‘Randonnée’ vs.
> ‘Randonnée’).
>
> As far as I can see, there is no equivalent to setting
> http_setOption('file-ccsid': '1208') for directly
receiving utf-8 data
> into a variable.
>
> Am I missing something? Any ideas?
>
> Best regards,
>
> Richard
|