Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 12 of 12
  1. #1
    New Coder
    Join Date
    Dec 2004
    Posts
    20
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Question Using XMLHttpRequest for Netscape

    Hi,

    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 ?

    Thanks,
    Suraj

  • #2
    Supreme Master coder! glenngv's Avatar
    Join Date
    Jun 2002
    Location
    Philippines
    Posts
    11,075
    Thanks
    0
    Thanked 256 Times in 252 Posts
    Try escaping the characters:

    strPage="remotedata.asp?First=" + escape("日本語") + "&Second=" + escape("すこいい");

    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.
    Code:
    <form name="remoteForm" action="remotedata.asp" target="hiddenFrame">
    <input type="hidden" name="First" value="" />
    <input type="hidden" name="Second" value="" />
    </form>
    <iframe name="hiddenFrame" src="about:blank" style="display:none; width:0px; height:0px"></iframe>
    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);
      //...
    }
    remotedata.asp should output something like this:
    Code:
    <html>
    <body onload="parent.displayOutput(document.getElementById('output').innerHTML)">
    <div id="output">Output goes here...</div>
    </body>
    </html>
    Last edited by glenngv; 12-07-2004 at 06:09 AM.
    Glenn
    ____________________________________

    My Blog
    Tower of Hanoi Android app (FREE!)
    Tower of Hanoi Leaderboard
    Samegame Facebook App
    vBulletin Plugins
    ____________________________________

  • #3
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    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.
    • Use a form, like Glenn suggests.
    Last edited by liorean; 12-07-2004 at 11:16 AM.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #4
    New Coder
    Join Date
    Dec 2004
    Posts
    20
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi Glenn and Liorean,

    Thanks for your replies :

    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?

    Thanks,
    Suraj
    Last edited by Suraj; 12-08-2004 at 09:10 AM.

  • #5
    Supreme Master coder! glenngv's Avatar
    Join Date
    Jun 2002
    Location
    Philippines
    Posts
    11,075
    Thanks
    0
    Thanked 256 Times in 252 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;
    }
    Glenn
    ____________________________________

    My Blog
    Tower of Hanoi Android app (FREE!)
    Tower of Hanoi Leaderboard
    Samegame Facebook App
    vBulletin Plugins
    ____________________________________

  • #6
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Quote Originally Posted by Suraj
    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.
    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?
    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.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #7
    Supreme Master coder! glenngv's Avatar
    Join Date
    Jun 2002
    Location
    Philippines
    Posts
    11,075
    Thanks
    0
    Thanked 256 Times in 252 Posts
    Does your POST request look like this?
    Code:
    ...
    oXML.open("POST", "http://yourdomain.com/remotedata.asp", false); 
    var body = '';
    var boundary = "Boundary_for_ProductNameOrAnything_" + new Date().getTime() + ";";
    body += setRequestBody("First", "日本語", boundary);
    body += setRequestBody("Second", "すこいい", boundary);
    body += "--" + boundary;
    oXML.setRequestHeader("Content-Type","multipart/form-data; boundary="+boundary+"; charset=SHIFT_JIS");
    oXML.send(body);
    alert(oXML.responseText);
    ...
    
    function setRequestBody(elementName, elementValue, boundary)
    {
    	var body = "";
    	body += "--" + boundary + "\r\n";
    	body += "Content-Disposition: form-data; name=\"" + elementName + "\"" + "\r\n\r\n";
    	body += elementValue + "\r\n"; 
    	return body;
    }
    Glenn
    ____________________________________

    My Blog
    Tower of Hanoi Android app (FREE!)
    Tower of Hanoi Leaderboard
    Samegame Facebook App
    vBulletin Plugins
    ____________________________________

  • #8
    New Coder
    Join Date
    Dec 2004
    Posts
    20
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Thanks Glenn and Liorean,

    For Netscape, the problem was solved by doing the following :

    [Client Side - Javascript]

    session.CodePage=65001
    Response.CharSet="UTF-8"

    strPage="remotedata.asp?First="+encodeURIComponent("日本語")+"&Second="+encodeURIComponent("すこいい")

    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.

    Thanks,
    Suraj

  • #9
    Master Coder
    Join Date
    Feb 2003
    Location
    UmeŚ, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    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:
    Code:
    Unicode code point      UTF-8
    ----                    ----
    0000 0000 - 0000 007f   0xxxxxxx
    0000 0080 - 0000 07ff   110xxxxx 10xxxxxx
    0000 0800 - 0000 7fff   1110xxxx 10xxxxxx 10xxxxxx
    0000 8000 - 0007 ffff   11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
    0008 0000 - 007f ffff   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
    0080 0000 - 07ff ffff   1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
    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.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #10
    Supreme Master coder! glenngv's Avatar
    Join Date
    Jun 2002
    Location
    Philippines
    Posts
    11,075
    Thanks
    0
    Thanked 256 Times in 252 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.
    Glenn
    ____________________________________

    My Blog
    Tower of Hanoi Android app (FREE!)
    Tower of Hanoi Leaderboard
    Samegame Facebook App
    vBulletin Plugins
    ____________________________________

  • #11
    New Coder
    Join Date
    Dec 2004
    Posts
    20
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi Liorean,

    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

  • #12
    Supreme Master coder! glenngv's Avatar
    Join Date
    Jun 2002
    Location
    Philippines
    Posts
    11,075
    Thanks
    0
    Thanked 256 Times in 252 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.
    Glenn
    ____________________________________

    My Blog
    Tower of Hanoi Android app (FREE!)
    Tower of Hanoi Leaderboard
    Samegame Facebook App
    vBulletin Plugins
    ____________________________________


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •