MySQL: Zeilenumbrüche in MySQL

In einigen Programmiersprachen wie PHP oder Java können wir die Zeichen beziehungsweise die Escape-Sequenzen \r und \n für einen Zeilenumbruch verwenden. In JavaScript steht dagegen bereits die Escape-Sequenz \n alleine für einen vollständigen Zeilenumbruch, andere Programmiersprachen nutzen Zeichencodes oder stellen entsprechende Funktionen oder Konstanten für das Einfügen eines Zeilenumbruchs zur Verfügung.

Wie aber verhält es sich damit in MySQL? Wie können wir mit der Hilfe von SQL-Befehlen explizit mit Zeilenumbrüchen arbeiten, zum Beispiel um gezielt nach Texten mit einem Zeilenumbruch in einer Datenbank zu suchen, Texte über mehrere Zeilen zu ersetzen, Texte mit Zeilenumbrüchen in eine Tabelle zu schreiben oder um Zeilenumbrüche durch ein anderes Zeichen zu ersetzen oder zu löschen?

In diesem Artikel möchten wir diese Frage in den nächsten Abschnitten beantworten:

• Grundlagen: Escape-Sequenzen und die CHAR()-Funktion
• Windows-Zeilenumbrüche
• Unix-Zeilenumbrüche (Linux und macOS)
• Zeilenumbrüche innerhalb eines Strings
• Nutzung der CONCAT()-Funktion
• Alternative Schreibweise der Zeichencodes
• Einschränkungen der CHAR()-Funktion
• Unicode-Zeilenumbrüche (NEL, LS, PS, VT und FF)
• Zeilenumbrüche in PHP und phpMyAdmin

Grundlagen: Escape-Sequenzen und die CHAR()-Funktion

Grundsätzlich bietet uns MySQL gleich zwei Möglichkeiten, um Zeilenumbrüche zu spezifizieren: Einerseits können wir die aus PHP bekannten Escape-Sequenzen \r und \n verwenden, andererseits stellt uns MySQL die Funktion CHAR() zur Verfügung, die unter anderem einen oder auch mehrere ASCII-Codes entgegennehmen kann, um uns dann die entsprechenden Zeichen zurückzugeben. Der Code beziehungsweise Codepoint aus dem ASCII-Range für einen Line Feed lautet 10 (LF), der für einen Carriage Return 13 (CR). Die entsprechenden Escape-Sequenzen sind \r für CR sowie \n für LF.

Windows-Zeilenumbrüche

Demnach können wir zum Beispiel die folgende MySQL-Query für Windows-Zeilenumbrüche (CR LF) formulieren:

UPDATE tabelle SET spalte = REPLACE(spalte, CHAR(13, 10), '');

Damit ersetzen wir alle Zeilenumbrüche der Art CR LF mit nichts - das heißt wir löschen sämtliche Zeilenumbrüche aus dem Text der Spalte "spalte" aus der Tabelle "tabelle" vollständig.

Statt die CHAR()-Funktion zu verwenden, können wir alternativ auch mit den Escape-Sequenzen arbeiten und statt CHAR(13, 10) den String '\r\n' in unsere Query einbauen, was das selbe bedeutet und entsprechend zum gleichen Ergebnis führt:

UPDATE tabelle SET spalte = REPLACE(spalte, '\r\n', '');

An dieser Stelle spielt es übrigens keine Rolle, ob wir einfache oder doppelte Anführungszeichen verwenden. Zwar macht PHP einen Unterschied zwischen '\r\n' und "\r\n" und ersetzt nur die zweite in doppelten Anführungszeichen gefasste Variante durch echte Zeilenumbrüche während die erste Variante als solche stehen bleibt, MySQL jedoch unterscheidet nicht zwischen der Art der Anführungszeichen und ersetzt entsprechend beide Varianten durch echte Zeilenumbrüche (mehr zu diesem Thema im letzten Abschnitt über Zeilenumbrüche in MySQL und PHP).

