Wandai Blog 共被围观 1,584,838 次

今天呐, 一直有一个空异常的Error Report邮件在骚扰我,  我并没有理会这些邮件, 直到swx叫我处理这个空异常。

我根据他的说明, 看了一部分代码, 并没有发现哪里有问题, 后来他叫我转储这个异常的getTraceAsString, 然后发现这个异常实际上不是空的, 是有一定内容的。

但是这并不能解决问题, 于是我又加入了出错页面的uri的转储, 后来发现是一个看似正常的uri, 它总是以一个特定的字符串为结尾, 但是我并没有注意这个特定的字符串, 并暂时忘记了它。

这个uri形如

.../%CB%D1%CB%F7?一个特定的字符串

后来, 我在本地修改为直接输出错误并访问这个uri, 我成功得到了异常的输出!

是编码问题, 异常消息形如”non-utf8 string □□”。显然, “%CB%D1%CB%F7″用utf8来解码会发生问题。

于是我们就得到了一个结论, 并且它看起来是合理的。

对 {[含有(含有不正确的utf8字符)的字符串成员]的类或者数组} 使用json_encode, 相应的内容将会得到”null”

于是我们就研究为什么会出现这个非utf8 urlencoded的东西。

一开始, 我居然说是用户手动输入, 显然我这个时候忘记了那个特定的字符串的存在, 然后swx说把它强制转换为utf8, 并且网页输出的时候使用ansi urlencode, 然后再处理。

我认为这样不行, 因为我记得, 不同的浏览器对于用户直接输入在地址栏的中文字符会有不同的处理方式, 比如我用的chrome是显示为中文, 但是http中使用utf8 urlencode的字符串。经过测试, ie6、ie9也是这样处理的。

于是我们就又得到了一个结论, 并且它看起来是合理的。

看来……小学时候老师说的不要用中文url有很大道理呢orz

于是swx同意了我的观点: 检测编码之后再转换。

(期间讨论了一下Windows内核是Unicode的还是ANSI的, 还有Win32 API的 xxxA/xxxW, 然后称赞了Linux一直使用Unicode, 并且ib说UTF-8的长度不好获取, UTF-16更好)

但是swx忽然发现, 因为那个特定的字符串的存在, 这串uri不怎么可能是用户手动输入的, 于是便猜测可能是js的问题, 因为那个特定的字符串是ajax里面的参数。

他还指出, 可能是js使用了ansi urlencode, 并称这也是浏览器问题。

于是他勒令给js加入escapeURIComponent, 问题应该能够得到解决。