在ios的键盘上有这样一个键
£
当你在一个euc-jp编码的网页上输入这个pond并提交,服务器端代码接受这个参数并存储到MySQL中,以后再次从MySQL中读取并展示在页面上时,这个pond就不见了!
euc-jp编码是支持pond的,编码是A1F2
参见http://www.fileformat.info/info/charset/EUC-JP/list.htm
然后ios的键盘上提交的编码是8EE1,这不是一个合法的EUC-jp的编码,wiki上是这样定义EUC-jp的。http://en.wikipedia.org/wiki/Extended_Unix_Code
- A character from the lower half of JIS-X-0201 (ASCII , code set 0) is represented by one byte, in the range 0x21 – 0x7E.
- A character from the upper half of JIS-X-0201 (half-width kana , code set 2) is represented by two bytes, the first being 0x8E, the second in the range 0xA1 – 0xDF.
- A character from JIS-X-0208 (code set 1) is represented by two bytes, both in the range 0xA1 – 0xFE.
- A character from JIS-X-0212 (code set 3) is represented by three bytes, the first being 0x8F, the following two in the range 0xA1 – 0xFE.
A1F2和8EE1这两个pond在不同的浏览器上显示效果也不同
Firefox, IE, Opera | 只支持A1F2,8EE1显示出来是一个乱码 |
Chrome | 两个都可以显示,但是显示效果有细小的区别,而且如果将显示在页面上的8EE1复制粘帖后提交,提交的却是A1F2 |
Safari | 两个都支持,显示效果有比较大的不同,各自复制粘帖后提交还都是各自的编码 |
google了很多,都没有关于8EE1这个编码的来源,试验了一下从8EE0开始的编码,分别是
8EE0 | ¢ |
8EE1 | £ |
8EE2 | ¬ |
8EE3(这个显示的不对,其实在euc-jp下是个¥类似这样的符号) | \ |
8EE4 | ~ |
解决办法:
1. 因为只有pond能够“正常”被提交,所以只要处理这个就可以了。方法是在服务器端使用正则替换。以perl为例
$param =~ s/\x8E\xE1/\xA1\xF2/g;
不过所有能够输入的文本框都有这样的问题,这样做是不是太烦锁了...
2. 也可以在客户端用js的encodeURICompent处理一下,js出来的结果是UTF-8编码的,即C2A3,然后在服务器端再做一个编码转换成EUC-jp。不过要注意不要出现两次uri encode :)
这也许是个BUG?