Unix-Zeilenumbrüche (Linux und macOS)

Analog lassen sich natürlich auch andere Typen von Zeilenumbrüchen verarbeiten, indem wir statt 13 und 10 beziehungsweise \r und \n die entsprechenden anderen Zeichencodes beziehungsweise Escape-Sequenzen verwenden. Also zum Beispiel Zeilenumbrüche vom Typ Unix, die zum Beispiel auf Linux- oder macOS-Systemen gebräuchlich sind und nur aus dem einem Zeichen LF mit dem dezimalen Code 10 bestehen:

UPDATE tabelle SET spalte = REPLACE(spalte, CHAR(10), ' ');

Mit dieser UPDATE-Query ersetzen wir alle Vorkommnisse dieses Zeilenumbruchtyps in der Spalte "spalte" der Tabelle "tabelle" durch ein Leerzeichen.

Wieder können wir alternativ auch mit Escape-Sequenzen arbeiten und entsprechend das Escape-Zeichen für den Unix-Zeilenumbruch \n für LF benutzen:

UPDATE tabelle SET spalte = REPLACE(spalte, '\n', ' ');

Das Ergebnis beider dieser Queries ist identisch.

Zeilenumbrüche innerhalb eines Strings

Bisher haben wir die Zeilenumbrüche immer nur alleine und nicht in Verbindung mit anderen Zeichen innerhalb von längeren Strings verwendet. Im nächsten Beispiel möchten wir uns daher ansehen, wie wir nach einem Text bestehend aus mehreren Zeichen inklusive einem Zeilenumbruch zum Beispiel in einer Spalte des Typs VARCHAR oder TEXT mit MySQL suchen können.

Am einfachsten können wir dies mit Hilfe der Escape-Sequenzen bewerkstelligen:

SELECT id FROM tabelle WHERE spalte = 'Zeile 1\r\nZeile 2';

Diese Anfrage sucht für uns alle Einträge aus der Tabelle "tabelle", die den zweizeiligen Text mit der ersten Zeile "Zeile 1" sowie der zweiten Zeile "Zeile 2" in der Spalte "spalte" enthält. Für das Beispiel haben wir einen Windows-Zeilenumbruch verwendet. Für einen Unix-Zeilenumbruch müssten wir entsprechend das "\r" weglassen und stattdessen nur "Zeile 1\nZeile 2" schreiben.

Natürlich können wir alternativ auch um diese Anfrage umzusetzen wieder mit der CHAR()-Funktion arbeiten. Allerdings müssen wir uns in diesem Fall darüber Gedanken machen, wie wir das Ergebnis der CHAR()-Funktion mit unseren sonstigen String-Teilen verbinden können, denn diesbezüglich gibt es einige Unterschiede zwischen den verschiedenen Datenbankmanagementsystemen und Konfigurationen.

In vielen Datenbankmanagementsystem wie SQLite, Firebird, PostgreSQL oder Oracle kann das Pipe-Symbol (das in MySQL als ODER genutzt wird) in der folgenden Weise zur String-Verbindung verwendet werden:

SELECT id FROM tabelle WHERE spalte = 'Zeile 1' || CHAR(13) || CHAR(10) || 'Zeile 2';

Microsoft SQL Server supportet dagegen stattdessen das Plus-Zeichen um mehrere Strings zu verbinden:

SELECT id FROM tabelle WHERE spalte = 'Zeile 1' + CHAR(13) + CHAR(10) + 'Zeile 2';

In MySQL und ebenso auch in der oft als Alternative genutzten MariaDB funktioniert jedoch in der Grundeinstellung keine der beiden Varianten. Standardmäßig unterstützen sowohl MySQL als auch MariaDB weder + noch || als Operator für String-Konkatinationen und würden für das letzte Beispiel den Zahlenwert 0 zurück geben, weil das Plus als Rechenoperator angesehen wird (der ||-Operator lässt sich jedoch mit dem per Default deaktivierten SQL-Modus PIPES_AS_CONCAT auch in MySQL und MariaDB zum Beispiel über die Anweisung "SET sql_mode = (SELECT CONCAT(@@sql_mode, ',PIPES_AS_CONCAT'));" aktivieren).

