Zeichenkodierung

Zeichensatz und MySQL

Bei der Anlage einer Datenbank wird festgelegt, welcher Zeichensatz Tabellenspalten standardmäßig zugewiesen werden soll, wenn Tabellenspalten angelegt werden und die Tabellenspalten einen der drei Datentypen "CHAR", "VARCHAR" oder "TEXT" erhalten. Auch wenn später der Datentyp einer Tabellenspalte zu "CHAR", "VARCHAR" oder "TEXT" geändert wird und der Spalte noch kein Zeichensatz zugewiesen war, wird ihr jener Zeichensatz zugewiesen, der als Standardzeichensatz für die Datenbank festgelegt ist. Es ist in der Regel allerdings möglich, den Zeichensatz für Spalten mit den Datentypen "CHAR", "VARCHAR" oder "TEXT" zu ändern.

Der Zeichensatz, welcher einer Spalte zugewiesen ist, entscheidet darüber, welche Zeichen überhaupt in der Spalte gespeichert werden dürfen. Der Zeichensatz 'ASCII' ist z.B. eine kleine Teilmenge von 'UTF-8'. Unbedingt zu beachten ist, bei der Verwendung von MySQL, dass MySQL für die Zeichnkodierung 'UTF-8' die Bezeichnung 'utf8mb4' verwendet. Der MySQL-Zeichensatz mit der Bezeichnung 'utf8' ist dagegen nur eine Teilmenge von 'utf8mb4'. In MySQL können in den Spalten, denen der Zeichensatz 'utf8' zugewiesen ist, nicht jene Zeichen aus 'UTF-8' gespeichert werden, deren Code aus 4 Bytes besteht.

Der Zeichensatz einer Spalte, die keinem Index zugewiesen ist, kann nachträglich ohne Probleme geändert werden, wenn alle Zellen der Spalte leer sind oder alle Werte in den Zellen der Spalte nur Zeichen enthalten, die im neuen Zeichensatz auch enthalten ist. Fehlt im neuen Datensatz ein Zeichen, welches im bisher zugewiesenen Zeichensatz vorhanden, kann die Änderung zu Datenverlusten führen.
Die Änderung funktioniert allerdings nur dann reibungslos, wenn nicht im gleichen Befehl auch die Zeichenkodierung einer Spalte geändert werden soll, die einem Index zugeordnet ist. Wenn eine Spalte aus dem Befehl einem Index zugeordnet ist, weist MySQL - mindestens bei der Verwendung von phpMyAdmin zur Datenbankadministration - den Spalten, die keinem Index zugewiesen sind und deren Codierung geändert werden soll, den Datentyp "BLOB" zu und ändert damit auch die Zeichenkodierung zu "binary". Das hat zur Folge, dass der Inhalt der Tabellenzellen ausgelagert und in den Tabellenzellen jeweils ein Verweis auf den tatsächlichen Speicherort des BLOBs gespeichert wird. Ruft man danach die Tabellenansicht von phpMyAdmin auf, so wird nur der Datentyp und die enthalten Datenmenge angezeigt (z.B. BLOB - 25 B), der eigentliche Inhalt bleibt für das menschlische Auge verborgen.
Wird versucht mit phpMyAdmin die Zeichenkodierung einer Spalte zu ändern, die einem Index zugeordnet ist, versucht MySQL auch dieser Spalte den Datentyp "BLOB" zuzuweisen. Weil aber Spalten mit dem Datentyp "BLOB" nur in einfachen Indizes enthalten sein dürfen und außerdem für diese Spalten immer festgelegt werden muss, wie viele Bytes (gezählt ab dem Beginn der Bytefolge) im Index enthalten sein sollen, scheitert die Umwandlung der Zeichenkodierung immer dann, wenn die Spalte einem eindeutigen Index zugeordnet ist oder bei der Zuordnung zu einem nichteindeutigen Index zuvor keine entsprechende Festlegung hinsichtlich der Anzahl der Zeichen erfolgte.

Oftmals sollen die Einträge der Spalten vom Typ "VARCHAR" alphabetisch sortiert werden. Aufgrund der unterschiedlichen Zeichensätze, die das Alphabet der verschiedenen Sprachen bilden, gibt es für die verschiedenen Sprachen unterschiedliche Sortier-Regeln. In Deutschland wird zusätzlich noch hinsichtlich der Sortierung in Wörterbüchern (latin1_german1_ci, utf8_unicode_ci, utf8bm4_unicode_ci) und in Telefonbüchern (latin2_german1_ci, utf8_german2_ci, utf8bm4_german2_ci) unterschieden. Welche Sortier-Regeln anzuwenden ist, wird zunächst für die Datenbank standardmäßig eingestellt. Diese Regel kann aber für jede Spalte der Datentypen "CHAR", "VARCHAR" oder "TEXT" mit dem Wert für die Eigenschaft "COLLATE" problemlos jederzeit und ohne Datenverluste geändert werden, wenn sich dabei nicht der verwendete Zeichensatz für die Spalte ändert.

Bei jedem Verbindungsaufbau mit einer Datenbank führt das System unmittelbar nach dem Verbindungsaufbau den mySQL-Befehl "SET NAMES 'charset' " aus, um die Zeichenkodierung für den Datenaustausch zwischen der Anwendung und der Datenbank einzustellen. Als Wert für 'charset' verwendet das System den Wert, welcher der Datenabank im Element "set_names" in der Datei "__wm/kern/__variablen/datenbanken.php" zugeordnet ist. Die Angaben in der Datei können nicht mit einem Systemformular geändert werden. Der Befehl set_names wird allerdings nur dann ausgeführt, wenn dies laut den Konfigurationseinstellungen für den Server nicht verboten ist.

