I am using the following piece of code to send an open request to the server side while using the Netscape browser :
strPage="remotedata.asp?First="+"日本語"+"&Second=" +"すこいい";
if (browser_name.indexOf("Netscape")!=-1)
{
var oXML=new XMLHttpRequest();
oXML.open("GET",strPage,false);
oXML.send(null);
document.write(oXML.responseText);
}
Notice - Japanese strings are passed as parameters. In the server side (ASP/VB), we extract the parameters passed (Using Request.QueryString) and return it back to the client in the Response.
The Netscape browser character setting is "Shift-JIS" and the Response CharSet setting is also "Shift-JIS".
For Japanese strings passed as parameters, junk characters are returned in the Response which ultimately causes the Netscape browser to crash.
(For IE browser, the same functionality is achieved using ActiveXObject, and the Japanese strings are correctly returned.)
On the server side, IIS is being used as the Web Server.
Could someone please guide us how to successfully return Japanese strings in Netscape using the XMLHttpRequest call ? Has anyone experience similar problems before ?
But why not just use a hidden form and submit it to a hidden iframe and then from the iframe, retrieve the result? This will solve cross-browser issues.
Then set the value of the 2 fields and submit the form:
Code:
function remoteCall(first, second){
var f=document.remoteForm;
f.First.value=first;
f.Second.value=second;
f.submit();
}
function displayOutput(str){
alert(str);
//...
}
This is because Mozilla powered browsers follow the standard. URI's are US-ASCII encoded. There is no way to change this, and there is no standard way of escaping non-US-ASCII characters defined. The only escaping method defined is for US-ASCII characters that have special meanings.
There are three solutions to this:
One is to use UTF-8 escaped using the mentioned US-ASCII method and hoping the reciever allows that - most do, it's an emerging de facto standard. The URN standard, but neither URI nor HTTP standard, specifies a demand for allowing the escaping of multibyte UTF-8 characters using a series of the 8-bit escapes defined for US-ASCII characters.
In ECMAScript, this type of escaping is provided by the encodeURIComponent function.
As for using the escape function of ECMAScript as Glenn suggested, ECMA defines a syntax like so: %unnnn for escaping Unicode code points above 255, but this is not in the HTTP, URI or URN standards and probably has a very low support level server side, so I wouldn't use it. Use the UTF-8 method instead.
Change it from 'GET' to 'POST', and use the response body to send the characters.
We have tried using escape() as Glenn suggested and encodeURIComponent() as Liorean has suggested but they have not helped.
Even using POST, as suggested by Liorean in the call oXML.open("POST",strPage,false) has not provided the desired results.
Using simple HTML form and POST, SUBMIT in a Netscape browser, we have been able to receive the Japanese strings passed as parameters, correctly in the server side (where RemoteData.asp is). However, the problem seems to occur with the use of XMLHttpRequest. So, does Glenn suggest replacing the use of XMLHttpRequest with the FORM he has suggested ?
Glen, in your solution the response can take time and the response text cannot be captured in the same function where the form is submitted. The response text can only be recieved on the "onload" event of the iframe. Hence directly changing the current function might not be a solution.
Can anything else be done so that the XMLHttpRequest call is substituted without changing any other functionality?
Location: Los Angeles, CA Original Location: Philippines
Posts: 10,241
Thanks: 0
Thanked 112 Times in 111 Posts
Quote:
Originally Posted by Suraj
Glen, in your solution the response can take time and the response text cannot be captured in the same function where the form is submitted. The response text can only be recieved on the "onload" event of the iframe. Hence directly changing the current function might not be a solution.
Thanks,
Suraj
Can you explain again why my suggestion might not work for you? I didn't quite get it. What my suggestion does is when the response text is generated in the iframe, the iframe (when it loads) invokes a function in the parent window passing the response text. You just put the code in that function whatever the parent window wants to do with the response.
Code:
function displayOutput(str){
alert(str);
//do what you want to do with str, probably setting it to innerHTML...
//document.getElementById('targetElementId').innerHTML=str;
}
We have tried using escape() as Glenn suggested and encodeURIComponent() as Liorean has suggested but they have not helped.
Straight off the bat, I didn't think they would. You need to make sure that your server decodes the encoded URI on the server.
Quote:
Even using POST, as suggested by Liorean in the call oXML.open("POST",strPage,false) has not provided the desired results.
Well, did you also do the other things mentioned: have you turned the URI query string into a form submission string that you give as an argument to the XMLHttpRequest.prototype.send method, and made the corresponding change in the server side to read the POST data?
Quote:
Can anything else be done so that the XMLHttpRequest call is substituted without changing any other functionality?
As mentioned, you need to change your server side script accordingly, and send it as a request body instead of URI string.
if (browser_name.indexOf("Netscape")!=-1)
{
var oXML=new XMLHttpRequest();
oXML.open("GET",strPage,false);
oXML.send(null);
document.write(oXML.responseText);
}
[Server Side - VB Script]
<%@CodePage=65001%>
Response.CharSet="UTF-8"
.
.
.
....and Request.QueryString was used to return the response to the client.
This time, Japanese characters were correctly received on the client side.
From this I understand that
1. It is necessary to set the code page to 65001 to support unicode in both client and server side.
2. It is necessary to set the Response Char Set to UTF-8 both in the Client and Server side (??????)
3. It is necessary to do encodeURIComponent() to the parameters being passed from the client side.
4. We did not have to do a decodeURI on the server side (??). Anyways, there is no decodeURIComponent supported in ASP/VB script.
5. IE requires none of the above and that it is enough to set CodePage=932, Response.CharSet("Shift-JIS"). It is not necessary to do a encodeURIComponent.
*This is what I have understood from the solution obtained today though I am not sure if my assumptions are correct. Please let me know your views so that I can take better precautions.
I am a bit confused how to share the code for Netscape and IE in the same file with all the above conditions.
Glenn: In your example, shouldn't setRequestBody be oXML.setRequestBody? I assume it's a method of the XMLHttpRequest object, not a global function.
Suraj: This code shouldn't have any meaning on the client, unless you have defined the Response and session objects elsewhere in the client side script:
Code:
session.CodePage=65001
Response.CharSet="UTF-8"
Second, you should be able to use the same syntax for most browsers, with only a slight fork for iew. In other words:
Code:
var
oXML=typeof XMLHttpRequest!='undefined'?
new XMLHttpRequest:
false;
if(!oXML)
try{
oXML=new ActiveXObject('MSXML2.XMLHTTP.5.0');
}catch(e){
try{
oXML=new ActiveXObject('MSXML2.XMLHTTP.4.0');
}catch(e){
try{
oXML=new ActiveXObject('MSXML2.XMLHTTP.3.0');
}catch(e){
try{
oXML=new ActiveXObject('Microsoft.XMLHTTP');
}catch(e){
throw new Error('XMLHttpRequest object does not exist');
}
}
}
}
/*
From this point, you should be able to use the oXML object in the same
way for iew, moz, saf and op7.6. Thus, all the necessary code forking
has already been done.
*/
As for the UTF-8 decoding in VBScript in ASP, that shouldn't be too hard to write. If you look at the UTF-8 encoding, it works like this:
I'm a bit surpirsed that VBScript doesn't have an UTF-8 decoder present, but I think VBScript shouldn't have any problem decoding that, if you write a UTF-8 decoder function. Anyway, setting the server up to handle the request as UTF-8 should make the decoder unnecessary.
Oh, and another thing: Netscape is dead. It might not look that way, but it is. Mozilla Firefox is the successor. It's user agent string does not contain 'Netscape'. Also, both Safari and Opera support the XMLHttpRequest object in recent versions. So, you're doing this thing entirely wrong:
Code:
if (browser_name.indexOf("Netscape")!=-1)
Look at the code forking I wrote earlier in this response to see how to properly handle the detection of what type of XMLHttpRequest object to use.
Location: Los Angeles, CA Original Location: Philippines
Posts: 10,241
Thanks: 0
Thanked 112 Times in 111 Posts
Quote:
Originally Posted by liorean
Glenn: In your example, shouldn't setRequestBody be oXML.setRequestBody? I assume it's a method of the XMLHttpRequest object, not a global function.
No. I only made up that function. I really don't know if there's already a built-in method for that but when I did alert(oXML.setRequestBody) and other possible method names, it returned undefined.
Could you please explain the part about UTF decoding (the table that you have mentioned) ? I did not get it exactly.
I am sorry for asking basic questions but am a novice in web programming just about finding my feet.
Glenn, thanks for your point about Inner HTMLs and my team-mates do agree that is a great idea - but as the code is the product code, we are not supposed to change the architecture right now and have to do with the XMLHttpRequest solution.
Liorean, extracting browser information still contains the string Netscape. In what context did you say that it would not contain Netscape ?
Thanks,
Suraj
Location: Los Angeles, CA Original Location: Philippines
Posts: 10,241
Thanks: 0
Thanked 112 Times in 111 Posts
Quote:
Originally Posted by Suraj
Liorean, extracting browser information still contains the string Netscape. In what context did you say that it would not contain Netscape ?
Thanks,
Suraj
liorean was talking about Mozilla Firefox which is the successor of Netscape 7. It's better to use object detection as liorean suggested rather than relying on user agent strings. Not only Netscape supports XMLHttpRequest object.
Before you post, read our: 
Using XMLHttpRequest for Netscape
