纠结于ajax开发中 response的contentType 问题
纠结于ajax开发中 response的contentType 问题
- 博客分类：
- web前端
AjaxjsonJavaScriptjQuery应用服务器
ajax开发中, 常遇到下面的几种情况:
1 服务端需要返回一段普通文本给客户端
2 服务端需要返回一段HTML代码给客户端
3 服务端需要返回一段XML代码给客户端
4 服务端需要返回一段javascript代码给客户端
5 服务端需要返回一段json串给客户端
================================
对于每一种返回类型 规范的做法是要在服务端指定 response的contentType 的.
(当然 不指定绝大多数情况下也没什么问题 尤其是返回"非xml"的时候)
1 服务端需要返回一段普通文本给客户端
2 服务端需要返回一段HTML代码给客户端
3 服务端需要返回一段XML代码给客户端
4 服务端需要返回一段javascript代码给客户端
5 服务端需要返回一段json串给客户端
================================
对于每一种返回类型 规范的做法是要在服务端指定 response的contentType 的.
(当然 不指定绝大多数情况下也没什么问题 尤其是返回"非xml"的时候)
Java代码
以上三个可以说是毫无争议的, 也没什么值得讨论的,
但是另外两种情况 就要注意一下了.
javascript 的 contentType 按最标准的写法 应该是 application/javascript.
而常用的 text/javascript 已经被 rfc定义为废弃的.
(参见rfc4329)
但是 在这里暂时不建议使用 application/javascript .
大家还是继续使用text/javascript为好.
因为很多老旧浏览器并不支持 application/javascript .
而所有浏览器都支持 text/javascript.
在标准和广泛的兼容性之间 还是暂且选择后者吧.
json 的 contentType 常见写法有 : text/json & text/javascript .
但是 这个 text/json 其实是根本不存在的,
而 text/javascript 在有些时候客户端处理起来会有歧义.
对于json的contentType , rfc里定义的标准写法是 :application/json.
(参见rfc4627)
在这里毫无疑问 我们应该选择标准写法的application/json.
======================
也许有人会问, 设置这些有什么用呢?
以前一些程序没有设置这些东西 运行的也很好啊.
首先必须承认的一点是, 这些信息 在目前绝大多数情况下 确实不设置也可以.
但是这种做法是不规范不标准的.
未来对于复杂的ajax应用 ,不规范的行为是会带来很大的隐患.
举个例子.
对于同样的内容 可以有下面的3种形式
html形式
- 普通文本:text/plain
- HTML代码:text/html
- XML代码:text/xml
以上三个可以说是毫无争议的, 也没什么值得讨论的,
但是另外两种情况 就要注意一下了.
javascript 的 contentType 按最标准的写法 应该是 application/javascript.
而常用的 text/javascript 已经被 rfc定义为废弃的.
(参见rfc4329)
但是 在这里暂时不建议使用 application/javascript .
大家还是继续使用text/javascript为好.
因为很多老旧浏览器并不支持 application/javascript .
而所有浏览器都支持 text/javascript.
在标准和广泛的兼容性之间 还是暂且选择后者吧.
json 的 contentType 常见写法有 : text/json & text/javascript .
但是 这个 text/json 其实是根本不存在的,
而 text/javascript 在有些时候客户端处理起来会有歧义.
对于json的contentType , rfc里定义的标准写法是 :application/json.
(参见rfc4627)
在这里毫无疑问 我们应该选择标准写法的application/json.
======================
也许有人会问, 设置这些有什么用呢?
以前一些程序没有设置这些东西 运行的也很好啊.
首先必须承认的一点是, 这些信息 在目前绝大多数情况下 确实不设置也可以.
但是这种做法是不规范不标准的.
未来对于复杂的ajax应用 ,不规范的行为是会带来很大的隐患.
举个例子.
对于同样的内容 可以有下面的3种形式
html形式
Html代码
对于 html 形式,客户端得到数据后,往往是对其做dom操作.
javascript形式
- <scripttype="text/javascript">
- varuser={
- name:"Tom",
- age:12
- };
- </script>
对于 html 形式,客户端得到数据后,往往是对其做dom操作.
javascript形式
Javascript代码
对于 javascript形式,往往是对其做eval操作:
eval(responseText);
json形式
- varuser={
- name:"Tom",
- age:12
- ;
对于 javascript形式,往往是对其做eval操作:
eval(responseText);
json形式
Javascript代码
对于 json形式,往往是对其做 eval操作之后 赋值给某变量:
var clientVar= eval(responseText);
客户端拿到不同形式的代码 所要做的工作是不一样的.
如果没有设置 contentType 客户端很难判断 返回的数据是什么, 该怎么处理.
==========================
另外,对于返回信息,如果不设置contentType,web服务器往往会给返回的内容添加一个"默认的contentType",
但是这个"默认"会根据服务器的不同 以及web应用配置的不同而不同.
而浏览器对于没有足够头信息的返回值 也会做出"某些默认行为(打开 或下载 或报错".
总之 不同浏览器 不同的浏览器设置 结果可能是不一样的 无法把控.
也就是说 当我们不指定正确的contentType时, 我们所能做的只能是祈祷 在所有环境中, 程序的表现是一致的,
但是与其"祈祷"不如我们亲自把这些信息加上来得可靠.
所以 正确设置返回信息的 contentType 还是很有必要的.
======================
总结 & 建议 :
1.
服务端 向 客户端 发送 JSON数据 时:
Content-Type = 'application/json;charset=UTF-8'
2.
服务端 向 客户端 发送 JS 代码 时:
Content-Type = 'text/javascript;charset=UTF-8'
3
服务端 判断 客户端 提交的是否是 JSON数据 时 :
Content-Type = 'application/json;charset=UTF-8'
Content-Type = 'text/json;charset=UTF-8'
Content-Type = 'text/javascript;charset=UTF-8'
Content-Type = 'application/javascript;charset=UTF-8'
只要 Content-Type 满足上面4个条件中的 任意一个时,就可以认为提交的数据是 JSON数据.
之所以要提供4种选择 是因为 为了提供更好的兼容性.
(我想没有人会提交真正的js代码到服务端 然后用服务端js引擎去解析执行吧?
即使真有这种需求 也可以在js代码外包一层 json格式的 wrapper ,
所以姑且都当作json处理应该没什么问题)
======================
唉 又一篇蛮纠结于无聊细节的短文 就这样结束了
如有不对 还请斧正 谢谢了. 优质内容筛选与推荐>>
1、IsPostBack
2、创建featureclass，为它赋别名，并移动到数据集下
3、Powershell About LocalGroupMembership
4、SQL Server 2008 将数据导出到SQL脚本文件
5、第一次作业 汇编语言基础知识
- {
- name:"Tom",
- age:12
对于 json形式,往往是对其做 eval操作之后 赋值给某变量:
var clientVar= eval(responseText);
客户端拿到不同形式的代码 所要做的工作是不一样的.
如果没有设置 contentType 客户端很难判断 返回的数据是什么, 该怎么处理.
==========================
另外,对于返回信息,如果不设置contentType,web服务器往往会给返回的内容添加一个"默认的contentType",
但是这个"默认"会根据服务器的不同 以及web应用配置的不同而不同.
而浏览器对于没有足够头信息的返回值 也会做出"某些默认行为(打开 或下载 或报错".
总之 不同浏览器 不同的浏览器设置 结果可能是不一样的 无法把控.
也就是说 当我们不指定正确的contentType时, 我们所能做的只能是祈祷 在所有环境中, 程序的表现是一致的,
但是与其"祈祷"不如我们亲自把这些信息加上来得可靠.
所以 正确设置返回信息的 contentType 还是很有必要的.
======================
总结 & 建议 :
1.
服务端 向 客户端 发送 JSON数据 时:
Content-Type = 'application/json;charset=UTF-8'
2.
服务端 向 客户端 发送 JS 代码 时:
Content-Type = 'text/javascript;charset=UTF-8'
3
服务端 判断 客户端 提交的是否是 JSON数据 时 :
Content-Type = 'application/json;charset=UTF-8'
Content-Type = 'text/json;charset=UTF-8'
Content-Type = 'text/javascript;charset=UTF-8'
Content-Type = 'application/javascript;charset=UTF-8'
只要 Content-Type 满足上面4个条件中的 任意一个时,就可以认为提交的数据是 JSON数据.
之所以要提供4种选择 是因为 为了提供更好的兼容性.
(我想没有人会提交真正的js代码到服务端 然后用服务端js引擎去解析执行吧?
即使真有这种需求 也可以在js代码外包一层 json格式的 wrapper ,
所以姑且都当作json处理应该没什么问题)
======================
唉 又一篇蛮纠结于无聊细节的短文 就这样结束了
如有不对 还请斧正 谢谢了. 优质内容筛选与推荐>>
1、IsPostBack
2、创建featureclass，为它赋别名，并移动到数据集下
3、Powershell About LocalGroupMembership
4、SQL Server 2008 将数据导出到SQL脚本文件
5、第一次作业 汇编语言基础知识