-cpstream

[GregTomkins]

I'm having 'French problems' (again) and wondering if anyone can clarify what this parameter does (the documentation is vague). Here's my situation:

1. As I understand it (per jQuery's documentation), XmlHttpRequest always uses UTF-8, even if you explicitly set otherwise in ContentType.

2. Our DB is ISO8859-1.

3. If I set -cpstream on the WS agent to UTF-8, characters sent from WebSpeed to the browser are garbled all over the place. So that seems like a bad idea (though advice on SO is generally 'always use UTF-8', so, I wonder about this).

4. If I set -cpstream to ISO8859-1:

A. Characters from WebSpeed to the browser are OK without having to use CODEPAGE-CONVERT (eg. WebSpeed does it for us).

B. However, characters from the browser to WebSpeed are NOT OK, and must be explicitly converted in ABL using CODEPAGE-CONVERT. This is a debugging observation, not a practical solution.

From poking around, it appears to me that when data goes from the browser to WebSpeed, it is being 'double-converted' somewhere. I don't understand how or why this would be. We don't use CODEPAGE-CONVERT other than in the experimentation that I did here, nor do we do anything special in the browser.

BTW, when I say 'characters' I mean characters such as ó which reside in the range of 128-255. Characters in the 0-127 (English) range are always OK.

Any advice appreciated.

 

[Stefan]

Progress version?
How are you moving data from WebSpeed to the browser? {&OUT}? Is the data packaged as xml or json? If xml how are you creating the xml? How is the encoding of the xml set? Are longchars involved? Are they fix-codepaged?

 

[GregTomkins]

1. 10.2b
2. JSON, created 'by hand'
3. There is no explicit encoding anywhere except where I experimentally added CODEPAGE-CONVERT into our JSON writer.
4. LONGCHAR is used throughout.
5. I don't know what fix-code paged means?

Thanks for thinking about my issue, cheers.

 

[GregTomkins]

Can you or anyone clarify what -cpstream does? I think a value of X would mean that Progress will expect incoming data to be encoded as page X, and that it would convert from X to whatever it uses internally. Then, on output, the reverse. But based on experimentation I don't think that is true, and it seems like input and output are not necessarily treated equivalently. Thanks again.

 

[Stefan]

I think you are correct in your understanding of -cpstream, but your data /may/ already have been garbled in the longchar stage.

The fix-codepage statement explicitly sets the codepage of a longchar, otherwise it is implicitly set.

fix-codepage( lcc ) = "utf-8".