Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Unicode : Chinese

Former Member
0 Likes
1,432

Hi ALL ,

Recently we moved to Unicode , and we are facing problem with an interface program for citybank

citybank -cityDirect specification is based on the field position in the flat file,it identifies fields from the field position.

File is downloaded to flat file with fields in the exact position , as it is specified in the internal table/ structure field length declaration .

<b>The issue .</b>

In Unicode system, the format of the file downloaded is disturbed because of Chinese characters in the file .

This is because Unicode system considers the length of a Chinese character as 1, even though it occupy 2 spaces/places compared to English ( in the flat file /Notepad ).

Ex:

ab ab ab ab

&#28023; &#40784; &#23572; &#31639; May be chinese is big and it is of 2 bytes where as english is 1 .

So when the user download the file in ANSI, the field length of field NAME1 ( which hold Chinese characters ) in the text file is increasing , and the entire file format is getting disturbed .

I know, I can count the bytes ,find out Chinese chr in the string , adjust the field length dynamically . But this does not seem to be standard solution.

Did anybody face this problem before?

Thanks for any reply ,

Hi ALL ,

Recently we moved to Unicode , and we are facing problem with an interface program for citybank

citybank -cityDirect specification is based on the field position in the flat file,it identifies fields from the field position.

File is downloaded to flat file with fields in the exact position , as it is specified in the internal table/ structure field length declaration .

<b>The issue .</b>

In Unicode system, the format of the file downloaded is disturbed because of Chinese characters in the file .

This is because Unicode system considers the length of a Chinese character as 1, even though it occupy 2 spaces/places compared to English ( in the flat file /Notepad ).

Ex:

ab ab ab ab

&#28023; &#40784; &#23572; &#31639; May be chinese is big and it is of 2 bytes where as english is 1 .

So when the user download the file in ANSI, the field length of field NAME1 ( which hold Chinese characters ) in the text file is increasing , and the entire file format is getting disturbed .

I know, I can count the bytes ,find out Chinese chr in the string , adjust the field length dynamically . But this does not seem to be standard solution.

Did anybody face this problem before?

Thanks for any reply ,

8 REPLIES 8
Read only

Former Member
0 Likes
1,039

Hi,

Try using

SET LOCALE LANGUAGE lg.

Read the documentation for SET LOCALE for more details..

Thanks,

Naren

Read only

Former Member
0 Likes
1,039

please read the question

Thanks any way for your reply.

Read only

Former Member
0 Likes
1,039

Hi,

Search in SDN forum with the keyword Unicode...I am getting lot of forums regarding those..

Thanks,

Naren

Read only

0 Likes
1,039

I did , but nothing relevant.

Thanks

Read only

Former Member
0 Likes
1,039

Hi,

Try with the key word Chinese..

Thanks,

Naren

Read only

0 Likes
1,039

Thanks , I did all searches before posting , even in customer market place.

Read only

Former Member
0 Likes
1,039

hello Freney,

i have faced the same issue for russia..wht i did for tht is i translated the Russian Cyrillic Characters into LAtin characters and then moved them to table ...

now thing is tht u have to code how to convert the Chineese characters into latin characters..i m sure once this is done it will work..

amit

Read only

0 Likes
1,039

Hi,

I don't understand fully: If you download using unicode characters then all characters regardless of chinese or not should occupy 2 bytes. How do you change encoding within the record?

It won't be possible to convert to latin without losing information.

Regards,

Clemens