Kbase P150919: Cannot display Euro symbol in OpenEdge 10 with GB2312
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/05/2010 |
|
Status: Verified
SYMPTOM(s):
Cannot display Euro symbol in OpenEdge 10 with GB2312
Start 'prowin32.exe -cpinternal GB2312 -cpstream GB2312'
In the started procedure editor, the Euro symbol is displayed correctly using the test program below as an example.
However, run the program, the Euro Symbol can not be displayed properly. It only displayed as a 'square/rectangular shape' depends on the font used.
Sample Code:
DEFINE VARIABLE iD AS INTEGER NO-UNDO.
DEFINE VARIABLE cD AS CHAR NO-UNDO.
MESSAGE SESSION:STARTUP-PARAMETERS SESSION:CHARSET VIEW-AS ALERT-BOX.
iD= ASC("?").
cD= CHR(ASC("?")).
DISPLAY iD
UPDATE cD.
Can display Euro symbol in Progress 9.1x with GB2312.
FACT(s) (Environment):
Windows XP (English OS) is set up as: Control Panel-> Open Regional and Language Options -> Advanced tab -> Language for non-Unicode programs -> Chinese (PRC).
Other applications like Word, Wordpad and Notepad can display the Euro symbol correctly.
Run 'proenv> chcp' returns: Active code page: 936
Windows Operating System was using a code page of 936 which has Euro at 0x80
Windows
OpenEdge 10.x
CHANGE:
Upgrade from Progress 9.1x to OpenEdge 10.
CAUSE:
The change in behavior is due to the Unicode Client support in OpenEdge 10. Euro symbol does not exist in GB2312. The expectation - display Euro symbol with GB2312 is based on incorrect assumptions.
On Windows, pre-10.0A, we called the ANSI variants of the Win32 API functions to display and input text. We pass the data from -cpinternal as-is to the Win32 APIs, without conversion. If there is a mismatch between -cpinternal and the Windows codepage, then incorrect data can be displayed and retrieved from the Win32 APIs. When has 936 as Windows codepage, as this is the MS extension of GB2312, and the closest MS provide to GB2312. If the user enters a Euro, Windows interprets this as 0x80 in 936 because Euro is defined in 936. This is passed back to the Progress client as 0x80, as there is no codepage conversion done. We store it as 0x80, and when we display it, we pass it to the Win32 API, which treats it as Euro. However, if we were to convert this to UTF-8, a Euro does not exist in GB2312, this conversion will fail.
For Linux/UNIX, there is a conversion between -cpinternal and -cpterm (-cpterm = -cpstream if -cpterm is not defined). If -cpinternal and -cpterm are both GB2312, there is no conversion, bytes are sent as-is from the UNIX side of the telnet session to the terminal, most likely a terminal emulator. It is then up to the terminal to intepret those bytes as characters. This depends on the terminal emulator, and how it has been configured. If the terminal emulator is configured to treat the data as 936, then it will display Euro for 0x80 (for the same reasons Progress pre-10.0A did).
FIX:
The workaround is to use -cpinternal UTF-8 or CP936 instead.
If using -cpinternal CP936 on Windows, then please contact Progress Technical Support for additional assistance with this issue.