Sonderzeichen in Ajax

[Sven Rautenberg]

Moin!

Überhaupt, warum benutzt du nicht UTF-8? Was hat dein EDITOR mit der Speicherung von Text in der Datenbank zu tun?

Meine DATENBANK ist ja auch UTF-8 codiert. Die Kollation der einzelnen Tabellen ist latin1_swedish_ci (voreinstellung).

Entscheidend ist, was die Tabellen bieten. Und das ist kein UTF-8. Und mit der Wahl von "swedish_ci" hast du überdies noch eine in Deutschland höchst ungewöhnliche Sortierregel aktiviert.

Wenn ich allerdings jedes Glied der Kette UTF-8 codieren will, ist mein Editor ebenfalls betroffen.

Phase 5 darf ja laut seiner Lizenz nur für private Zwecke kostenlos eingesetzt werden, darüber hinausgehender Einsatz erfordert den Kauf einer Lizenz. Und abgesehen davon ist seine Unfähigkeit, UTF-8 zu verarbeiten, noch ein weiterer Grund, von diesem Editor Abschied zu nehmen. Er ist schlicht nicht mehr zeitgemäß.

Aber auf diese Diskussion von wegen UTF-8 ja nein wollte ich gar nicht hinaus, sofern die Lösung dieses Problems auch ohne UTF-8 geht.

Das ist überhaupt nicht »natürlich«.
Die meisten Browser haben heutzutage eingestellt, dass sie URIs mit UTF-8 an den Server senden. Es sollte dann statt %C4 daher %C3%84 herauskommen.

Hmm, Firefox nutzt jedenfalls %C4.

Mutmaßlich codiert er den eingegebenen Umlaut auf Basis der Codierungsangabe der Webseite, um die aufzurufende URL zu bilden.

Dagegen kann man ja was tun. encodeURIComponent() ist die Funktion, in die du alle Variablen stecken musst, um "sichere" Werte für den Transport als URL-Parameter zu erhalten. Die feststehenden Bestandteile deiner von AJAX aufgerufenen URL kannst du ja manuell von gefährlichen Zeichen freihalten bzw. diese Codieren - aber wenn in dein Formular "böse Zeichen" wie "=" oder "&" eingegeben werden, wird der jetzige Mechanismus deiner AJAX-Funktion fehlerhafte URLs zusammenbauen.

Durch den Einsatz von encodeURIComponent() kriegst du dann auch automatisch alle Umlaute und sonstigen Sonderzeichen in die Prozent-Escape-Version von UTF-8 gewandelt.

- Sven Rautenberg