Ajax在firefox中的中文乱码

[xxgu]

前台页面和后台页面都使用的是utf-8编码，显示结果的页面也用的utf-8编码，ajax用post方法提交数据，setRequestHeader("Content-Type","application/x-www-form-urlencoded;charset=utf-8")，提交前用encodeURIComponent处理过中文，在ie下面是肯定没问题的了，但是firefox提交的中文是gb2312编码的，存到数据库以后再读到页面就是乱码了，（分两种情况，一种是直接在utf-8页面复制的中文提交不会乱码，自己手打得中文提交就乱码了），请各位老大给个解决的办法，谢谢！


PS：能提供出解决问题思路的100分，剩下的平分，谢谢大家!分不够可以再加

[xxgu]

先把沙发坐上...

[Love_birds]

出现乱码的记录是DB中是不是乱码？

如果在DB中是正常的，但是你用AJAX读出来后显示乱码的话，可以这样解决：

在AJAX读取DB记录的那个程序文件中最前面加入字符集指定：

header('Content-type: text/html;charset=GB2312');

如果是DB中就是乱码，那你得查一下POST到DB的那个程序文件了。

[Love_birds]

追加一下，以上只是想法，我以为你是PHP的程序，没想到是ASP的。呵呵。但理论是一样的。

[xxgu]

记录存进数据库以后就是直接读到一个utf-8的页面显示，没有用ajax去从数据库读，读出来的数据从ie提交的都正常，但是firefox的会乱码，把页面编码改成gb2312的话，firefox提交的就正常了，ie的乱码，还有就是对于多个中文参数的提交,firefox接受参数的时候可能出错

[myvicy]

<%
response.charset="utf-8" '先设置一下编码再输出显示看看
response.write rs("field")
%>

[wlkjhxd]

在页面的头部写上
utf-8:
<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>
<%Session.CodePage=65001%>
或gb2312:
<%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%>
<%Session.CodePage=936%>

[xxgu]

显示的页面是utf-8的，但是只有ie提交的中文是正常的firefox得乱码，改成gb2312的话，firefox提交的正常，ie乱码

[Love_birds]

五，六楼的建议可以试试，测试方法就是哪个浏览器出乱码，你查哪个浏览器的显示编码看是什么。

如果不是你想要的。你就在输出页头强制指定显示的字符编码。

[smartcatiboy]

我推测
可能是FF不自动判断，而根据HTTP页面的meta读取，没有就以客户端系统默认
在asp加上下面这个行不

<meta http-equiv="Content-Language" content="utf-8">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

[银狐被占用]

1。用DM或editplus等工具新建网页时选UTF-8编码。
2。在页面最上面放上<%@ CODEPAGE="65001"%>
3。如果用SQL数据库，那么把字符型的字段都改为nvarchar，存数据时这样写：
insert into tb(field) values(N'fdskfldsalfds')

暂时有这几种方法。。

[银狐被占用]

还有一点，XML请求时，取返回值用var result = xmlhttp_request.responsetext;
这样回来的值就是UTF-8的了。

[一把编程的菜刀]

你存进数据库的时候是乱码吗？
如果不是，只是读取时变乱码
那转换下
response.Write(escape(rs("laiyuan")))



function getName()
{
var id;
id = document.getElementById("myid").value;
xmlhttp.open("get","xmlhttp.asp?id="+id);
xmlhttp.onreadystatechange = function(){
if(xmlhttp.readyState==4){
document.getElementById("myname").value =unescape(xmlhttp.responseText);
}
}
xmlhttp.setRequestHeader("If-Modified-Since","0");
xmlhttp.send(null);
}

红色部分

[xxgu]

我原来用的<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>
现在加上了
<%Session.CodePage=65001%>
好像问题解决了...
正在找人测试
谁告诉我一下Session.CodePage=65001这个的作用是什么

[myvicy]

<%response.charset="utf-8"%>
这个应该也可以的。

[myvicy]

<%Session.CodePage=936%>
指定输出的内容是GB2312编码的。
936是GB2312编码，UTF-8则是65001。
你再测试<%response.charset="utf-8"%>
效果应该相同的.

[xxgu]

<%response.charset="utf-8"%>
不行，我只前用的就是<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%><%response.charset="utf-8"%>

加上<%Session.CodePage=65001%>才行
不知道这个的作用到底是什么，不过我那个是限制ip的，要找个没用过的ip才能测
目前在上海，可以用了的话下周回北京结帖

[若白师妹]

我google來的，顺便学习

下面是msdn中的一段话。

setting @codepage explicitly affects literal strings in a single response. response.codepage affects dynamic strings in a single response, and session.codepage affects dynamic strings in all responses in a session.


