ios safari的奇怪pond

 

在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？