4fd form appears to have broken chinese text when using gsform to convert.

Technote (troubleshooting)


Problem(Abstract)

customer using gsform to convert 4gl form(*.per) to Genero form(*.4fd), but some Chinese character got garbled result.

Cause

original 4gl file.



using gsform -import sam.per to convert sam.4fd

and then using vi to check 4fd file, all Chinese character is garbled.


Resolving the problem

The converted .4fd file is encoded in UTF-8 which, when visualized on a terminal that set to Big5 , appears as nonsense. Now, 4fd files are not meant to be edited with vi but with "form designer" inside Genero studio.


4fd files are all encoded in UTF-8, but when shown inside Form Designer or when the program runs and visualizes the form, the strings inside the form are automatically turned from UTF8 to the codeset used by the program (set by LANG, for example big5) so they are shown properly.

The conclusion is that the encoding of the converted form shouldn't be a problem and the file shouldn't be manually edited with vi.
If. for some reason, it has to edited with vi, then this need to be done from a terminal emulator set to utf8.

Some more details

The customer uses big5 as encoding for the applications and the database. On AIX setting LANG=Zh_TW without specifying the codeset assumes the default codeset for the region (big5 in this case)

The terminal emulator, the screenshots come from, is almost certainly set to interpret text as big5 , and that's why the source .per file (encoded in big5) looks good.

The reason why the .4fd file looks bad when opened with vi is that it's encoded in UTF-8.

Cross reference information
Segment Product Component Platform Version Edition
Information Management Informix Tools Informix Genero Linux, Windows 2.4, 2.32 Compiler, Developer

Rate this page:

(0 users)Average rating

Document information


More support for:

Informix Tools
Informix Genero

Software version:

2.4, 2.32

Operating system(s):

Linux, Windows

Software edition:

Compiler, Developer

Reference #:

1617006

Modified date:

2012-11-12

Translate my page

Machine Translation

Content navigation