这句话解释清楚了@codepage，response.codepage，session.codepage 分别的作用是什么。

@codepage作用于所有静态的字符串，比如某文件中的 const blogname="我的家"

response.codepage,session.codepage作用于所有动态输出的字符串，比如<%=blogname%>

这句话很关键的是说明了response.codepage的作用范围是a single response，而sxna中声明的session.codepage的作用范围是all responses in a session。

再看另外一句话。

if response.codepage is not explicitly set in a page, it is implicitly set by session.codepage, if sessions are enabled. if sessions are not enabled, response.codepage is set by @codepage, if @codepage is present in the page. if there is no @codepage in the page, response.codepage is set by the aspcodepage metabase property. if the aspcodepage metabase property is not set, or set to 0, response.codepage is set by the system ansi code page.


这句话我乍一看，把意思理解成了这样：在sessions are enabled的时候，如果response.codepage没有声明，则response.codepage会被session.codepage赋值。如果sessions are not enabled的时候, 如果@codepage已声明，则response.codepage会被@codepage赋值，等等.............

这句话解释了为什么从sxna中出来以后进入一些别的页面比如oblog,z-blog等等容易出现乱码，因为其他程序没有声明response.codepage而恰巧sxna声明了session.codepage，因此一进入sxna，session.codepage立即被赋值（版本不同，有的版本赋了936有的版本赋了65001），而后进入其他程序的时候response.codepage马上被session.codepage赋值，如果这时response.codepage与页面本身编码不一样的话，页面就会出现乱码。所以进入z-blog出现乱码的时候我查了当时的session.codepage和response.codepage都是936，而进入oblog出现乱码的时候session.codepage和response.codepage都是65001.就是说要想保证叶面不出现乱码，应该声明response.codepage，否则他就会按照session.codepage来解释网页（而不是按照@codepage解释网页）.

如果仅仅按照上面的解释的话，我实际上是很糊涂的，因为我们都是用的中文操系统，当每一次进入浏览器的时候你可以尝试输出session.codepage，能看到他都是936！为什么进入z-blog的时候他不把默认的session.codepage的936赋给response.codepage呢？反而把@codepage给了response.codepage？什么情况下session.codepage才赋值给response.codepage呢？原文的sessions are enabled应该如何理解呢？

也许上面的话应该这样理解：

在session.codepage被任何程序声明的时候，如果response.codepage没有声明，则response.codepage会被session.codepage赋值。如果session.codepage没有被任何程序声明的时候, 如果@codepage已声明，则response.codepage会被@codepage赋值，....，最后的页面动态内容部分按照response.codepage的值解释。


因为zblog和oblog都声明了@codepage，所以，用户刚刚启动完机器然后进入浏览器浏览zblog和oblog的时候response.codepage会被@codepage赋值，于是叶面显示正常。

这句话进一步解释了产生乱码的原因

if you set response.codepage or session.codepage explicitly, do so before sending non-literal strings to the client. if you use literal and non-literal strings in the same page, make sure the code page of @codepage matches the code page of response.codepage, or the literal strings are encoded differently from the non-literal strings and display incorrectly.


其中比较有用的一句话是说如果response.codepage和@codepage不一样的话会产生乱码。也就是说当z-blog的@codepage=65001而z-blog的response.codepage被session.codepage赋为936的时候就会出现乱码，oblog反之亦然。

不知道上面说了这么多解释清楚没有-_-||

下面解释一下为什么sxna有时会把session.codepage赋为936，我有一个版本是这样写的：

<% originalcodepage=session.codepage %>

.......

<% session.codepage=originalcodepage %>


当用户进入浏览器的时候session.codepage默认为936，这个时候的默认936不是程序声明的，因此不会赋给response.codepage，当进入sxna的时候，session.codepage被上面那段代码一折腾就变成了程序声明的session.codepage=936,因此再进入zblog的时候就把936给了response.codepage。

至此，全部原因已经分析清楚了。

因此说，保证asp叶面一定不会出现乱码的代码应该是这样的：（假定是utf-8的叶子）

<%@ codepage=65001 %>

<% response.codepage=65001%>

<% response.charset="utf-8" %>


进一步说明为什么要加response.charset，因为msdn说应该加...呵呵

if the code page is set in a page, then response.charset should also be set.


另外，文件的编码格式应该与@codepage一样:

the file format of a web page must be the same as the @codepage used in the page.


这就是为什么zblog,pjblog等一些程序要吧文件存成utf8编码格式的原因.

综上，如果所有的程序都声明了response.codepage就不会被session.codepage干扰而出现乱码了。所以session.codepage还是不能轻易用的！

[xxgu]

谢谢楼上的，刚找人用firefox测过可以用了，又长见识了...

[一把编程的菜刀]

..