Für Datenbankzugriffe, bei denen Information aus den Systemtabellen abgerufen und/oder in Systemtabellen gespeichert werden sollen, muss für die Verbindung "SET NAMES 'utf8mb4' " gewählt werden, weil die System-Formulare, welche auf die Systemtabellen zugreifen, Werte in dieser Zeichenkodierung erwarten und schreiben. Bei einer abweichenden Codierungsanweisung würde MySQL ansonsten bei Lese- und Schreibbefehlen jeweils eine Umcodierung ausführen, wodurch Datenverluste möglich sind.

Für anwendungsspezifische Datenbanktabellen kann eine Verbindung mit einer anderen Zeichenkodierung aufgebaut werden. Allerdings muss der Wert für "charset" im Befehl "SET NAMES 'charset' " zu der Codierung passsen, mit der Zeichenketten in diesen Tabellen gespeichert werden, damit der Informationsaustausch reibungslos verlaufen kann.

zum Anfang

Zeichen werden von Anwendungsprogrammen interpretiert

Wenn man eine Zeichenkette "ZK", die per POST- oder GET- gesendet wurde, mit PHP empfängt oder eine Zeichenkette "ZK" mit einem php-Befehl wie readfile(), file() oder gets() aus einer Datei oder per Befehl aus einer MySQL Datenbank einliest, ist diese Zeichenkette "ZK" in PHP vom Datentyp her ein String, solange keine Veränderungen (z.B. mit Funktionen oder Operatoren) an der Variablen, welcher die Zeichenkette "ZK" im Arbeitsspeicher zugeordnet ist, ausgeführt werden. In diesem String-Zustand wirken sich Zeichen, welche eine Funktionswirkung haben können, nicht aus.

zum Anfang

Zeicheninterpretation durch PHP-Server

Wird aus einem Browser heraus auf einem PHP-Server eine Datei mit der Dateiendung .php aufgerufen, übermittelt der php-Server sämtliche Zeichen, die vor dem ersten Auftreten der Zeichenfolge <?php stehen, an den Browser. Sofern dem Browser nicht am Beginn der Zeichenfolge Informationen übermittelt werden, wie er mit dieser Zeichenfolge umzugehen hat, interpretiert er ihn als HTML-Code und versucht ihn auszugeben.
Ab der Zeichenfolge <?php führt der PHP-Server dann sämtlichen Code aus, bis er auf eine Zeichenfolge ?> stößt, die sich außerhalb eines Strings und außerhalb eines Blockkommentars befindet. Der Code wird allerdings nur ausgeführt, wenn er syntaktisch korrekt ist. Als Start-Tag ist seit der php-Version 5.4.0 immer auch die Zeichenfolge <?= gültig.
Folgt auf das schließende php-Tag (?>) direkt ein weiteres öffnendes php-Tag, so schließt sich nahtlos an den ersten php-Block ein zweiter php-Block an. Steht nach dem schließenden php-Tag allerdins ein anderes Zeichen/eine andere Zeichenfolge, wird diese ohne jegliche Verarbeitung durch den php-Server an den Browser ausgeliefert. Sofern der php-Server nach dem Start-Tag kein Ende-Tag in der Datei findet, interpretiert er sämtlichen Code, der auf das Start-Tag folgt als php-Code.
Wenn in der Konfigurationsdatei statt short_open_tag=Off der Befehl short_open_tag=On steht, interpretiert der php-Server jede Zeichenfolge, die mit <? beginnt, als öffnendes Tag für einen php-Abschnitt. Es wird aber nicht empfohlen, die Kurzform als Start-Tag zuzulassen, weil auch in anderen Programmiersprachen die Start-Tags mit dieser Zeichenfolge beginnen können und der PHP-Server sonst nicht erkennen kann, ob es ein Start-Tag für einen Block mit php-Code oder z.B. ein Block mit XML-Code ist.
Vor der php-Version 7.0.0 waren auch die Zeichenfolgen <%, <%= (ASP-Tags) und der Script-Tag <script language="php"> als Start-Tags für einen php-Abschnitt zugelassen. Mit dem Entfernen der Start-Tags <% und <%= wurde auch das zugehörige Ende-Tag %> entfernt.

