Been revisiting the question of why some kinds of character data are corrupted when sent via an ajax call to a webserver, no matter what encoding is used. Even if the data is precoded into a 7-bit format, what comes out is still not always equal to what went in.
I was using a third party javascript base64 encoder to prepare ajax data, and initally thought this had a bug. But, other base64 encoders show exactly the same problem -including one which claims full unicode compatibility- and there are several forum reports of similar problems, none of which seem to have been fully resolved. So, I don't think the encoder itself is at fault.
I noticed that the corruption typically arises with data cut-and-pasted from other programs into CKEditor, if that data contains certain specific high-order ASCII/ANSI codes.
A few more tests seem to indicate that the problem has to do with some kind of discrepancy between the way javascript reads character data from a webpage, and the way it forms string data from internal programmatic methods, for example String.fromCharCode().
In the snippet below, the handling of character 0x9E inserted into an HTML document by cut-and-paste from a text editor is compared with the same character generated programmatically from hex code 0x9E (U+017E - Arial Latin small z with caron, Windows Western charset). This is one of several character codes which have been seen to give rise to this anomalous behaviour. Strangely, most other >127 character-codes give no such problems, and are rendered as two-byte unicode as they should be.
<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>
With a UTF-8 page charset, gives:
Pasted Character: [0xFFFD] Resultant Code(s): ~65533~
Generated Character: [blank] Resultant Code(s): ~158~
With a default page charset, gives:
Pasted Character: ž Resultant Code(s): ~382~
Generated Character: [blank] Resultant Code(s): ~158~
Notably, neither handling of the pasted character is correct, and there is no such ANSI code as 382!
Both outputs are single byte.
Strictly speaking this character is 8-bit ASCII/ANSI, which js does not claim to handle, however it is perfectly legitimate for it to be pasted into an HTML editor, for example from a text document. Thus the javascript subsystem should be capable of handling such input without bugs arising. It certainly seems to me, anyway, that generating the same character string in two different ways should not return two different results.
Any thoughts on this would be welcome. I am not sure exactly what role this anomaly plays in corrupting the ajax send, but it seems likely it is the culprit.
