Wat heb je allemaal geprobeerd?

1. Heb je gekeken of het aan je DB lag?
2. Heb je gekeken of de query werkt?
3. Heb je gekeken of die values gepost/opgenomen worden?
4. Heb je gekeken of JS goed doorstuurt?

of wat anders?

En waar zit enige beveiliging? Of kan iedereen dit uitvoeren?

Enne, jQuery heeft een standaard functie genaamd serialize() waarmee je automatisch een URL-encoded string kunt bouwen.

Jouw code gebruikt een langere en omslachtigere methode, en encodeert de waarden op dit moment ook helemaal niet... Als er dus gekke tekens in je data zitten die in de URL-encoded context een speciale betekenis hebben bestaat de kans dat de data-string verkeerd wordt uitgelezen aan de ontvangstkant, met onvolledige/corrupte data als gevolg.

Ook is het altijd van belang dat al je character encoderingen in de pas lopen, vooral als je via AJAX data doorgeeft, klopt het dat al je data ook UTF-8 geëncodeerd is (en utf8 in MySQL)?

Het bovenstaande kun je eenvoudig testen door eens wat exotische karakters te voeren aan de database via een AJAX-call, met hier en daar ook karakters als &, >, < en enkele en dubbele quotes. Als alles goed wordt weergegeven na opslaan en er ook weer goed uitziet als je deze data weer wilt gaan bewerken (pas dan heb je een volledig rondje gemaakt) dan heb je je werk goed gedaan. Anders... zet je een stevige pot koffie en los je dit alsnog op :).

Citaat van FangorN

Enne, jQuery heeft een standaard functie genaamd serialize() waarmee je automatisch een URL-encoded string kunt bouwen.

Jouw code gebruikt een langere en omslachtigere methode, en encodeert de waarden op dit moment ook helemaal niet... Als er dus gekke tekens in je data zitten die in de URL-encoded context een speciale betekenis hebben bestaat de kans dat de data-string verkeerd wordt uitgelezen aan de ontvangstkant, met onvolledige/corrupte data als gevolg.

Ook is het altijd van belang dat al je character encoderingen in de pas lopen, vooral als je via AJAX data doorgeeft, klopt het dat al je data ook UTF-8 geëncodeerd is (en utf8 in MySQL)?

Het bovenstaande kun je eenvoudig testen door eens wat exotische karakters te voeren aan de database via een AJAX-call, met hier en daar ook karakters als &, >, < en enkele en dubbele quotes. Als alles goed wordt weergegeven na opslaan en er ook weer goed uitziet als je deze data weer wilt gaan bewerken (pas dan heb je een volledig rondje gemaakt) dan heb je je werk goed gedaan. Anders... zet je een stevige pot koffie en los je dit alsnog op :).

Gebruikt MySQL niet automatisch UTF8 codering? en anders mysqli_set_charset();

Verder ga ik met hem akkoord.

Citaat van Tredgy

Gebruikt MySQL niet automatisch UTF8 codering? en anders mysqli_set_charset();

Ik denk dat je het toch anders moet zien. Het antwoord op jouw eerste vraag is waarschijnlijk "nee", vaak is de standaard character encoding nog steeds latin1. Verder lijkt het mij ook onverstandig om uit te gaan van een default, het is veel beter om deze expliciet in te stellen (bijvoorbeeld bij de creatie van de tabel en bij het maken van een connectie).

Dan misschien handig voor de beeldvorming wat een set_charset() functie doet. Dit moet je zien al een contract tussen jouw applicatie en de database. Dit contract bevat twee bepalingen:
- jij zorgt ervoor dat alle data die je aanlevert in de overeengekomen character encoding is opgesteld
- de database zorgt ervoor (of doet in ieder geval een oprechte poging) om alle data die zij teruggeeft aan te leveren in de overeengekomen character encoding

Dit is dus de "taal" waarmee jullie met elkaar praten, maar dat zegt helemaal niets over welke character encoderingen de tabellen of de data daarin zou moeten hebben en met een set_charset() methode kun je dit ook niet afdwingen omdat dit al is vastlgelegd in de definities van de tabellen zelf.

Indien jouw website UTF-8 is en jouw database enkel latin1 tabellen bevat kun je dus nog steeds set_charset('utf8') gebruiken: als je iets opvraagt vertaalt MySQL de latin1 data naar utf8 en als je data wegschrijft vertaal MySQL de UTF-8 data naar latin1 (maar dat laatste zal mogelijk niet altijd passen).

Beschouw set_charset() dus als "de character encoding die je op jouw website wenst te gebruiken". Je moet er dan dus ook zorg voor dragen dat je, als je data wegschrijft naar een database, deze data aanlevert in de overeengekomen character encoding anders gaat het mis.

Citaat van FangorN

Ik denk dat je het toch anders moet zien. Het antwoord op jouw eerste vraag is waarschijnlijk "nee", vaak is de standaard character encoding nog steeds latin1. Verder lijkt het mij ook onverstandig om uit te gaan van een default, het is veel beter om deze expliciet in te stellen (bijvoorbeeld bij de creatie van de tabel en bij het maken van een connectie).
Dan misschien handig voor de beeldvorming wat een set_charset() functie doet. Dit moet je zien al een contract tussen jouw applicatie en de database. Dit contract bevat twee bepalingen:
- jij zorgt ervoor dat alle data die je aanlevert in de overeengekomen character encoding is opgesteld
- de database zorgt ervoor (of doet in ieder geval een oprechte poging) om alle data die zij teruggeeft aan te leveren in de overeengekomen character encoding

Dit is dus de "taal" waarmee jullie met elkaar praten, maar dat zegt helemaal niets over welke character encoderingen de tabellen of de data daarin zou moeten hebben en met een set_charset() methode kun je dit ook niet afdwingen omdat dit al is vastlgelegd in de definities van de tabellen zelf.

Indien jouw website UTF-8 is en jouw database enkel latin1 tabellen bevat kun je dus nog steeds set_charset('utf8') gebruiken: als je iets opvraagt vertaalt MySQL de latin1 data naar utf8 en als je data wegschrijft vertaal MySQL de UTF-8 data naar latin1 (maar dat laatste zal mogelijk niet altijd passen).

Beschouw set_charset() dus als "de character encoding die je op jouw website wenst te gebruiken". Je moet er dan dus ook zorg voor dragen dat je, als je data wegschrijft naar een database, deze data aanlevert in de overeengekomen character encoding anders gaat het mis.

Ahzo, dankjewel weer wat geleerd.

Ik zie geen enkele of dubbele quotes, < punthaken >, en ook geen exotische karakters zoals ë of € of ™ of wat dan ook.