Ohne die Grundeinstellungen zu ändern nutzen MySQL und MariaDB für String-Verbindungen die CONCAT()-Funktion, die wir uns im nächsten Abschnitt ansehen werden. Neben MySQL und MariaDB supporten auch Microsoft SQL Server, Oracle und PostgreSQL diese Funktion zum Verbinden von Strings.

Nutzung der CONCAT()-Funktion

Alternativ zur Nutzung der Zusammensetzung unseres Strings über das doppelte Pipe-Zeichen || oder das Plus-Zeichen +, wie wir es in den Beispielen aus dem letzten Abschnitt gesehen haben, können wir für den gleichen Zweck in MySQL, MariaDB, Microsoft SQL Server, Oracle und PostgreSQL auch die CONCAT()-Funktion nutzen, der wir eine beliebige Anzahl von Parametern in Form von Einzelstrings übergeben können. Diese einzelnen Strings können unter anderem sowohl aus in Anführungszeichen gesetzten Text als auch aus einzelnen durch CHAR() erzeugten Zeichen bestehen.

Das Beispiel aus dem letzten Abschnitt können wir entsprechend auf die folgende Weise mit CONCAT() umsetzen:

SELECT id FROM tabelle WHERE spalte = CONCAT('Zeile 1', CHAR(13), CHAR(10), 'Zeile 2');

Wie wir sehen, können wir die Einzelteile einfach mit einem Komma voneinander trennen, was natürlich auch für unsere Escape-Sequenzen gilt, wie unser nächstes Beispiel zeigt:

SELECT id FROM tabelle WHERE spalte = CONCAT('Zeile 1', '\r', '\n', 'Zeile 2');

Im Gegensatz zu PHP ist es auch hier abermals unerheblich ob wir unsere Escape-Sequenzen in einfache oder in doppelte Anführungszeichen setzen. SQL akzeptiert beide Varianten während in PHP nur doppelte Anführungszeichen funktionieren, worauf wir noch im letzten Abschnitt detailliert eingehen werden.

Alternative Schreibweise der Zeichencodes

In allen bisherigen Beispielen haben wir die CHAR()-Funktion immer mit dezimalen Zeichencodes unserer Zeilenumbruchzeichen genutzt. Also 13 für CR (Carriage Return) sowie 10 für LF (Line Feed). MySQL erlaubt es uns jedoch auch, diese Codepoints in hexadezimaler Schreibweise anzugeben. Die hexadezimale Schreibweise für 13 ist 0D während für 10 die hexadezimale Schreibweise 0A lautet. Um MySQL zu signalisieren, dass es sich bei unserer Angabe um eine hexadezimale Zahl handelt, müssen wir zusätzlich 0x voranstellen. Schauen wir uns auch dazu ein Beispiel an:

UPDATE tabelle SET spalte = CONCAT('a', CHAR(0x0D), CHAR(0x0A), 'b');

Mit diesem SQL-Befehl setzen wir den Inhalt der Spalte "spalte" auf einen zweizeiligen Text, der aus den Zeilen "a" und "b" besteht. Für den Windows-Zeilenumbruch zwischen den beiden Zeilen nutzen wir statt CHAR(13) und CHAR(10) die hexadezimale Schreibweise CHAR(0x0D) sowie CHAR(0x0A).

Die Spezifikation des Windows-Zeilenumbruchs lässt sich weiter vereinfachen, indem wir die einzelnen Zeichen 0D und 0A auf die folgende Weise zu 0x0D0A zusammenziehen und damit nur noch einmal die CHAR()-Funktion aufrufen müssen:

UPDATE tabelle SET spalte = CONCAT('a', CHAR(0x0D0A), 'b');

