【发布时间】：2013-10-03 02:48:04
【问题描述】：
一直在重新审视为什么某些类型的字符数据在通过 ajax 调用发送到网络服务器时会损坏的问题，无论使用什么编码。即使数据被预编码为 7 位格式，输出的数据仍然不总是等于输入的数据。
我使用第三方 javascript base64 编码器来准备 ajax 数据，并最初认为这有一个错误。但是，其他 base64 编码器显示完全相同的问题——包括一个声称完全兼容 unicode 的问题——并且有几个类似问题的论坛报告，似乎都没有完全解决。所以，我不认为编码器本身有问题。
我注意到，如果数据包含某些特定的高阶 ASCII/ANSI 代码，则通常会在从其他程序剪切并粘贴到 CKEditor 中的数据时出现损坏。
更多测试似乎表明问题与 javascript 从网页读取字符数据的方式与它从内部编程方法形成字符串数据的方式（例如 String.fromCharCode( )。
在下面的 sn-p 中，将通过文本编辑器剪切和粘贴插入 HTML 文档的字符 0x9E 的处理与从十六进制代码 0x9E 以编程方式生成的相同字符（U+017E - Arial Latin small z with caron, Windows Western charset)。这是导致这种异常行为的几个字符代码之一。奇怪的是，大多数其他大于 127 个字符的代码都没有出现这样的问题，而是按照它们应该的方式呈现为两字节 unicode。
<script>
var pasted_char = 'ž';
alert("Pasted Character: " + pasted_char + " Resultant Code(s): " + charcodes(pasted_char));
var charcode = 0x9E;
var generated_char = String.fromCharCode(charcode);
alert("Generated Character: " + generated_char + " Resultant Code(s): " + charcodes(generated_char));
function charcodes(invar) {
// lists char codes for each byte in a character.
var ccodes = "~";
for (ct=0; ct<invar.length; ct++){
var invarc = invar.charCodeAt(ct);
ccodes += invarc + "~";
}
return ccodes;
}
</script>
使用 UTF-8 页面字符集，给出：
粘贴字符：[0xFFFD] 结果代码：~65533~
生成的字符：[空白] 结果代码：~158~
使用默认页面字符集，给出：
粘贴字符：ž 结果代码：~382~
生成的字符：[空白] 结果代码：~158~
值得注意的是，对粘贴字符的处理都不是正确的，并且没有像 382 这样的 ANSI 代码！
两个输出都是单字节。
严格来说，这个字符是 8 位 ASCII/ANSI，js 并没有声称可以处理它，但是将它粘贴到 HTML 编辑器中是完全合法的，例如从文本文档中。因此，javascript 子系统应该能够处理此类输入而不会出现错误。无论如何，在我看来，以两种不同的方式生成相同的字符串不应该返回两个不同的结果。
欢迎对此提出任何想法。我不确定这个异常在破坏 ajax 发送方面究竟扮演了什么角色，但它似乎很可能是罪魁祸首。
【问题讨论】：
标签： javascript ajax utf-8 base64