Version 2.05 Bugfix Änderung

Antwort erstellen

Bestätigungscode
Gib den Code genau so ein, wie du ihn siehst; Groß- und Kleinschreibung wird nicht unterschieden.
Smileys
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:

BBCode ist eingeschaltet
[img] ist eingeschaltet
[url] ist eingeschaltet
Smileys sind eingeschaltet

Die letzten Beiträge des Themas
   

Ansicht erweitern Die letzten Beiträge des Themas: Version 2.05 Bugfix Änderung

Re: Version 2.05 Bugfix Änderung

von Frank S. » Do 9. Jul 2026, 04:40

Hallo zusammen,

ich weiß, das ist ein ziemlich alter Forenbeitrag, aber mein Bugreport scheint genau hier zu passen.

Vor etwa sechs Jahren wurde in operations.php offenbar folgender Code eingefügt:

Code: Alles auswählen

if (strlen($signtxt) > 120) {
    $signtxt = substr($signtxt, 0, 117) . "...";
}
Dadurch wird der String auf 120 Zeichen gekürzt. Das Problem ist allerdings, dass strlen() und substr() auf Bytes arbeiten.

Enthält ein Artikelname Sonderzeichen (bei uns war es z. B. „Radler-Süß“), kann es (scheinbar völlig zufällig und sehr sporadisch) passieren, dass substr() genau mitten in einem UTF-8-Multibyte-Zeichen abschneidet. Beim Speichern des ungültigen UTF-8-String in der Datenbank führte das anschließend zu folgendem PHP-Fehler:

Code: Alles auswählen

[Sun Jun 28 17:41:02.349905 2026] [php:error] [pid 23899] [client 192.168.0.208:50322] PHP Fatal error:  Uncaught PDOException: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: '\\xC3...' for column `ordersprinter`.`os_operations`.`signtxt` at row 1 in /var/www/html/php/commonutils.php:510\nStack trace:\n#0 /var/www/html/php/commonutils.php(510): PDOStatement->execute()\n#1 /var/www/html/php/utilities/operations.php(51): CommonUtils::execSql()\n#2 /var/www/html/php/queuecontent.php(1977): Operations::createOperation()\n#3 /var/www/html/php/queuecontent.php(1908): QueueContent::signAtTSE()\n#4 /var/www/html/php/queuecontent.php(1533): QueueContent->addProductListToQueueCore()\n#5 /var/www/html/php/queuecontent.php(125): QueueContent->addProductListToQueue()\n#6 /var/www/html/php/contenthandler.php(75): QueueContent->handleCommand()\n#7 {main}\n  thrown in /var/www/html/php/commonutils.php on line 510, referer: http://192.168.0.100/waiter.html
Erst wenn die komplette Bestellung verworfen und anschließend neu erfasst wurde, funktionierte alles wieder. Dabei wurde die Reihenfolge der Bestellung (zufällig) geändert, sodass der Schnittpunkt nicht mehr mitten in einem Multibyte-Zeichen lag.

Die Lösung besteht darin, UTF-8-fähige Funktionen zu verwenden, z. B. mb_strlen() und mb_substr(), damit immer an einer gültigen Zeichenposition abgeschnitten wird (wobei mit diesen Funktionen längere Strings als 120 Byte entstehen können).

Ich habe es jetzt so gelöst:

Code: Alles auswählen

if (strlen($signtxt) > 120) {
    $signtxt = mb_strcut($signtxt, 0, 117, 'UTF-8') . "...";
}
Folgende Zeile ist ebenso anfällig für Multi-Byte-Zeichen, hat aber wohl keine Funktion mehr

Code: Alles auswählen

$signtxt_ascii = preg_replace('/[[:^print:]]/', '', $signtxt);
Gruß Frank

Re: Version 2.05 Bugfix Änderung

von pichel » Di 15. Sep 2020, 19:43

Hallo,

der von der TSE zu signierende text, der eben abhängig von der Bestellung ist, wird in der Tabelle operations in einer Spalte signtxt gesichert. Diese war bis 2.0.4 vom Typ VARCHAR, und je nach Konfiguration der Datenbank gab es einen Fehler, wenn der zu signierende Text eben länger als die festgelegte maximallänge war.

Gruß,

Stefan

Version 2.05 Bugfix Änderung

von Meolo » Di 15. Sep 2020, 18:42

Moin,

bei der Version 2.05 gab es ja einen Gubfix.

"Bugfix: Bei großen Bestellungen konnte es bei bestimmten Datenbankkonfigurationen zu einem Fehler kommen. Gefixt."

Wie hat sich der Fehler den bemerkbar gemacht?

Gruß
Thorsten

Nach oben