via:http://chinaonrails.com/topic/view/1771.html
URL 编码
URL 编码是一种浏览器用来打包表单输入的格式. 浏览器从表单中获取所有的name和其中的值 ,将他们作为name/value参数编码, 移去那些不能传送的字符, 将数据排行等等,这些还取决于你用GET还是POST?作为URL的一部分或者分离地发给服务器. 不管哪种情况, 在服务器端的表单输入格式样子象这样:
theName=Ichabod+Crane&gender=male&status=missing&headless=yes
URL编码遵循下列规则:
每对name/value由&符分开.
每对来自表单的name/value由=符分开. 如果用户没有输入值给这个name,那么这个name还是出现,只是无值(象这样 "name=").
任何特殊的字符(就是那些不是简单的七位ASCII,如汉字) 将以百分符%用十六进制编码. 当然也包括象 =, &, 和 % 这些特殊的字符.
在输入区中的空格将以加号+显示.
因为表单输入是用这个URL编码传递给你的脚本的,在你用这些参数之前必须解码,因为解码是个很普遍的工作,可以有很多工具做这个工作 . 你没有必要自己写这个解码程序.
URL是用于表示信息位置的标识符号,称为“统一资源定位符”,字串由四部分组成:
协议:计算机之间进行通信所使用的规则;
域名:被访问网站服务器的专用名称;
目录:网页在网站服务器中的位置;
文件名:网页在服务器中的名字。
四部分连接起来就是:
协议://域名/服务器子目录/文件名
URL 编码是一种浏览器用来打包表单输入的格式. 浏览器从表单中获取所有的name和其中的值 ,将他们作为name/value参数编码, 移去那些不能传送的字符, 将数据排行等等,这些还取决于你用GET还是POST?作为URL的一部分或者分离地发给服务器. 不管哪种情况, 在服务器端的表单输入格式样子象这样:
theName=Ichabod+Crane&gender=male&status=missing&headless=yes
URL编码遵循下列规则:
每对name/value由&符分开.
每对来自表单的name/value由=符分开. 如果用户没有输入值给这个name,那么这个name还是出现,只是无值(象这样 "name=").
任何特殊的字符(就是那些不是简单的七位ASCII,如汉字) 将以百分符%用十六进制编码. 当然也包括象 =, &, 和 % 这些特殊的字符.
在输入区中的空格将以加号+显示.
因为表单输入是用这个URL编码传递给你的脚本的,在你用这些参数之前必须解码,因为解码是个很普遍的工作,可以有很多工具做这个工作 . 你没有必要自己写这个解码程序.
URL是用于表示信息位置的标识符号,称为“统一资源定位符”,字串由四部分组成:
协议:计算机之间进行通信所使用的规则;
域名:被访问网站服务器的专用名称;
目录:网页在网站服务器中的位置;
文件名:网页在服务器中的名字。
四部分连接起来就是:
协议://域名/服务器子目录/文件名
3 - 6-23 16:26
龙生第九子
北京市朝阳区
1.在没有中文字符的机器可能,无法访问到这一连接。
2.搜索引擎,不会收录url上有中文的地址。
3.中文网址非常不利国际化,很多人期望的是更友好的。
每个人都喜欢有意义的URL,所以使用'/users/jim-neath'比使用'/users/231'或 /users/吉姆 更nice
2.搜索引擎,不会收录url上有中文的地址。
3.中文网址非常不利国际化,很多人期望的是更友好的。
每个人都喜欢有意义的URL,所以使用'/users/jim-neath'比使用'/users/231'或 /users/吉姆 更nice
4 - 6-23 16:27
Caiwangqin
楼主
中国
以下是和刘松的交流记录:
URL的参数编码规范似乎是base64 url safe.
在ruby端,可以
require 'cgi'
CGI.escape(...) 还是encode/decode来着,我忘了.
在javascript端,是encodeURIComponenent
它们接收的,都是key=value&key=value里,编码之前的value
Sent at 4:17 PM on Monday
刘松: http://www.faqs.org/rfcs/rfc3548.html
看Base 64 Encoding with URL and Filename Safe Alphabet那一段.
Sent at 4:20 PM on Monday
刘松: 至少value里不能包含 &和=字符,不然就破坏key=value&key=value这种格式了.
至于中文,我不清楚,可能涉及unicode编码问题,所以还是encode一下再传输更靠谱
rails的xx_path及ajax库的类似Ajax.Request,在内部都对key,value进行encode,所以,在编码上感觉不到.
decode的过程,server side自动做了,所以一般不用我们去显式调用,params[:key]取到的就是已经decode后的值
URL的参数编码规范似乎是base64 url safe.
在ruby端,可以
require 'cgi'
CGI.escape(...) 还是encode/decode来着,我忘了.
在javascript端,是encodeURIComponenent
它们接收的,都是key=value&key=value里,编码之前的value
Sent at 4:17 PM on Monday
刘松: http://www.faqs.org/rfcs/rfc3548.html
看Base 64 Encoding with URL and Filename Safe Alphabet那一段.
Sent at 4:20 PM on Monday
刘松: 至少value里不能包含 &和=字符,不然就破坏key=value&key=value这种格式了.
至于中文,我不清楚,可能涉及unicode编码问题,所以还是encode一下再传输更靠谱
rails的xx_path及ajax库的类似Ajax.Request,在内部都对key,value进行encode,所以,在编码上感觉不到.
decode的过程,server side自动做了,所以一般不用我们去显式调用,params[:key]取到的就是已经decode后的值
5 - 6-23 16:33
Caiwangqin
楼主
中国
从理论上讲,经过encoding后,URL中可以包含所有字符。以下是和Robin Lu的交流记录:
Caiwangqin: 没有中文系统支持的系统呢?不encoding呢?如 P1.cn/中国
中国.p1.cn
Robin: 浏览器会自己encoding,你不用管
http://www.caibangzi.com/document/show/什么是基金
Caiwangqin: 这个是可以,为什么自定义用户URL时,过去一般没有人支持中文呢?
Robin: 那是因为一般很少有系统愿意支持中文用户名吧
还有一个原因是安全问题
Caiwangqin: 中文在URL中不安全?
Robin: 因为unicode会造成很多 glyph相同但编码不同的字符
会出现冒充用户的
Caiwangqin: 没有中文系统支持的系统呢?不encoding呢?如 P1.cn/中国
中国.p1.cn
Robin: 浏览器会自己encoding,你不用管
http://www.caibangzi.com/document/show/什么是基金
Caiwangqin: 这个是可以,为什么自定义用户URL时,过去一般没有人支持中文呢?
Robin: 那是因为一般很少有系统愿意支持中文用户名吧
还有一个原因是安全问题
Caiwangqin: 中文在URL中不安全?
Robin: 因为unicode会造成很多 glyph相同但编码不同的字符
会出现冒充用户的
7 - 6-23 16:48
Caiwangqin
楼主
中国
以下是和 94smart 的交流记录:
94smart: 这个问题太高深了
一般我碰到中文URL的问题都会跳过
Caiwangqin: 跳过?
94smart: 就是能不用就不用
Caiwangqin: 现在我们在决定是否在用户挑选自己的URL时是否支持中文,如 蔡望勤.p1.cn
94smart: 最后会转换为英文URL
这样有什么直接的好处吗?或者说这是用户的直接需求吗?
Caiwangqin: 没有好处,也不是直接需求。我们的产品经理说可以支持
94smart: 。。。
这个是劳民伤财呀
Caiwangqin: 到技术这里,我就要验证是否可行了。
Sent at 4:43 PM on Monday
94smart: 处理逻辑可不可以这样:不管哪种编码,统一转成参数是userid的链接。
Caiwangqin: 不行,要在显示URL的时候象这样:P1.cn/蔡望勤,而不能是 P1.cn/323232
94smart: 那就只能每页都作UTF8转码这个动作了
而且好像不是每个浏览器都支持中文URL
94smart: 保险的做法是让用户自己改IE的Internet选项
关掉“是以 UTF-8 发送URL”这个选项
Caiwangqin: 我们不可能要求用户修改浏览器选项后来使用我们的网站的。
94smart: 所以问题比较大呀
94smart: 这个问题太高深了
一般我碰到中文URL的问题都会跳过
Caiwangqin: 跳过?
94smart: 就是能不用就不用
Caiwangqin: 现在我们在决定是否在用户挑选自己的URL时是否支持中文,如 蔡望勤.p1.cn
94smart: 最后会转换为英文URL
这样有什么直接的好处吗?或者说这是用户的直接需求吗?
Caiwangqin: 没有好处,也不是直接需求。我们的产品经理说可以支持
94smart: 。。。
这个是劳民伤财呀
Caiwangqin: 到技术这里,我就要验证是否可行了。
Sent at 4:43 PM on Monday
94smart: 处理逻辑可不可以这样:不管哪种编码,统一转成参数是userid的链接。
Caiwangqin: 不行,要在显示URL的时候象这样:P1.cn/蔡望勤,而不能是 P1.cn/323232
94smart: 那就只能每页都作UTF8转码这个动作了
而且好像不是每个浏览器都支持中文URL
94smart: 保险的做法是让用户自己改IE的Internet选项
关掉“是以 UTF-8 发送URL”这个选项
Caiwangqin: 我们不可能要求用户修改浏览器选项后来使用我们的网站的。
94smart: 所以问题比较大呀
9 - 6-23 17:08
Caiwangqin
楼主
中国
Iceskysl: 这个玩意一般用encoding后都可以
另外和机器浏览器发起请求的编码有关
在IE的高级设置里面
可以设置发起请求的编码格式
10 - 6-23 17:11
robin
北京市海淀区
url显示和发送是两回事.
ie我懒得试了,safari是会按照"P1.cn/蔡望勤"来显示的,firefox在2.0以前是按照十六进制码显示,3.0已经fix了这个问题,同样是"P1.cn/蔡望勤".
但是发送的时候,都是encoding后发送的.
url的decoding/encoding是浏览器和cgi的事情,和用户没有关系.
"以 UTF-8 发送URL"是为那些老旧的不能识别utf-8的cgi设置的,和你要解决的不是一个问题.
ie我懒得试了,safari是会按照"P1.cn/蔡望勤"来显示的,firefox在2.0以前是按照十六进制码显示,3.0已经fix了这个问题,同样是"P1.cn/蔡望勤".
但是发送的时候,都是encoding后发送的.
url的decoding/encoding是浏览器和cgi的事情,和用户没有关系.
"以 UTF-8 发送URL"是为那些老旧的不能识别utf-8的cgi设置的,和你要解决的不是一个问题.