2010-03-29 9 views
5

Ich habe gerade meine erste Ajax-Funktion mit jQuery erstellt, die tatsächlich funktioniert, aber leider die Zeichencodierung (für Zeichen wie ä, ö, ü, ß, č, ć, å , ø) ist ein Albtraum.jQuery: AJAX Umlaute & Sonderzeichen sind ein Chaos

Meine Dateien und meine Datenbank sind alle UTF-8. Ich habe eine Vielzahl von Optionen in der Ajax-Funktion und der PHP-Funktion ausprobiert, von denen keine zufriedenstellend war.

Das ist mein Ajax

var dataString = { 
'name': name, 
'mail': mail 
// other stuff 
} 


    $.ajax({ 
type: "POST", 
url: "/post.php", 
data: dataString, 
contentType: "application/x-www-form-urlencoded;charset=UTF-8", 
cache: false, 
success: function(html){ 
// do stuff 
} 

Ich habe versucht, es ohne content: "application/x-www-form-urlencoded; charset = UTF-8" und ich habe versucht, die betroffenen Daten zu wickeln in encodeURIComponent(), von denen keiner gearbeitet hat.

Wenn ich, dass AJAX mit htmlentities() in meinem php, meine Umlaute im Klartext wie folgt aussehen: UE Ã, AE Ã, OE Ã, ue ü, ae å¤, oe o

und wie diese in der Datenbank: UE & Atilde; œ, AE & Atilde; „, OE & Atilde ;, ue & Atilde; & frac14 ;, ae & Atilde; & curren ;, oe o

Wenn ich nicht htmlentities() aber mysql_real_escape_string() stattdessen (oder keine), sie sehen gut aus im Klartext, aber sie sehen in der Datenbank so aus: AE à ", OE Ãœ, Ãœ à à à à à Ãà Ãe Ãœ Ãue

Ich habe schon seit Stunden unzählige Optionen getestet, aber ich kann keine Lösung finden, die funktioniert. Bisher scheint die einzige Option, die ich zu haben scheint, darin zu bestehen, dass sie in der Datenbank total durcheinander ist, aber das wäre sehr kontraproduktiv, wenn diese Datensätze bearbeitet werden müssten.

+1

Schlägt nicht Ihre letzte Beobachtung vor, dass das Problem wahrscheinlich mit der Datenbank (und vielleicht PHP) und nicht mit jQuery und AJAX ist? –

+0

Ich habe versucht, meine Datenbank-Codierung zu Latin1 zu ändern, aber es gab keinen Unterschied – rayne

Antwort

6

Ich habe versucht, die betroffenen Daten in encodeURIComponent()

Nah zu wickeln, wenn Sie in einem {} Objekt übergeben sind, wird jQuery von UTF-8 kümmern und URL-kodierenden für dich.

Wenn ich, dass AJAX mit htmlentities() in meinem php, meine Umlaute wie folgt aussehen im Klartext: UE Ã, AE Ã, OE Ã, ue ü, ae å¤, oe o

Wenn Sie htmlentities() verwenden müssen, haben Sie es zu sagen, Ihre Codierung UTF-8 im optionalen $charset Argument ist, sonst wird es (dummerweise) default alle Bytes als ISO-8859-1 zu behandeln und sie zu unangemessenen kodieren Entitätsreferenzen, eine für jedes Byte.

Besser ist es, stattdessen htmlspecialchars() zu verwenden, da es nicht versucht, unnötige Codierung auf andere Zeichen als die wenigen ASCII-Zeichen anzuwenden, die es wirklich brauchen.

Und wie dies in der Datenbank: UE Ü, AE à „, OE Ã-, ue ü, ae å¤, oe o

Wie geht es Ihnen, dass die Bestimmung? Kennt das Tool, das Sie verwenden, um Daten aus der Datenbank abzurufen, über Unicode? (Wenn es eine dubiose PHP-Web-Admin-Schnittstelle ist, vielleicht nicht. PHP ist nicht gut in Unicode.)

Es ist möglich, dass Sie richtige UTF-8 Bytes in der Datenbank speichern, aber in Tabellen mit einem markiert Latin-1-Kollatierung.Dies funktioniert, sofern Sie die gleichen Bytes erhalten, die Sie eingegeben haben, aber wenn MySQL nicht weiß, dass es sich um UTF-8-Bytes handelt, dann funktioniert die Groß-/Kleinschreibung außerhalb des ASCII-Bereichs nicht richtig , so auf der Suche nach Ä wird nicht übereinstimmen ä. Das mag dir egal sein oder nicht.

Wenn ich htmlentities nicht(), aber mysql_real_escape_string() statt

Whoah, vorsichtig. HTML-Escaping ist für die Endstufe auf der Seite. SQL-string-literal-escaping tritt beim Erstellen einer SQL-Abfrage auf. Sie brauchen sie beide, aber mischen Sie sie nicht zusammen oder versuchen Sie, sie auf der gleichen Stufe zu tun, oder Sie werden alle Arten von seltsamen Fluchten haben - schiefgelaufene und potentielle Schwachstellen.

+0

Wenn ich htmlspecialchars() verwenden, sehen die Zeichen auf der Website gut, aber so in der Datenbank: (unabhängig davon, ob die Datenbank UTF-8 oder ist Latein1). Ich benutze SQLyog, um auf die Datenbank zuzugreifen, ich habe kein Webinterface wie phpmyadmin. Sie sehen auch chaotisch aus, wenn ich meine benutzerdefinierte Admin-Oberfläche benutze, um sie zu bearbeiten. – rayne

+0

OK, SQLyog * Ansprüche * Unicode zu unterstützen, so hoffentlich sollte es richtig sein. Wenn es für Sie wichtig ist, dass die Daten in der Admin-Oberfläche richtig aussehen, müssen Sie 'CREATE TABLE ... CHARACTER SET utf8' verwenden, um Ihre Tabellen zu erstellen, und mysql_set_charset ('utf8')' aus PHP aufrufen, bevor Sie die Datenbank verwenden Verbindung. – bobince

3

Es klingt wie das Problem beim Einfügen der Daten in die Datenbank auftritt. Verwenden Sie MySQL? Nach dem Anschluss der Server-Problem zu Ihrer Datenbank der Abfrage:

SET NAMES utf8; 

Dadurch wird den Datenbankserver sagt, dass die Client-Verbindung wünscht, Daten in UTF-8 zu senden und es als solches zu interpretieren.

Auch wenn diese Daten an den Browser zu senden stellen Sie sicher,

header('Content-type: text/html; charset=utf-8'); 

die Contenttype-Header setzen Dies wird dem Browser mitteilen, die Daten als UTF-8 zu interpretieren.

1

Versuchen verwenden diese Funktion anstelle von htmlentities

htmlspecialchars()

0

Ich habe endlich eine Lösung gefunden, die für mich arbeitet; Ich entfernt die contentType: "application/x-www-form-urlencoded;charset=UTF-8" von meinem jQuery Ajax, verwende ich nur htmlentities($value, ENT_NOQUOTES, 'UTF-8'); für die Verarbeitung der Daten mit SQL und meine Datenbank ist auf utf8 Unicode festgelegt.

Die Zeichen werden korrekt angezeigt und als ä für ä usw. in der Datenbank gespeichert.

+0

Bitte speichern Sie keine HTML-kodierten Daten in der Datenbank! HTML-Escaping ist ein Ausgabeproblem, das immer und nur bei der Seitenausgabe auftreten sollte. Es gehört nicht in die Datenzugriffsebene. Wenn Sie HTML-kodierte Daten in die Datenbank einfügen, können Sie keine Suchanfragen wie 'LIKE '% uml%' machen (es wird nicht möglich sein, den Unterschied zwischen einem umkodierten Umlaut und dem Text" uml "zu erkennen) Jede 'SUBSTRING'-Operation (einschließlich des impliziten Trimmens aufgrund von Feldlängenbeschränkungen) birgt das Risiko, eine Entity-Referenz zu brechen und fehlerhaftes HTML zu erzeugen, und es wird jegliche Nicht-HTML-Verwendung der Tabellendaten wie das Senden von Mail durcheinander bringen. – bobince

+0

Oh wirklich?Ich wusste das nicht, aber ich bin ein schlechter Programmierer im Allgemeinen;) Wenn ich die htmlenities() aus meinem Skript entfernen, sehen meine Sonderzeichen wieder so in der Datenbank: ¼ Seltsam, wenn ich sende die Daten nur über PHP (bei Deaktivierung von Javascript), sehen sie in der Datenbank (ä) gut aus. Das Problem wird wahrscheinlich von jQuery ajax verursacht. – rayne