[MSIE, FireFox en JPSpan] Character Encoding

[DPLuS]

De laatste tijd maak ik veel gebruik van JPSPan (http://jpspan.sourceforge.net, maar deze site is al een tijdje down) om structuur te geven aan mijn POST-string die ik via een submit POST naar een PHP pagina.
JPSpan serializeert de POST-string en ik kan hem dan netjes als een structuur aanleveren aan PHP, waarmee ik via unserialize() de boel weer kan on-serializeren.

Alleen loop ik nu tegen twee problemen aan:

1: Karakters boven ASCII getal 127 worden weggegooid door JPSpan, dat komt door deze regeltjes in de JPSpan library:

JavaScript:

    encodeString: function(v) {
        var s = ''
        for(var n=0; n<v.length; n++) {
            var c=v.charCodeAt(n);
            Ignore everything but ASCII
            if (c<128) {
                s += String.fromCharCode(c);
            }
        }
        return 's:'+s.length+':"'+s+'";';
    },

2: JPSpan + FireFox + Enters (\r\n) gaat mis, want FireFox telt een ENTER als 1 karakter, terwijl dit in Internet Explorer goed gaat, die telt namelijk 2 karakters voor een enter. Dus de string-length is dan eigenlijk te kort en dan krijg je deze errors in FireFox:

code:

a:1:{s:9:"textfield";s:1:"
";}

Notice:  unserialize(): Error at offset 27 of 31 bytes in c:\htdocs\temp\serialize_bleeding_edge.php on line 15

Dit gaat zowel op windows als op linux fout trouwens.

Mijn 2 vragen:

1: Kan ik die ASCII check gewoon eruit slopen en ervan uit gaan dat alle moderne browsers momenteel hun POST-waardes automatisch in UTF8 sturen naar de server? Of is dit te manipuleren??

2: Is het probleem met die enters gewoon een ordinaire bug in FireFox, of hebben meer mensen dit probleem gehad??

Extra info:
Download JPSpan:
http://prdownloads.sourceforge.net/jpspan

Alvast bedankt.

[crisp]

De afspraak is dat browsers POST-content 'normaliseren'; enters dienen daarbij omgezet te worden naar \r\n (CRLF). Firefox doet dit ook prima, maar pas bij de POST zelf. In dit geval bewerk je de content eerst met javascript, dus zal je rekening moeten houden met die normalisatie; het eenvoudigst is dat te doen door zelf te normaliseren bijvoorbeeld met een regexp:

JavaScript:

v = v.replace(/\r\n|\r|\n/g, '\r\n');

de GoT JS bevat ook een javascript serialize/unserialize implementatie waarin ik dat ook doe:

JavaScript:

String.prototype.toPHP=function()
{
    var s = this.replace(/\r\n|\r|\n/g, '\r\n');
    return 's:' + s.length + ':"' + s + '";';
}

Verder is de characterset van je document (hetzij via HTTP headers gedicteerd, of bij gebrek aan headers door de META-tag in je document) bepalend voor de karakters die verstuurd kunnen worden. Op zich is er niets mis mee om de volledige range (dus ASCII en de extended range t/m karaktercode 255) in een POST op te nemen.
UTF-8 is echter een ander verhaal aangezien karaktercodes daarin verder gaan dan 255, maar volgens mij hoeft dat op zich ook geen probleem te zijn als je document ook als UTF-8 geserveerd wordt.

[ Voor 59% gewijzigd door crisp op 02-09-2005 23:36 ]