Bei der Verwendung der hexadezimalen Schreibweise können wir das CHAR() sogar ganz weglassen, wie das nächste Beispiel zeigt:

UPDATE tabelle SET spalte = CONCAT('a', 0x0D0A, 'b');

Und je nach Datenbank-System (SQLite/Oracle/PostgreSQL/Firebird) oder auch im PIPES_AS_CONCAT-Modus von MySQL und MariaDB geht es auch ganz ohne CONCAT():

UPDATE tabelle SET spalte = 'a' || 0x0D0A || 'b';

Jeder dieser vier verschiedenen Beispielaufrufe liefert uns exakt das gleiche Ergebnis.

Bei Verwendung der dezimalen Schreibweise wären die hier gezeigten Notationen nicht möglich. Einmal abgesehen davon, dass wir nicht "1310" schreiben können, da im Gegensatz zur hexadezimalen Notation für die dezimale Zahl "1310" unklar wäre, dass sich diese Angabe auf zwei Einzelzahlen bezieht, könnte ein Aufruf von 'a' + 10 + 13 + 'b' zu einer Interpretation der beiden Zahlen als String oder Zahlenkolonne führen und das Ergebnis wäre (je nach Datenbankmanagementsystem) statt einem Zeilenumbruch der Text "a1013b" oder ein Zahlenwert.

Einschränkungen der CHAR()-Funktion

Wichtig: Wir können die hier genutzte CHAR()-Funktion nicht einfach mit beliebigen Codepoints aufrufen um beliebige Codepoints in ihre Zeichenäquivalente zu verwandeln, sondern müssen die verwendete Kodierung und die Möglichkeit von resultierenden Multi-Byte-Zeichen im Hinterkopf behalten.

Relativ unproblematisch ist die Nutzung von Codepoints aus dem ASCII-Range mit den Integer-Zahlen von 0 bis 127, in dem auch unsere Codes für den Windows-Zeilenumbruch (13 und 10) sowie für den Unix-Zeilenumbruch (10) liegen. So lässt sich beispielsweise mit CHAR(65) der Buchstabe "A" (Codepoint U+0041, dezimal 65) erzeugen:

SELECT CHAR(65);                 -- A

Schwieriger wird es jedoch mit Zeichen, die in unserer verwendeten Kodierung durch mehrere Bytes repräsentiert sind. Verwendet unsere Datenbank beispielsweise die Standard-Collation UTF-8, können wir nicht einfach CHAR(196) schreiben, um den Buchstaben "Ä" zu erzeugen. Der Buchstabe "Ä" hat zwar den Unicode-Codepoint U+00C4 was der dezimalen Zahl 196 entspricht, jedoch produziert uns CHAR() eine Bytefolge, die in der UTF-8 Kodierung C3 84 statt C4 für "Ä" ist. Aus diesem Grund müssen wir für den Buchstaben "Ä" unter Verwendung einer UTF-8-Standard-Collation unserer Datenbank genau diese Bytefolge übergeben (entweder direkt hexadezimal über 0xC384 oder in dezimaler Schreibweise 50052):

SELECT CHAR(196);                -- 0xc4
SELECT CHAR(50052);              -- Ä
SELECT CHAR(0xC384);             -- Ä

Möchten wir Zeichen durch von der Standard-Collation unserer Datenbank abweichenden Codepoints oder Bytesequenzen erzeugen, können wir den von uns bevorzugten Zeichensatz aber auch über den USING-Zusatz definieren:

SELECT CHAR(196 USING LATIN1);   -- Ä
SELECT CHAR(0xC384 USING UTF8);  -- Ä
SELECT CHAR(0x00C4 USING UTF16); -- Ä
SELECT CHAR(0xD0A8 USING UTF8);  -- Ш

