Re: Allowing accented characters in the database

On 2023-09-18 11:42 a.m., Patrik Schindler wrote:

... You said that UTF-8 in database files is (mainly) a problem because of RPG vs. alphanumeric CCSIDs. But from the table above I see UTF-8 is said to match CCSID 1208, which only has digits. Currently, the database PFs are used solely over ODBC. No local 5250 applications. Yet. Maybe someday this might become a thing.

May I kindly ask you to elaborate about this alphanumeric thing for RPG?

Thanks!

In addition, I was under the impression that there is a "UTF-8 EBCDIC" encoding. AFAIK UTF-8 low positions are ASCII compatible and I assumed there is a similar, backwards compatible entity for EBCDIC. Apparently I assumed wrong. :-)

One more thing… I can compile a PF with CCSID(1208) character fields to an object, but not CCSID(1200) which should be UTF-16 according to the above table. This fails due to CPD7678. The help text leaves me puzzled. Is this just a badly worded "not supported"? Which means my only meaningful option is CCSID(1208).

Thanks for helping. This topic is highly confusing.

:wq! PoC

Hi Patrik,

Sorry for the confusion about "alphanumeric CCSIDs". I meant to refer to CCSIDS for fields defined with the alphanumeric data type (type A in DDS).

UTF-8 fields are defined as type A with CCSID(1208).

For UTF16, the data type is G for DDS. (RPG uses type C for UTF16. RPG only uses 'G' for true DBCS CCSIDs such as Chinese or Japanese.)

A R REC
A UTF8 5A CCSID(1208)
A UTF16 5G CCSID(1200)

DSPFFD shows this:

Field Level Information
Data Field Buffer Buffer Field Column
Field Type Length Length Position Usage Heading
UTF8 CHAR 5 5 1 Both UTF8
Coded Character Set Identifier . . . . . : 1208
UCS2 or Unicode conversion . . . . . . . : *CONVERT
Normalize data . . . . . . . . . . . . . : No
UTF16 GRAPHIC 5 10 6 Both UTF16
Coded Character Set Identifier . . . . . : 1200
UCS2 or Unicode conversion . . . . . . . : *CONVERT
Normalize data . . . . . . . . . . . . . : No