www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/2ef9cfde-89b0-4db0-a9d5-835f9b020979/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

TYPO3\CMS\Extbase\Persistence\Generic\Storage\Exception\SqlErrorException: An exception occurred while executing a query: Incorrect string value: '\x…

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers¶

1. Ursache identifizieren¶

Der Fehler mysqli_sql_exception: Incorrect string value: '\xC0\xA7\xC0\xA2%2...' for column 'title' at row 1 ist ein Zeichencodierungsfehler.

Konkrete Ursache:

• Die Bytes \xC0\xA7 und \xC0\xA2 sind keine gültigen UTF-8-Sequenzen. \xC0 ist eine überlange (overlong) UTF-8-Encoding-Sequenz, die von MySQL im strict mode abgelehnt wird.
• Das %2 im Fehlerstring deutet darauf hin, dass es sich um URL-kodierte Daten handelt, die nicht korrekt dekodiert/encodiert wurden.
• Der Prozess läuft vermutlich so ab: Ein Parameter (z.B. title) enthält URL-encodete Bytes wie %C0%A7%C0%A2 → Wird per urldecode() zu rohen Bytes \xC0\xA7\xC0\xA2 dekodiert → Diese Rohbytes werden als UTF-8 interpretiert und in die Datenbank geschrieben → MySQL lehnt ab, da es keine gültige UTF-8-Sequenz ist.
• Die Datenbankspalte title ist vermutlich als utf8mb4 konfiguriert, akzeptiert also nur gültige UTF-8-Sequenzen.

2. Fix (konkret)¶

Schritt 1 – Eingabedaten vor Verarbeitung validieren und konvertieren:

// Prüfen, ob der String gültiges UTF-8 ist
if (!mb_check_encoding($input, 'UTF-8')) {
    // Von der erkannten Quell-Encoding (z.B. Windows-1252/Latin-1) nach UTF-8 konvertieren
    $input = mb_convert_encoding($input, 'UTF-8', 'Windows-1252');
}

Schritt 2 – URL-Parameter korrekt dekodieren:

// Statt nur urldecode() sollte die gesamte Kette stimmen:
$value = rawurldecode($value); // statt urldecode()
// Dann explizit als UTF-8 interpretieren
if (!mb_check_encoding($value, 'UTF-8')) {
    $value = mb_convert_encoding($value, 'UTF-8', 'ISO-8859-1');
}

Schritt 3 – TYPO3-spezifisch: HTTP-Request-Daten bereinigen

• In der eigenen Extension oder im Middleware-Setup sicherstellen, dass alle Request-Parameter ($_GET, $_POST, $_REQUEST) vor der weiteren Verarbeitung durch mb_convert_encoding() oder ähnliche Funktionen validiert werden.

Schritt 4 – Datenbank-Connection prüfen:

• In LocalConfiguration.php sicherstellen, dass der PDO/MySQL-Connection charset korrekt auf utf8mb4 gesetzt ist:

'DB' => [
    'Connections' => [
        'Default' => [
            'charset' => 'utf8mb4',
            'tablePrefix' => '',
        ],
    ],
],

3. Betroffene TYPO3 Extension¶

Da der Fehler im title-Feld auftritt und über den normalen HTTP-Request-Flow läuft (Middleware-Dispatcher → Application), ist die genaue Extension ohne genauere Stack-Trace-Angaben nicht eindeutig identifizierbar. Basierend auf dem Kontext ist es jedoch höchstwahrscheinlich eine Custom-Extension oder eine System Extension, die Eingabedaten direkt aus HTTP-Parametern in Datenbankeinträge schreibt.

Häufige Verdachtskandidaten:

• Eigene Frontend-Plugins, die Titel/Überschriften aus URL-Parametern ableiten
• News-Extensions (z.B. news / GeorgRinger.News)
• Mask-Content-Elemente
• Eigene Backend-Module mit Formulareingaben

Um die betroffene Extension exakt zu identifizieren, sollte der SQL-Query aus den TYPO3-Logs analysiert werden (welche Tabelle und welcher Record wird geschrieben?).

4. Confidence¶

85% — Die Analyse ist sehr hochgradig wahrscheinlich korrekt:

• Die Bytes \xC0\xA7 sind eindeutig keine gültigen UTF-8-Sequenzen
• Das Vorhandensein von %2 im Fehlerstring bestätigt URL-Encoding als Datenquelle
• MySQL strict mode lehnt dies ab
• Die Lösung (Encoding-Validierung + Konvertierung) adressiert das Problem direkt

Die 15% Unsicherheit resultiert daraus, dass die exakte Extension, die die fehlerhafte Eingabe erzeugt, ohne den vollständigen SQL-Query und weitere Stack-Trace-Daten nicht endgültig bestimmt werden kann.