Wie die erste Zeile zeigt, wird es damit möglich, den Buchstaben "Ä" auch über die Dezimalzahl 196 unter Verwendung des Zeichensatzes Latin-1 zu erzeugen, da der Buchstabe "Ä" in Latin-1 nur über das eine Byte C4 (196) kodiert ist. Analog können wir abermals die Bytefolge C3 84 für "Ä" in der UTF-8 Kodierung sowie die Bytefolge 00 C4 für "Ä" in der UTF-16 Kodierung sowie beliebige andere Bytefolgen übergeben, um die entsprechenden Zeichen zu erzeugen.

Wichtig ist diese Grundlage für die Erzeugung von Zeilenumbrüchen, deren Codepoints sich außerhalb des ASCII-Ranges befinden, wie beispielsweise die Unicode-Zeilenumbruchtypen, die wir uns unter Verwendung derselben Vorgehensweise im nächsten Abschnitt ansehen möchten.

Unicode-Zeilenumbrüche (NEL, LS, PS, VT und FF)

Der Unicode-Standard verlangt, dass auch die Zeichen NEL (Next Line, Nächste Zeile, U+0085), LS (Line Separator, Zeilentrenner, U+2028), PS (Paragraph Separator, Absatztrenner, U+2029), VT (Vertical Tab, Vertikaler Tab, U+000B) sowie FF (Form Feed, Seitenvorschub, U+000C) als Zeilenumbrüche zu interpretieren sind. Aus diesem Grund möchten wir uns auch für diese Zeilenumbruchtypen ansehen, wie wir sie in unseren MySQL-Statements verwenden können. Wie bereits im letzten Abschnitt erklärt wurde, können wir dazu wieder die CHAR()-Funktion nutzen.

Die folgende Tabelle zeigt für alle Zeichen, mit welchen UTF-8 und UTF-16-Bytefolgen wir CHAR() aufrufen können, um das betreffende Zeichen zu erzeugen:

Zeichen		Codepoint	UTF-8	UTF-16
VT	Vertical Tab	U+000B	CHAR(0x0B USING UTF8)	CHAR(0x000B USING UTF16)
FF	Form Feed	U+000C	CHAR(0x0C USING UTF8)	CHAR(0x000C USING UTF16)
NEL	Next Line	U+0085	CHAR(0xC285 USING UTF8)	CHAR(0x0085 USING UTF16)
LS	Line Separator	U+2028	CHAR(0xE280A8 USING UTF8)	CHAR(0x2028 USING UTF16)
PS	Paragraph Separator	U+2029	CHAR(0xE280A9 USING UTF8)	CHAR(0x2029 USING UTF16)

In der Praxis können wir diese Zeichen einfach, wie bereits für die anderen Zeilenumbrüche gezeigt wurde, in unseren SQL-Anweisungen nutzen. Zum Beispiel um alle Windows-Zeilenumbrüche (hier spezifiziert über Escape-Sequenzen) durch das NEL-Zeichen auszutauschen:

UPDATE tabelle SET spalte = REPLACE(spalte, '\r\n', CHAR(0xC285 USING UTF8));

Oder um alle Datensätze zu finden, die das Line Separator Zeichen LS enthalten:

SELECT * FROM tabelle WHERE spalte LIKE CONCAT('%', CHAR(0x2028 USING UTF16), '%');

Wie die Beispiele zeigen, können wir die mit CHAR() erzeugten Unicode-Zeilenumbruchszeichen wie gewohnt einzeln oder auch verbunden über die CONCAT()-Funktion verwenden. Die aus vielen anderen Programmiersprachen bekannten Escape-Sequenzen für Unicode-Codepoints wie beispielsweise \x2028, \u2028 oder \U{2028} für den Line Separator werden dagegen nicht von MySQL unterstützt.

Zeilenumbrüche in PHP und phpMyAdmin

Grundsätzlich können wir die hier gezeigten SQL-Befehle auch genauso in unserem PHP-Code oder in phpMyAdmin verwenden. Wir müssen jedoch beachten dass \r und \n nicht in allen Fällen in die Zeichen U+000A beziehungsweise U+000D umgewandelt werden sondern unter manchen Bedingungen auch als solche stehen bleiben können.