In einem PHP-Block können zwei Arten von Kommentaren enthalten sein, Zeilenkommentare und Block-Kommentare. Innerhalb der Block-Kommentare und der Zeilenkommentare können beliebige Zeichen und Zeichenfolge stehen. Der Inhalt der Kommentare wird vom php-Server sowohl beim Parsen als auch bei der Ausführung des php-Codes ignoriert.
Ein Block-Kommentar kann mit der Zeichenfolge /** und auch mit der Zeichenfolge /* beginnen. Der Block-Kommentar endet mit dem ersten Auftreten der Zeichenfolge */. Die Zeichenfolgen /* und /** werden vom php-Server allerdings nur dann als Start für einen Block-Kommentar interpretiert, wenn sie sich nicht innerhalb eines Strings oder eines Kommentars befinden.
Ein Zeilenkommentar beginnt mit der Zeichenfolgem // und endet mit dem Zeilenumbruch, es sei denn, in der Zeile folgt nach dem Kommentarbeginn die Zeichenfolge ?>. Dann endet sofort der Zeilenkommentar und gleichzeitig der php-Block. Die Zeichenfolge // beginnt allerdings nur dann einen Zeilenkommentar innerhalb des php-Blocks, wenn sie sich nicht innerhalb eines Strings oder eines Kommentars befindet.

Trifft der php-Server innerhalb eines php-Blocks, aber außerhalb eines Kommentars und außerhalb eines Strings, auf ein Apostroph ', interpretiert er das Apostroph als Beginn eines Strings, egal welches Zeichen unmittelbar vor dem Apostroph notiert ist. Genauso verhält er sich, wenn er auf ein doppeltes Anführungszeichen " stößt, welches sich außerhalb eines Kommentars und eines Strings befindet. Ob ein String mit einem Apostroph oder einem doppelten Anführungszeichen beginnt, wirkt sich darauf aus, wie die Zeichen innerhalb des Strings vom php-Server interpretiert werden.

Ein String, der mit einem Apostroph beginnt, endet erst dann, wenn der php-Server in der auf das Apostroph folgenden Zeichenfolge auf ein Apostroph stößt, welches nicht maskiert ist. Ein Apostroph ist dann maskiert, wenn unmittelbar vor dem Apostroph eine ungerade Anzahl von Backslashs notiert ist. Ein Apostroph ist also dann nicht maskiert, wenn vor ihm ein anderes Zeichen als ein Backslash oder eine gerade Anzahl von Backslashes steht.
Entdeckt der php-Server innerhalb eines Strings, welcher durch Apostrophs begrenzt wird, einen Backslash \ ("B1"), prüft es, welches Zeichen auf "B1" folgt. Folgt auf "B1" ein anderes Zeichen als ein Apostroph oder ein Backslash, ist "B1" ein Backslash ohne Funktionsbedeutung. Ist das Zeichen, welches auf "B1" folgt, ein weiterer Backslash, "verschmelzen" die beiden Backslashes intern zu einem Backslash ohne Funktionsbedeutung. Folgt auf "B1" ein Apostroph, ist dieses für den Server "maskiert", er interpretiert es daher nicht als schließenden Begrenzer für den String.
Folgen mehr als zwei Backslashs unmittelbar aufeinander, verschmelzen jeweils zwei der Backslashes zu einem Backslash ohne Funktionsbedeutung, aus 4 Backslashes entstehen also 2 Backslashes ohne Funktionsbedeutung, aus 6 Backslashes 3, usw. Bei einer ungeraden Anzahl ist der letzte der Backslashes ebenfalls ein Backslash ohne Funktionsbedeutung, es sei denn auf diesen letzten Backslash folgt ein Apostroph. Dann maskiert das letzte Backslash der Backslashfolge dieses Apostroph. Es wird dann vom php-Server nicht als Ende des Strings interpretiert.
Alle anderen Zeichen haben innerhalb eines Strings, der durch Apostrophs begrenzt wird, keinerlei Wirkung.

Beginnt der String statt mit einem Apostroph mit einem Anführungszeichen, endet dieses erst dann, wenn der php-Server in der auf das Anführungszeichen folgenden Zeichenkette auf ein Ausführungszeichen stößt, welches nicht maskiert ist. Für die Maskierung eines doppelten Anführungszeichen gelten die Aussagen aus dem vorherigen Absatz zur Maskierung eines Apostrophs analog.
Auch bei einem String der durch doppelte Anführungszeichen begrenzt wird, "verschmelzen" zwei unmittelbar aufeinander folgende Backslashs zu einem Backslash ohne Funktionsbedeutung.
Anders als bei Strings die mit Apostrophs begrenzt werden, besitzt der Backslash innerhalb von Strings, die mit doppelten Anführungszeichen begrenzt werden, auch vor einigen anderen Zeichen eine Funktionswirkung. In den meisten Fällen davon führt der Backslash dazu, dass das nachfolgende Zeichen durch ein Steuerzeichen ersetzt wird. Die Steuerzeichen können sich allerdings erst dann auswirken, wenn der String durch einen Befehl verarbeitet wird, wobei es vom Befehl abhängt, ob und welche Wirkung ausgelöst wird.

zum Anfang

Zeicheninterpretation durch MySQL

Wird vom PHP-Server ein SQL-Befehl erstellt, so ist dieser Befehl innerhalb von PHP ein String. Wird dieser String mit dem entsprechenden Befehl an den Datenbankserver gesendet, so ist der PHP-String innerhalb des Datenbankservers zunächst nur eine einfache Folge von Bytes. Mit der Anweisung "set_names" wurde dem dem MySQL-Server bei der Herstellung der Datenbankverbindung mitgeteilt, welchen Zeichensatz der MySQL-Server anwenden muss, um diese Bytefolge in einen für den Datenbankserver les- und interpretierbaren Befehl umzwuwandeln.

In PHP kann der gesamte Befehl entweder mit doppelten Anführungszeichen oder mit Apostrophs begrenzt werden, um ihn als String zu kennzeichnen.
Weil innerhalb des Befehls sämtliche Werte, die von MySQL als Strings interpretiert werden sollen, entweder durch Apostrophs oder durch doppelte Anführungszeichen zu kapseln sind und innerhalb von MySQL ahbängig vom SQL-Modus die doppelten Anführungszeichen sowohl als Begrenzer für Werte als auch für Identifizierer interpretiert werden, wird empfohlen, jene Zeichenfolgen innerhalb des Befehls, die MySQL als Werte mit dem Datentyp String interpretieren soll, immer mit Apostrophs zu kapseln und jene Zeichenfolgen, die MySQL als Identifizierer interpretieren soll, mit dem Akzentzeichen zu kapseln, sofern eine Kapselung dieser Zeichenfolgen erforderlich oder empfehlenswert ist. Das doppelte Anführungszeichen sollte also innerhalb von SQL-Befehlen nicht als Begrenzer eingesetzt werden, um Interpretationsfehler zu vermeiden.

Identifizierer in MySQL

Für Identifizierer können bis auf das ANSII-Zeichen NUL (U+0000) und die Unicode-Zeichen an den Code-Positionen U+10000 und höher alle anderen Unicode-Zeichen verwendet werden. Dabei ist allerdings Folgendes zu beachten:
Die Zeichenfolge "I" für einen Identifizierer muss immer dann gekappselt werden,
wenn MySQL die Zeichenfolge für "I" als ein reserviertes Wort interpretieren könnte,
oder wenn "I" auch andere Zeichen als die ASCII-Zeichen [0-9,a-z,A-Z$_] (basic Latin letters, digits 0-9, dollar, underscore) und die Unicode-Zeichen U+0080 .. U+FFFF enthält,
oder wenn "I" nur aus Ziffern [0-9] besteht.

Die Zeichenfolge "I" sollte im SQL-Befehl immer dann gekapselt werden,
wenn "I" aus einer externen Quelle stammt (z.B. per Formular erhalten oder aus einer Datei eingelesen wurde), und nicht gewährleistet ist, dass "I" ein syntaktisch korrekter Identifizierer ist, der nicht gekapselt werden muss. Würde die Kapselung fehlen, wäre mit "I" eine SQL-Injektion möglich.

Ergänzender Hinweis:
Enthält der Identifizierer "I" selber das Zeichen ` oder das Zeichen ", so muss "I" gekapselt werden.
Wird "I" mit dem Zeichen ` gekapselt, muss innerhalb von "I" jedes vorhandene ` maskiert werden, indem statt ` die Zeichenfolge `` notiert wird, das Akzentzeichen ` muss also verdoppelt werden.
Analoges gilt für das doppelte Anführungszeichen ", wenn dieses bei aktivem SQL-Modus "ANSI_QUOTES" zur Kapselung von "I" verwendet wird.

Strings in MySQL

Wenn MySQL beim Lesen und "Übersetzen" der Bytefolge auf eine Zeichenkette "ZK" stößt, die es als String interpretieren soll, erzeugt MySQL intern daraus einen String "S", indem es Zeichen für Zeichen aus der Zeichenkette "ZK" in "S" einfügt, sofern das Zeichen für MySQL keine Funktionsbedeutung hat. Wenn das Zeichen aus "ZK" für MySQL eine Funktionsbedeutung hat, reagiert MySQL auf das Zeichen. Welche Zeichen für MySQL eine Funktionsbedeutung haben, richtet sich auch nach den Server-Einstellungen und der "Umgebung" in welcher der Datenbankserver läuft.

MySQL "merkt" sich, ob ein Apostroph oder ein doppeltes Anführungszeichen den String eingeleitet hat, und weist diesem Zeichen dann die Bedeutung "kapselt den String" zu. Das andere Zeichen ist für MySQL dann innerhalb des Strings ein Zeichen ohne Bedeutung. Angenommen der String wurde mit einem Apostroph eingeleitet. Sobald MySQL in der darauf folgenden Bytefolge erneut ein Apostroph entdeckt, geht MySQL davon aus, dass an dieser Stelle der String endet, es sei denn, dieses Apostroph ist für MySQL "maskiert".

In einem String, der mit einem Apostroph eingeleitet wurde, ist ein Apostroph dann maskiert, wenn zwei Apostrophs unmittelbar aufeinanderfolgen, in diesem Fall "verschmelzen" die beiden Apostrophs für MySQL zu einem Apostroph ohne Funktionsbedeutung.
Wurde der String dagegen durch ein doppeltes Anführungszeichen eingeleitet, brauchen innerhalb des Strings die Apostrophs nicht maskiert zu werden. Stattdessen müssen dann die doppelten Anführungszeichen maskiert werden, die im String enthalten sein sollen. Auch für diese ist eine Maskierung durch Verdoppelung des Zeichens in der Bytefolge "ZK" möglich.
Die Maskierung durch Verdoppelung funktioniert unabhängig vom SQL-Modus, aber jeweils nur für das Zeichen, welches den String begrenzt. Eine Verdoppelung des Apostrophs in einem String, der durch doppelte Anführungszeichen begrenzt wird, würde dazu führen, dass auch in "S" zwei Apostrophs unmittelbar aufeinanderfolgen würden.

Eine weitere Maskierungsvariante ist das Voranstellen eines Backslashs vor einem Apostroph innerhalb eines Strings, der durch ein Apostroph eingeleitet wurde. Diese Markierungsvariante setzt allerdings voraus, dass der SQL-Modus NO_BACKSLASH_ESCAPES nicht aktiviert ist.
Wenn der SQL-Modus NO_BACKSLASH_ESCAPES aktiviert ist, interessiert sich MySQL nicht dafür, welches Zeichen auf einen Backslash folgt. In diesem Fall interpretiert MySQL jeden Backslash einfach als das druckbare Zeichen \ .
Falls jedoch der SQL-Modus NO_BACKSLASH_ESCAPES ausgeschaltet ist, "reagiert" MySQL, wenn es innerhalb des Strings auf einen Backslash stößt. In diesem Fall bilden der Backslash und das nachfolgende Zeichen für MySQL immer eine Einheit "E". Bestimmte Kombinationen, die zudem case-sensitiv sind - führen dazu, dass MySQL die Einheit "E" durch ein anderes Zeichen ersetzt. Diese Ersetzungsregeln stehen in der nachfolgenden Tabellen. In fast allen anderen Fällen führt der Backslash, mit dem "E" beginnt, dazu, dass der Backslash sozusagen "verworfen" wird, und MySQL das zweite Zeichen aus "E" als ein Zeichen ohne jede Funktionsbedeutung betrachtet.
Die Ausnahmen von der letzten Regel betreffen das %-Zeichen, den Unterstrich _ und den Großbuchstaben N. Steht vor dem %-Zeichen oder den Unterstrich _ ein Backslash bleibt der Backslash - unabhängig vom SQL-Modus immer für MySQL im String erhalten, es sei denn der String wird innerhalb des SQL-Befehls für einen LIKE-Vergleich verwendet. Nur in dem LIKE-Zusammenhang wird der Backslash von MySQL auch vor % und _ als Maskierungszeichen betrachtet. Er entfernt dann die Joker-Eigenschaft, welche die Zeichen % (Joker-Eigenschaft: keins oder beliebig viele Zeichen, egal welche) und _ (Joker-Eigenschaft: genau ein Zeichen, egal welches) sonst innerhalb des LIKE-Zusammenhangs besitzen. Die Zeichen-Kombination \N wird von MySQL nur bei dem Befehl LOAD DATA ... zum Wert NULL (Bedeutung: NoData) umgesetzt. Und die Ausgabe eines NULL-Wertes in eine Datei kann durch den Befehl SELECT ... INTO OUTFILE von MySQL in die Zeichenfolge \N umgesetzt werden.

In der Dokumentation zu MySQL findet sich der Hinweis, dass in manchen MySQL-Umgebungen das Zeichen NUL innerhalb von Strings maskiert werden muss, damit der String von MySQL nicht an der Position, an welcher das Zeichen NUL steht, abgeschnitten wird. Außerdem wird darauf hingewiesen, dass es nötig sein kann, das Zeichen mit der Ordnungszahl 26 zu maskieren, damit es auf Windows-Systemen nicht als EOF interpretiert wird.
Die Zeichen können allerdings nur dann mit einem Backslash maskiert werden, wenn der SQL-Modus NO_BACKSLASH_ESCAPES nicht aktiviert ist. Bei aktivierterm SQL-Modus NO_BACKSLASH_ESCAPES bleiben ansonsten die als Maskierungszeichen vorgesehenen Backslashes im String als Backslash-Zeichen ohne Funktionsbedeutung erhalten und werden z.B. beim Schreiben des Strings in die Datenbank dort zusammen mit den anderen Zeichen aus dem String eingetragen.

Um ein eindeutiges und vorhersehbares Verhalten der Skripte auf sämtlichen System bzgl. der Befehlsausführung durch MySQL zu erzielen,wird bei der Herstellung des Datenbankzugriffs mit den Funktionen db_anmelden_lesen() und db_anmelden_bearbeiten() aus der Datei __zac4web/__funktioen/db_anmelden.php sämtliche bisherigen Einstellungen für die SQL-Modi entfernt. Es sei denn, beim Funktionsaufruf werden Hinweise übermittelt werden, welche SQL-Modi eingestellt werden sollen. Das Entfernen der Vorgaben für die SQL-Modi führt unter anderem dazu, dass dann der SQL-Modus NO_BACKSLASH_ESCAPES nicht aktiviert ist. Das bedeutet, dass der Backslash innerhalb von Strings in MySQL-Befehlen als Maskierungszeichen eingesetzt werden kann, aber auch, dass die in der Tabelle aufgelisteten Kombinationen des Backslashs mit anderen Zeichen von MySQL dahingehend interpretiert werden, dass die Zeichen entsprechend zu ersetzen sind.

Hinweise zu anderen Datentypen

Ein Wert, der in einer Spalte eingetragen werden soll, die einen Zahlentyp besitzt, oder mit einem Wert aus dieser Spalte verglichen werden soll, kann im SQL-Befehl als String notiert werden, also mit Apostrophs bzw. mit Anführungszeichen "gekapselt" werden.
Zu beachten ist dabei allerdings, dass MySQL den gekapselte Wert beim u.U. durch den Zahlenwert 0 ersetzt, wenn die gekapselte Zeichenfolge keine zulässige Zeichenfolge für eine Zahl ist.
Die "Kapselung" ist allerdings nicht möglich, wenn im MySQL-Befehl mit diesen Werten eine Rechenoperation durchgeführt werden soll oder der Zahlenwert z.B. als Mengenbegrenzer im Befehlsteil LIMIT eingesetzt werden soll.
Aus den beiden Aussagen zuvor ergibt sich, dass ein Wert, der in einem MySQL-Befehl in einem Zahlenkontext verwendet werden soll, daraufhin zu untersuchen ist, ob dieser Wert tatsächlich eine Zahl ist, bevor der Wert an den MySQL-Befehl übergeben wird. Wenn auf diese Weise sichergestellt ist, dass der Wert eine Zahl ist, braucht er nicht innerhalb des SQL-Befehls "gekapselt" zu werden, um SQL-Injektion zu vermeiden.

Für die Werte der verschiedenen Datums- und Zeit-Typen sind in MySQL-Befehlen sowohl Zahlen als auch Strings zulässig. Wenn bei der Wertzuweisung im Befehl zwischen den Teilen der Wertangaben (z.B. für Jahr, Monat, Tag, Stunde, Minute, Sekunde, Microsekunde) die jeweils erlaubten Trennzeichen notiert werden, ist nur eine Übergabe in Form eines Strings möglich. Der Wert muss daher entweder mit Apostrophs oder doppelten Anführungszeichen gekapselt werden, damit er nicht zum Wert NULL umgewandelt wird. Auch wenn die Zeichenfolge oder die Ziffernkombination kein zulässiger Wert für die Spalte ist, wandelt MySQL diesen Wert in einen NULL-Wert um. Durch Server-Mode-Einstellungen kann aber erreicht werden, dass MySQL auch Datumsangaben, die nur partiell ungültig sind (also solche mit Nullwerten für Tag und Monat) akzeptiert.
Möchte man verhindern, dass eine Zeichenfolge, die im MySQL-Befehl in einem Datums- oder Zeit-Kontext stehen soll, in den NULL-Wert umgesetzt wird, sollte in PHP geprüft werden, ob diese Zeichenfolge eine zulässige Datums- oder Zeitangabe ist und ggf. den Wert korrigieren, bevor er an MySQL weitergegeben wird.

Wertangaben können in MySQL auch in Form von Hexadezimalwerten zugewiesen werden. Wenn diese Wertzuweisungen im MySQL-Befehl als Strings übergeben werden, also innerhalb von Apostrophs oder Anführungszeichen stehen, notiert MySQL in Spalten, in denen Strings notiert werden können, die Zeichenfolge genauso, wie sie im Befehl stand und nicht in eine andere Zeichenfolge umgewandelt. In Spalten, in welchen Zahlen erfasst werden, kann der Wert dagegen bei der Übergabe als String nicht eingetragen werden. Falls der MySQL-Server fehlertolerant ist, wird er statt des Hexadezimalwertes den NULL-Wert in der Zahlenspalte eintragen.
Sofern der Hexadezimalwert nicht gekapselt übergeben wird, entscheidet MySQL anhand des Kontext, ob der Hexadezimalwert in eine Zahl oder in einen String umgewandelt werden muss.
Bei der Übergabe der Zeichenfolge, die MySQL als Hexadezimalwert interpretieren soll, darf der Wert also nicht "gekapselt" werden. Daher muss in diesem Fall zuvor von PHP geprüft werden, ob die Zeichenfolge tatsächlich ein gültiger Hexadezimalwert ist, bevor dieser Wert von PHP an einen MySQL-Befehl übergeben wird.

Als Werte können in MySQL auch die reservierten Wörter TRUE, FALSE und NULL übergeben werden. Wenn diese Werte in Apostrophs oder doppelten Anführungszeichen gekapselt übergeben werden, betrachtet MySQL diese Wörter als Strings ohne jede Bedeutung und trägt die Zeichenfolgen, so wie sie sind in Spalten ein, in denen Strings notiert werden können. In Zahlenspalten und ähnlichen Spalten kann der String nicht eingetragen werden. Für diese Spalten wird der Wert ggf. in den Wert NULL umgewandelt. Werden die reservierten Wörter nicht als Strings übergeben, verwendet MySQL die Werte, die diesen Konstanten zugeordnet sind. Dabei darf für diese reservierten Wörter jede beliebige Groß- und Kleinschreibung verwendet werden. TRUE entspricht dem Zahlenwert 1, FALSE dem Zahlenwert 0 und das Wort NULL im Stringkontext oder im BINÄR-Kontext der leeren Zeichenkette und ansonsten einer äquivalenten Darstellung für den NULL-Wert (oftmals der Zahlenwert 0 oder eine formatierte Zeichenfolge, die nur aus der Ziffer 0 und den Formatierungszeichen besteht z.B. 0000-00-00).

Werte können in MySQL auch in der b'value' oder 0bvalue Notation zugewiesen werden. Werden diese Werte ungekapselt zugewiesen, so werden diese Bitfolgen im Zahlenkontext als eine Zahl in Digitaldarstellung interpretiert und in eine Zahl umgewandelt, im String-Kontext entspricht diese Bitfolge einer leeren Zeichenkette. In Spalten, in denen Binär-Daten gespeichert werden können, wird die Bitfolge als fortlaufende Bytefolge gespeichert. Wird die Bitfolge gekapselt übergeben, wird sie nicht umgewandelt, sondern als ein String, also als eine Zeichenfolge betrachtet, die bytemäßig 1:1 in jenen Spalten notiert werden kann, in denen Zeichenfolgen gespeichert werden können (z.B. CHAR, VARCHAR, TEXT und BLOB). In einem anderem Typkonext führt die String-Darstellung des Wertes zum NULL-Wert.
Möchte man erreichen, dass MySQL eine Zeichenfolge als b'value oder 0bvalue interpretiert, darf die Zeichenfolge bei der Wertzuweisung im MySQL-Befehl also nicht "gekapselt" werden. Das bedeutet andererseits, dass die Zeichenfolge zuvor daraufhin getestet werden muss, ob sie ein b'value oder 0bvalue ist, bevor die Zeichenfolge ungekapselt im MySQL-Befehl eingefügt wird, um Fehler und SQL-Injektion zu vermeiden.

zum Anfang

Zeicheninterpretation durch Browser

Das Zeichen < ist in HTML das Startzeichen sowohl für ein HTML-Start-Tag als auch für ein HTML-Ende-Tag und das Zeichen > beendet HTML-Tags. Mit HTML-Start- und HTML-Ende-Tags werden dem Browser mitgeteilt, welche Textbestandteile zu einem Element gehören. An die HTML-Tags sind vielfach Formatierungsanweisungen und teilweise Funktionen gekoppelt.

Innerhalb von HTML-Start-Tags können ergänzende Hinweise in Form von Attributen und Attributwerten notiert werden, wodurch dem HTML-Element spezifische Eigenschaften zugewiesen werden können. Fast alle HTML-Attribute haben folgende grammatikalische Struktur: Attributname="Attributwert". Statt der Anführungszeichen kann der Attributwert auch durch Apostrophs begrenzt werden. Bei den Ausnahmen von der Struktur-Regel für Attribute braucht dem Attribut kein Attributwert zugewiesen werden. Bei diesen reicht allein die Erwähnung des Attributnamens im Start-Tag schon aus, damit der Browser weiß, welche Eigenschaft das HTML-Element besitzen soll (trifft z.B. auf die Attribute hidden, readonly, checked und selected zu.). Soll der HTML-Code allerdings XML-konform sein oder wird er mit Javascript erstellt, muss man bei diesen Attributen als Attributwert den jeweiligen Attributnamen zuweisen (z.B. checked="checked").

Übergibt man eine Zeichenkette "ZK" an einen Browser, so können je nach Ausgabekontext für "ZK" durch die Zeichen < " und ' unerwünschte Wirkungen erzielt werden. Die Auswirkungen sind allerdings unterschiedlich, wenn die Zeichenkette "ZK" direkt in die Ausgabe geschrieben wird, oder wenn an den Browser die Zeichenkette "ZK" als Wert einer Javascript-Variablen übergeben wird, damit Javascript den Wert in die Ausgabe einfügt.

In den nachfolgenden Aussagen findet sich teilweise eine Beschränkung der Aussgabe auf die aktuelle Firefox-Version (65), weil die Tests mit diesem Browser durchgeführt wurden. Es wird aber davon ausgegangen, dass sich mindestens die aktuellen Versionen anderer Browser ebenfalls so verhalten.

Direkte Ausgabe von "ZK" an den Browser

In diesem Fall kann man die kritischen Zeichen durch Ersetzung durch die zugehörigen HTML-Entities "entschärfen", eine Maskierung durch einen vorangestellten Backslash wie in PHP oder MySQL ist nicht möglich. Bei der spitzen öffnenden Klammer (<) würde es auch ausreichen, wenn ihr direkt ein Leerzeichen folgen würde, weil die spitze Klammer vom Browser dann nicht als Start-Zeichen für ein HTML-Tag interpretiert wird. Allerdings würde dann in der Anzeige hinter der spitzen öffneden Klammer immer ein Leerzeichen zu sehen sein.

Steht in der Zeichenfolge "ZK" ein HTML-Tag, so kann dadurch je nach HTML-Tag die Ausgabe unterschiedlich stark optisch verändert werden, weil der Browser immer versucht, den folgenden Text als das entsprechende Element darzustellen. Dabei unterscheidet der Browser auch danach, ob die Zeichenkette "ZK" innerhalb des Dokumenten-Teils "<head>" ("Kopf des Dokuments") oder "<body>" ("Körper des Dokuments") steht.
Besonders auffällig ist die Wirkungsweise der Zeichenfolge <textarea> im Dokumentteil "<body>. Entdeckt z.B. der Browser Firefox dort die Zeichenfolge <textarea>, so interpretiert Firefox dies meist als den Beginn eines Texteingabefeldes und stellt allen darauf folgenden Text in einem Texteingabefeld dar, bis es auf die Zeichenfolge </textarea> stößt. Im Quelltext werden die HTML-Tags übrigens angezeigt. Würde das HTML-Ende-Tag </textarea> fehlen, stünde der gesamte Dateiinhalt, der auf das Start-Tag folgt, in dem Texteingabefeld. Wenn im Start-Tag die schließende spitze Klammer fehlt, würde der Browser sämtlichen Dateiinhalt bis zum ersten Auftreten des Zeichens > zum Inhalt des Start-Tags zählen, unabhängig davon, in welchem Kontext das Zeichen > steht. Wäre das Zeichen > Bestandteil eines vollständig und korrekt formulierten HTML-Tags, würde dieses unwirksam, wodurch weitere Ausgabefehler möglich wären.
Falls das Zeichen < in "ZK" vom Browser nicht als Start-Zeichen für HTML-Tags interpretiert werden soll, kann statt der spitzen öffnenden Klammer innerhalb vom "ZK" die zugehörige HTML-Entity notiert werden (< = &lt;), bevor die Zeichenkette "ZK" an den Browser übergeben wird. In der Ausgabe sieht der Betrachter dann die spitzen Klammern und im Quelltext stehen die HTML-Entities. Die schließenden spitzen Klammern können innerhalb von "ZK" ebenfalls durch die zugehörige HTML-Entity ersetzt werden (< = &lt;), müssen es aber im aktuellen Browser Firefox nicht.
Die Ersetzung der spitzen Klammern ist auch für jene Zeichenfolgen möglich, welche in Formularfeldern vom Typ input und Typ textarea als sichtbarer Inhalt ausgegeben werden sollen. Wird das Formular abgesendet, wird statt einer HTML-Entity vom aktuellen Browser Firefox die zugehörige spitze Klammer an den Empfänger gesendet. Soll "ZK" in einem Texteingabefeld (input) als Wert ausgegeben werden, ist die Umwandlung in HTML-Entities nicht nötig, weil "ZK" als Wert des Attributs value durch Apostrophs oder doppelte Ausführungszeichen begrenzt wird und damit seine Bedeutung Start-/Ende-Zeichen für ein HTML-Tag für den Browser verliert. In Texteingabebereichen (textarea) gibt es diese Kennzeichnung von "ZK" nicht, so dass hier die Umwandlung in HTML-Entities teilweise erforderlich ist, damit die Dokumentstruktur durch die spitzen Klammern nicht gestört wird.

Apostrophs und doppelte Anführungszeichen innerhalb von "ZK" wirken sich nur dann aus, wenn ZK einem Attribut als Wert zugeordnet ist.
Angenommen der Nachname einer Person lautet O'Connor und soll als Wert für das Attribut "value" eines Input-Feldes ausgegeben werden. Wenn der Attributwert in diesem Fall mit doppelten Anführungszeichen umgeben ist (also value="O'Connor"), akzeptiert der Browser den gesamten Namen als Wert für das Attribut value. Würde die Ausgabe value='O'Connor' lauten, soll also der Attributwert durch Apostrophs begrenzt werden, so würde der Browser nur den Buchstaben O als Attributwert werten und im Eingabefeld anzeigen, weil danach ein Apostroph folgt. Den Rest der Zeichenfolge bis zur schließenden spitzen Klammer versucht der Browser dann, als weitere Attribute und ihre Werte zu interpretieren. Falls allerdings die restliche Zeichenfolge von der grammatikalischen Struktur für Attribute und Attributwerte abweicht, führt das zu einem Fehler, der in der Quelltext-Ansicht im Browser Firefox durch die rote Farbe für das HTML-Element angezeigt wird. Inwieweit sich dieser grammatikalische Fehler auf die sichtbare Anzeige und die Funktionsfähigkeit des HTML-Dokuments auswirkt, hängt vom Kontext ab.
Würde statt des Nachnamens O'Connor die Zeichenfolge bitte klicken" onfocus="tuwas();" class=" als Wert des Attributs value notiert, so würde diese Zeichenfolge bei der Begrenzung mit Apostrophs (value='ZK') keine Wirkung haben, wohingegen sie bei der Begrenzung mit Ausführungszeichen (value="ZK") in drei grammatikalisch korrekte Attribute mit gültigen Werten gegliedert würde value="bitte klicken" onfocus="tuwas();" class="".
Wenn die Begrenzer für den Attributwert das doppelte Anführungszeichen sind, reicht es aus, sämtliche in "ZK" vorhandenen doppelten Anführungszeichen durch die zugehörige HTML-Entity (&quot;) zu ersezten, damit der Browser die doppelten Anführungszeichen und Apostrophs, die in "ZK" enthalten sind, nicht als Begrenzer von Attributwerten interpretiert. Wird das Apostoph als Begrenzer für die Attributwerte eingesetzt, reicht analog die Ersetzung aller Apostrophs innerhalb von "ZK" durch die zugehörige HTML-Entity (') aus.

Übergabe als Wert einer Javascript-Variablen

Wenn bei der Wertzuweisung für eine Variable "V" in Javascript nach dem Gleichheitszeichen ein doppeltes Anführungszeichen " folgt, weist Javascript der Variablen "V" den Datentyp "String" zu. Der Variablenwert "W" endet für Javascript, sobald er in der folgenden Zeichenfolge erneut auf ein nicht maskiertes doppeltes Anführungszeichen stößt. Findet Javascript in dieser Zeile kein doppeltes Anführungszeichen, welches es als Begrenzer für den String verwenden kann, ist dieses für Javascript ein gravierender Fehler und der Javascript-Code kann nicht ausgeführt werden.
Analog verhält sich Javascript bzgl. des Apostrophs '.
Steht nach dem Gleichheitszeichen das Akzentzeichen ` endet für Javascript der Variablenwert erst dann, wenn er auf das nächste ` stößt, welches nicht maskiert ist. In diesem Fall dürfen im Quelltext auch ein oder mehrere Zeilenumbrüche innerhalb des Variablenwertes stehen.

Befindet sich innerhalb von "W" das Zeichen, welches als Begrenzer für den Variablenwert eingesetzt wird, müssen alle Vorkommen dieses Begrenzer-Zeichens innerhalb von "W" maskiert werden, weil ansonsten das Auftreten des Zeichens von Javascript als Ende des Variablenwertes interpretiert wird. Ein Zeichen ist dann in Javascript maskiert, wenn unmittelbar vor diesem Zeichen ein einzelner Backslash oder eine ungerade Anzahl von Backslashes steht. Es wird von Javascript dann als ein Zeichen ohne Funktionsbedeutung interpretiert.

Sobald Javascript beim Lesen des Variablenwertes "W" auf einen Backslash trifft, interpretiert Javascript diesen Backslash als Maskierungszeichen und gibt das folgende Zeichen an den Browser weiter, ohne darauf zu achten, was für ein Zeichen es ist. Das Zeichen wird von Javascript also nicht interpretiert. Anschließend liest Javascript das nächste Zeichen. Ist dieses wiederum ein Backslash, verhält es sich genauso wie zuvor und gibt das nächste Zeichen ebenfalls an den Browser weiter, ohne es zu interpretieren. Wenn also eine gerade Anzahl von Backslashes vor einem Anführungszeichen, einem Apostroph oder einem Akzentzeichen stehen, gibt es am Ende dieser Folge keinen Backslash mehr, welches das Anführungszeichen, das Apostroph oder das Akzentzeichen maskieren könnte. Damit also ein vorhandener Backslash vor dem Begrenzer des Variablenwertes (Ausführungszeichen, Apostroph oder Akzentzeichen) die beabsichtigte Maskierung durch einen zu Maskierungszwecken eingeschobenen Backslash aufhebt, müssen vor dem Maskieren des Zeichens, welches als Begrenzer verwendet wird, sämtliche vorhandenen Backslashes ebenfalls durch einen Backslash maskiert werden. Dies führt dann allerdings dazu, dass sämtliche zuvor vorhandenen Backslashes nun ebenfalls für Javascript maskiert sind und von Javascript an den Browser weitergeben werden.

Wenn "ZK" als Wert einer Javascript-Variablen an den Browser übermittelt wird, die per Javascript-Befehl im HTML-Dokument ausgegeben werden soll, ist es nicht sinnvoll, in "ZK" die Zeichen (< " ') durch die HTML-Entities in "ZK" zu ersetzen. Denn nach dem Einfügen des Variablenwertes mit einem Javascript-Befehl in das HTML-Dokument würde der Browser immer die Zeichenfolgen der HTML-Entities angezeigt, egal ob die Ausgabe als "einfacher" Text oder in einem Formularfeld erfolgt. Und beim Senden des Formulars würden die Zeichenfolgen der HTML-Entities übermittelt und nicht die den Entities zugeordneten "Klar-"Zeichen.

zum Anfang