|
Brad,
I think that'll work as far as storing the data in the database. I must
admit that I'm not 100% sure as I've not seen someone use UTF-8 in a DB2
for i database table before. Usually on IBM i, people use UCS-2 or
UTF-16. (CCSID 13488 or CCSID 1200, defined as graphic.)
In the latest & greatest RPG, you can declare your RPG field as CCSID 1208
(UTF-8) and then when you assign the value to a UCS-2/UTF-16 field (data
type C in RPG) it will auto-convert, which is really nice. Then you could
write that to the database table. For older releases, I'd use iconv() to
convert. (Or stick another routine into YAJL that returns the data in
UTF-16).
But, I would think the way you're doing it would work okay with a UTF-8
field... just not able to confirm that.
Java already uses unicode internally -- so on that side of things it's
just a matter of making sure that the SQL driver isn't assuming the data is
EBCDIC, but is using the CCSID defined in the table. Not sure how to do
that exactly, either, since I avoid Java like the plague.
-SK
On 6/15/2016 3:07 PM, Bradley Stone wrote:
Here's what I believe should work (still waiting to hear).This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
Define the field in the table as character (in this case its variable)
with
CCSID 1208.
The RPG code is as follows:
val = YAJL_object_find(node:'value');
exec sql Declare :value VARIABLE CCSID 1208;
value = %str(yajl_get_string_utf8(val));
exec sql
insert into file (value)
VALUES(:value);
Before adding the SQL Declare :value VARIABLE CCSID 1208 there was some
odd
conversion still going on that was corrupting the data I was reading in as
straight 1208. Once adding that (found it in a thread deep in the net)
things seemed to work fine.
Still waiting for confirmation from my customer, but the hex values look
like they should.
Brad
www.bvstools.com
On Wed, Jun 15, 2016 at 9:07 AM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:
Brad,
iNav or ACS Run SQL Scripts should be able to display the PF data...
Websphere (Java WAR?) should also display it correctly.
Charles
On Wed, Jun 15, 2016 at 9:42 AM, Bradley Stone <bvstone@xxxxxxxxx>
wrote:
Ok, I think I need to ask this a different way.
to
If I'm reading in UTF-8 data from a JSON file and the values could be
any
language, what would be the proper steps for reading that data in (as
raw
UTF-8, so it isn't converted to the jobs CCSID, or let it conver), the
field in the Pf that I want to store the data (defined as 1208?)
I've confirmed reading data in as 1208 raw data and storing it in a PF
field declared as 1208 seems to work. Of course it all looks like
"garbage" using query or sql.
But the issue is now a client wants to take this data and display it on
a
webpage using websphere I believe. So I though, how does websphere know
convert the data and display it properly (ie, english will be english,web
Chinese, Russian, etc)? They claim it is showing up as garbage on the
page.wrote:
On Mon, Jun 13, 2016 at 2:59 PM, Bradley Stone <bvstone@xxxxxxxxx>
Thanks, Barbara. I will look into things... Thanks!
On Mon, Jun 13, 2016 at 12:01 PM, Barbara Morris <bmorris@xxxxxxxxxx>
wrote:
On 6/10/2016 3:48 PM, Bradley Stone wrote:
Ok, so I set up the field with CCSID 1208 in the DDS. I didn't
specify
the
*NORMALIZE option. From what I understand, this will fix anyRPG
non-corresponding hex values to the closest match available?
...
We shall see if this will help. But I'm wondering if there are any
D-Spec keywords one can use so that when data is read in from this
field
it
is automatically converted to the JOB's CCSID? Or is iConv (oranother
conversion API) required?
that
Brad, what is your job CCSID? My understanding (and experience) is
CCSID 1208 data (and all other alphanumeric data) is converted to the
job
CCSID automatically by database unless the job CCSID is 65535. When
the
job
CCSID is 65535, no alphanumeric data is converted to the job CCSID.
your
At least, that's true when RPG opens the file prior to 7.2, and by
default from 7.2 on. Starting in 7.2, you can code DATA(*NOCVT) in
F
spec to cause the file to be opened with no conversion to the job
CCSID.
You could also code OPENOPT(*NOCVTDATA) to have that be the default
for
all
database files.
would
Also in 7.2, you could code DATA(*CVT) on your F spec, and ensure the
program field matching your 1208 field is in the job CCSID. Then RPG
do a runtime check, and if the job CCSID was 65535, it would convert
the
1208 data in the buffer to your field's job CCSID.
that
DATA(*CVT) is the default, but RPG needs some indication in the code
you want this new support. The old support wasn't necessarily correct,
but
we know that people coded workarounds that we can't break.
CCSID(*EXACT)
As long as you code the the DATA keyword on your file, or
in your H spec, or OPENOPT(*(no)CVTDATA) in your H spec, or the CCSID
keyword on that field or its externally-described data structure, RPGwill
handle any necessary CCSID conversions when the record is read.
(RPG400-L)
--
Barbara
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
mailing listThis is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
--
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