Entscheidend sind dabei einerseits der verwendete Anführungszeichtypus, andererseits die Verwendung der MySQL-typischen Escape-Funktionen mysqli_real_escape_string beziehungsweise mysqli::real_escape_string. Im folgenden möchten wir einige Beispiele analysieren, die das unterschiedliche Verhalten der verschiedenen Kombinationen aus Anführungszeichen und Escapen demonstrieren sollen.

Zuerst möchten wir uns dieses einfache Beispiel ansehen, mit dem wir den Inhalt einer Spalte auf den Text aus der Variablen $txt setzen möchten. $txt besteht dabei aus zwei Zeilen, die wir mit dem Windows-Zeilenumbruch \r\n voneinander getrennt haben.

$txt = "Zeile 1\r\nZeile 2";
$sql = "UPDATE tabelle SET spalte = '$txt' WHERE id = 1";

Den Text für die Variable $txt haben wir mit doppelten Anführungszeichen definiert. Dies ist an dieser Stelle entscheidend, da PHP einen Unterschied zwischen doppelten und einfachen Anführungszeichen macht. Escape-Sequenzen wie hier unser Zeilenumbruch \r\n werden nur in einen echten Zeilenumbruch aufgelöst sofern sie in doppelten Anführungszeichen stehen. Stehen sie dagegen in einfachen Anführungszeichen, bleiben die Zeichen als solche stehen.

Aus diesem Grund wandelt in diesem Beispiel bereits PHP \r\n in einen echten Zeilenumbruch um, bevor unser String überhaupt die Datenbank erreicht. Das Ergebnis ist ein Zeilenumbruch in der Datenbank und auch wenn wir $txt zum Beispiel mit echo oder über vardump() ausgeben, wird ein Zeilenumbruch im Quelltext unserer HTML-Seite erzeugt (nur im Quelltext, nicht in der Darstellung des Browsers da darin Zeilenumbrüche und anderer Whitespace ignoriert wird).

Nun möchten wir unser Beispiel nur um ein Detail abwandeln: Statt doppelten Anführungszeichen verwenden wir in unserem nächsten Beispiele einfache:

$txt = 'Zeile 1\r\nZeile 2';
$sql = "UPDATE tabelle SET spalte = '$txt' WHERE id = 1";  

Dies führt zum selben Ergebnis in der Datenbank jedoch zu einem anderen Ergebnis im Quelltext. Während dieser Code abermals in unserer Datenbank einen echten Zeilenumbruch erzeugt, bleibt der String \r\n bei einer Ausgabe von $txt im Quelltext stehen. Wie kann das sein? Die einfachen Anführungszeichen sorgen dafür, dass PHP keine Interpretation und Umwandlung der Escape-Sequenzen vornimmt. Das heißt, bis zuletzt bleiben \r und \n in der Variable $txt als solche stehen und die Ausgabe erfolgt entsprechend. Jedoch erfolgt dieses Mal eine Umwandlung nicht auf der Ebene von PHP sondern auf der Ebene von MySQL. MySQL wandelt \r\n erst nach Erhalt der Query in einen Zeilenumbruch um und schreibt diesen in die Datenbank.

Aus Sicherheitsgründen und um die Interferenz mit einigen Zeichen wie Anführungszeichen in einem Text zu unterbinden ist es erforderlich, Text zu escapen bevor wir ihn auf unsere Datenbank loslassen. Dies wird üblicherweise im prozeduralen Stil mit der Funktion mysqli_real_escape_string() gemacht beziehungsweise mit mysqli::real_escape_string wenn wir den objektorientierten Stil verwenden.

Schauen wir uns an, wie sich das Ergebnis unseres Codes ändert, wenn wir unseren String vor dem Einfügen in die Datenbank mit mysqli_real_escape_string() escapen:

