[ 
https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872188#action_12872188
 ] 

Naveen Ravindra commented on TRINIDAD-1073:
-------------------------------------------

Hello All,

This issue is observed with Websphere-Trinidad stack.

A resolution for this issue is to encode the special characters before POST 
request. If the method is POST and the data passed to the send() is a string, 
the data MUST be encoded as UTF-8 for transmission. 

You need to modify file XMLRequest.js found under
1. trinidad-impl-XXX.jar\META-INF\adf\jsLibsDebug\xhr
2. trinidad-impl-XXX.jar\META-INF\adf\jsLibs\xhr 

The file which would be downloaded depends on the mode configured in web.xml 

<context-param>
<description>

Apache Trinidad by default obfuscates the Javascript it delivers to the client, 
as well as stripping comments and whitespace. This dramatically reduces the 
size of our Javascript download, but also makes it tricky to debug the 
Javascript. This flag can be set to true to turn off the obfuscation.

Always set to false in a production environment.
</description>
<param-name>org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT</param-name>
<param-value>true</param-value>
</context-param>
 

Below are the changes required:

1. Add the below function to XMLRequest.js

function encodeCharacters(string) {
                        string = string.replace(/\r\n/g,"\n");
                        var utftext = "";
                        for (var n = 0; n < string.length; n++) {
                                    var c = string.charCodeAt(n);
                                    if (c < 128) {
                                                utftext += 
String.fromCharCode(c);
                                    }
                                    else if((c > 127) && (c < 2048)) {
                                                utftext += 
String.fromCharCode((c >> 6) | 192);
                                                utftext += 
String.fromCharCode((c & 63) | 128);

                                    }

                                    else {

                                                utftext += 
String.fromCharCode((c >> 12) | 224);
                                                utftext += 
String.fromCharCode(((c >> 6) & 63) | 128);
                                                utftext += 
String.fromCharCode((c & 63) | 128);

                                    }
                        }
                        return utftext;
            }
 

2. In TrXMLRequest.prototype.send related function change 
xmlhttp.send(content); to xmlhttp.send(encodeCharacters(content)); 

Make sure you clear the temporary Internet files before evaluating the 
resolution. 

Regards,
Naveen

> Character encoding problem with PPR on IBM WebSphere 6.0
> --------------------------------------------------------
>
>                 Key: TRINIDAD-1073
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1073
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>    Affects Versions: 1.0.7-core
>         Environment: MyFaces 1.1.5
> IBM WebSphere 6.0
> Windows XP SP2
>            Reporter: Vadim Dmitriev
>
> Input fields updated via PPR replace cyrillic characters with question marks. 
> There is no encoding problems if update is performed with ordinary form 
> submit.
> Simple testcase:
> create JSF page with tr:showDetailHeader containing tr:inputText. Type some 
> cyrillic characters in the input field. Close/open detailheader. As a result 
> cyrillic chars in the inputText will be replaced with question marks.
> There is no problem with encoding whatsoever if that showDetailHeader is 
> updated by ordinary update (navigation from/to that page, for example).
> This problem is specific to WebSphere 6.0 (maybe 6.1 too, never had a chance 
> to check it). I tried the same testcase on OC4J 10.3.3.2 and everything went 
> fine.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to