Kbase P136574: Extended characters are displayed incorrectly in XML when loading a Longchar into an X-Document and
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
25/08/2009 |
|
Status: Unverified
SYMPTOM(s):
Extended characters are displayed incorrectly in XML when loading a Longchar into an X-Document and saving
Extended characters are displayed incorrectly in XML when loading a Longchar into an X-Document and saving
Resulting XML file does not contain the correct or expected characters
If the same XML document is created programmatically using the XML DOM then the character is displayed correctly
Using -CPINTERNAL -CPSTREAM set to ISO8859-1 or 1252 for the session
Setting -CPINTERNAL UTF-8 -CPSTREAM UTF-8 results in the correct characters being
FACT(s) (Environment):
Adding extended Western characters to a Longchar variable
Longchar is loaded into an X-Document
X-Document is saved to file using the SAVE method
Desired character is present in ISO8859-1 or 1252 code-pages
Using FIX-CODEPAGE method on Longchar does not help
Setting -CPSTREAM to UTF-8 does not help
Setting ENCODING of XML to UTF-8 or session or O/S code-page does not help
Using CODEPAGE-CONVERT on the Longchar does not help
OpenEdge Category: Language (4GL/ABL)
OpenEdge 10.x
All Supported Operating Systems
CAUSE:
Bug# OE00176229
CAUSE:
The client tells the parser to use the -CPINTERNAL code-page. The parser defaults to UTF-8 when loading the document from a Longchar or memptr. When the XML document does not have an encoding setting, the default is supposed to be UTF-8 but because the client thinks the parser will use -CPINTERNAL on the LOAD, no conversion occurs from -CPINTERNAL to UTF-8 before passing it to the parser.
FIX:
To workaround the issue, set the encoding in the XML and the code-page for the Longchar to ISO8859-1 or 1252. The encoding matches the Longchar code-page and the parser will read the data properly, since the client is not converting the data to the code-page that the parser defaults to.