$txt = "Zeile 1\r\nZeile 2";
$txt = mysqli_real_escape_string($db, $txt);
$sql = "UPDATE tabelle SET spalte = '$txt' WHERE id = 1";
$erg = mysqli_query($db, $sql);

Auch dieser Code führt sowohl in der Datenbank als auch im Quelltext zu einem echten Zeilenumbruch. Der Grund dafür ist, dass wir in der ersten Zeile beim Setzen der Variable $txt doppelte Anführungszeichen verwenden und unsere Zeichen \r und \n dadurch bereits vor dem Escapen in echte Zeilenumbrüche umgewandelt wurden, denen unsere Escapefunktion nichts mehr anhaben kann.

Anders verhält es sich jedoch falls wir den selben Code mit einfachen Anführungszeichen bei der Variablendefinition aufrufen:

$txt = 'Zeile 1\r\nZeile 2';
$txt = mysqli_real_escape_string($db, $txt);
$sql = "UPDATE tabelle SET spalte = '$txt' WHERE id = 1";
$erg = mysqli_query($db, $sql);

Dieses Mal werden \r und \n durch die einfachen Anführungszeichen nicht von PHP in einen Zeilenumbruch umgewandelt. Die Ausgabe im Quelltext behält entsprechend \r\n bei wie wir es bereits in unserem zweiten Beispiel gesehen haben. Jedoch erfolgt dieses Mal auch von MySQL keine Umwandlung so dass wir unseren Originalstring mit \r\n in die Datenbank geschrieben bekommen. Dafür sorgt in diesem Code die Escape-Funktion, die noch vor dem UPDATE-Befehl unser \r\n in \\r\\n umgewandelt (escaped) hat wodurch MySQL von einer Umwandlung in Zeilenumbrüche absieht und das zurück-escapte \r\n in die Datenbank schreibt.

Bis jetzt haben wir all unsere Queries mit doppelten Anführungszeichen notiert, wodurch PHP auch unsere Variable $txt in Form ihres Inhaltes in die Query eingefügt hat. Für MySQL sah eine solche Query damit nach der Einfügung von $txt so aus (hier mit den Zeilen a und b):

$sql = "UPDATE tabelle SET spalte = 'a\r\nb' WHERE id = 1";

Notieren wir die gesamte Query dagegen mit einfachen Anführungszeichen müssen wir die Anführungszeichen, die unseren Text einbinden selber escapen, damit es weiterhin funktioniert:

$sql = 'UPDATE tabelle SET spalte = \'a\r\nb\' WHERE id = 1';

Auch diese Query erzeugt in der Datenbank einen Zeilenumbruch, den man jedoch nicht bei einer Ausgabe im Quelltext sieht (darin würde 'a\r\nb' stehen). Das gleiche Ergebnis auf beiden Ebenen erhalten wir auch mit einem doppelten Escape:

$sql = 'UPDATE tabelle SET spalte = \'a\\r\\nb\' WHERE id = 1';

Erst mit einem dreifachen Escape, wie wir es in der nächsten Query sehen, erhalten wir in der Datenbank den Text 'a\r\nb' ohne echten Zeilenumbruch während im Quelltext der Text 'a\\r\\nb' (auch ohne Zeilenumbruch) ausgegeben wird:

$sql = 'UPDATE tabelle SET spalte = \'a\\\r\\\nb\' WHERE id = 1';

Neben diesen Spezialfällen sollte abschließend noch erwähnt werden, dass wir in unserem PHP-Code oder in der SQL-Eingabeaufforderung von phpMyAdmin auch Zeilenumbrüche als solche verwenden können:

$sql = "UPDATE tabelle SET spalte = 'Zeile 1
Zeile 2' WHERE id = 1";

Diese Query erzeugt unabhängig von einem Escape oder der CHAR()-Funktion sowohl im Quelltext als auch in der Datenbank einen Zeilenumbruch.