GregTomkins
Active Member
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.
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.