A solution to the Chinese coding problem caused by XMLHTTP client interacting with ASP in transmitting XML

Test via system: WinXP Chinese Pro, XML4.0 sp2,c#

Try to XMLHTTP as a client, and then try to interact with the server-side ASP programmer, I think there are very ideas, of course, this is also boasting:). But the most headache is probably the problem of Chinese garbled, looked up a lot of information, MSDN, the Internet, tried a lot of methods are not very effective, fortunately not discouraged, now, the latest simplest solution to the debut:

The header of the XML to be transmitted by the client consists of:

<?xml version= "1.0" encoding= "gb2312"?>

Switch

<?xml version= "1.0" encoding= "Utf-8"?>

The server-side ASP program is sent to the client XML result with the addition of:

Response.ContentType = "Text/xml"
Response.Charset = "gb2312"

The client's program takes a return result with XMLDOM.loadXML (Xmlhttp.responsetext) on it.

============================================================================

The following analysis may be the cause:

This may be the reason why our operating system itself uses UTF-8 encoding.

Write all request.servervariables into a text file and you'll find something like this:

all_http:http_accept:*/*
Http_accept_language:zh-cn
Http_connection:keep-alive
Http_host:localhost
http_user_agent:mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;. NET CLR 1.1.4322;. NET CLR 2.0.50727; INFOPATH.1)
Http_cookie:aspsessionidaqbcsqra=fnehnoccmheccopiokkecefm
http_content_length:94
http_content_type:text/xml;charset=gb2312
Http_accept_encoding:gzip, deflate
Http_cache_control:no-cache

All_raw:accept: */*
Accept-language:zh-cn
Connection:keep-alive
Host:localhost
user-agent:mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;. NET CLR 1.1.4322;. NET CLR 2.0.50727; INFOPATH.1)
Cookie:aspsessionidaqbcsqra=fnehnoccmheccopiokkecefm
content-length:94
content-type:text/xml;charset=gb2312
Accept-encoding:gzip, deflate
Cache-control:no-cache

Appl_md_path:/lm/w3svc/1/root/zdqs
appl_physical_path:c:/inetpub/systems/zds/qry/
Auth_password:
Auth_type:
Auth_User:
Cert_cookie:
Cert_flags:
Cert_issuer:
Cert_keysize:
Cert_secretkeysize:
Cert_serialnumber:
Cert_server_issuer:
Cert_server_subject:
Cert_subject:
content_length:94
content_type:text/xml;charset=gb2312
gateway_interface:cgi/1.1
Https:off
Https_keysize:
Https_secretkeysize:
Https_server_issuer:
Https_server_subject:
Instance_id:1
Instance_meta_path:/lm/w3svc/1
local_addr:127.0.0.1
Logon_User:
Path_info:/zdqs/qury.asp
Path_translated:c:/inetpub/systems/zds/qry/qury.asp
Query_string:
remote_addr:127.0.0.1
remote_host:127.0.0.1
Remote_user:
Request_method:post
Script_name:/zdqs/qury.asp
Server_name:localhost
Server_port:80
server_port_secure:0
server_protocol:http/1.1
server_software:microsoft-iis/5.1
Url:/zdqs/qury.asp
http_accept:*/*
Http_accept_language:zh-cn
Http_connection:keep-alive
Http_host:localhost
http_user_agent:mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;. NET CLR 1.1.4322;. NET CLR 2.0.50727; INFOPATH.1)
Http_cookie:aspsessionidaqbcsqra=fnehnoccmheccopiokkecefm
http_content_length:94
http_content_type:text/xml;charset=gb2312
Http_accept_encoding:gzip, deflate
Http_cache_control:no-cache

Guess one: The encoding used in the network transmission process is gb2312

Then, see the additional MSXML4 SDK in one help: enforcing Character Encoding with DOM

In some cases, a XML document is passed to and processed by a application-for example, an ASP page-that cannot properly Decode rare or new characters. When this happens is might, you are able to work around the problem by relying on DOM to handle the character encoding. This bypasses the incapable application.

For example, the following XML document contains the character entity ("& #8364;") that corresponds to the Euro currenc Y symbol (€). The ASP page, incapable.asp, cannot process currency.xml.

XML Data (currency.xml)

<?xml version= "1.0" encoding= "Utf-8"?>
<currency>
   <name>Euro</name>
   < symbol>& #8364;</symbol>
   <exchange>
      <base>US___FCKpd___0lt;/base>
      < rate>1.106</rate>
   </exchange>
</currency>

ASP Page (incapable.asp)

<% @language = "javascript"%>
<%
   var doc = new ActiveXObject ("msxml2.domdocument.4.0");
   Doc.async = false;
   if (Doc.load (Server.MapPath ("Currency.xml")) ==true) {
      Response.ContentType = "Text/xml";
      Response.Write (Doc.xml);
   }
%>

When incapable.asp are opened from a Web browser, an error such as the following results:

An invalid character is found in text content. Error processing resource ' http://MyWebServer/MyVirtualDirectory/incapable.asp '. Line 4, Position 10

This error was caused by the use of the Response.Write (doc.xml) instruction in the incapable.asp code. Because it calls upon ASP to encode/decode the Euro currency symbol character found in Currency.xml, it fails.

However, can fix this error. To doing so, replace this Response.Write (doc.xml) instruction in incapable.asp with the following line:

Doc.save (Response);

The error does not occur. The ASP code does produce the correct output in a Web browser, as follows:

  <?xml version= "1.0" encoding= "Utf-8"?> 
  <currency>
    <name>Euro</name> 
    <symbol>€</symbol> 
    <exchange>
      <base>US $</base> 
      <rate>1.106</rate> 
    </exchange>
  </currency>

The effect of the change in the ASP page was to let the DOM object (DOC)-instead of the Response object on the ASP Page-han Dle the character encoding.

Take a look at the last sentence: The ASP change in the example above is to have the DOM object (DOC)--not the Response object in ASP--handle character encoding.

So the result is:

Guess two: You can view the request or Response object as a file handle, if you are using the load and save methods of the DOM object.

From conjecture one, conjecture two draws

Conjecture three: The client-compiled system uses the string itself is GB2312 encoded, and the use of XMLHTTP to transfer data automatically converted to GB2312, server-side with DOM object load due to the equivalent of loading a byte stream, Then a look at the XML header encoding is GB2312, so there is no conversion, directly to the byte stream as a string ... Sorry is that it did forget one thing is that the string in my system is displayed when it is UTF-8 encoded, so only forcing the XML conversion below the line, as if to see other people's solution also has written gb2312 to utf-8 conversion function ...

The last practice proves to be feasible ...

In a nutshell, the client sends to the server xml,encoding all utf-8 encoded; The server is sent to the client, all the specified encoding is: gb2312, everything OK.