一直在重新审视为什么某些类型的字符数据在通过 ajax 调用发送到网络服务器时会损坏的问题，无论使用什么编码。即使数据被预编码为 7 位格式，输出的数据仍然不总是等于输入的数据。
我正在使用第三方 javascript base64 编码器来准备 ajax 数据，并最初认为这有一个错误。但是，其他 base64 编码器显示完全相同的问题——包括一个声称完全兼容 unicode 的问题——并且有几个类似问题的论坛报告，似乎都没有完全解决。所以，我不认为编码器本身有问题。
我注意到，如果该数据包含某些特定的高阶 ASCII/ANSI 代码，则通常会在从其他程序剪切并粘贴到 CKEditor 中的数据时出现损坏。
更多测试似乎表明问题与 javascript 从网页读取字符数据的方式与它从内部编程方法（例如 String.fromCharCode()）形成字符串数据的方式之间的某种差异有关。
在下面的代码片段中，将通过文本编辑器剪切和粘贴插入 HTML 文档的字符 0x9E 的处理与从十六进制代码 0x9E 以编程方式生成的相同字符（U+017E - Arial Latin small z with caron, Windows西文字符集）。这是导致这种异常行为的几个字符代码之一。奇怪的是，大多数其他大于 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 发送中究竟扮演了什么角色，但它似乎很可能是罪魁祸首。