Opened by GwenDragon at 2019-01-21 16:16
User since
2015-01-07
561 Artikel
BenutzerIn
2015-01-07
561 Artikel
BenutzerIn
2019-01-22T21:38:48 rostiProblem mit 1f440 ist nachvollziehbar. Wenn $dbh->do('SET NAMES UTF8'); angewiesen wurde, schlägt auf meiner Kiste der Insert mit diesem Zeichen fehl.
Normalerweise gibts da jedoch eine Fehlermeldung. MfG
Es ist bekannt, dass MySQL unter "UTF8" keine 4-Byte-Werte versteht. Sollte es tatsächlich so einfach sein?
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
Index: battie/lib/WWW/Battie/Module/Model.pm
===================================================================
--- battie/lib/WWW/Battie/Module/Model.pm (revision 3052)
+++ battie/lib/WWW/Battie/Module/Model.pm (working copy)
@@ -60,7 +60,7 @@
on_connect_do => [
# "SET sql_mode='STRICT_TRANS_TABLES,STRICT_ALL_TABLES'",
],
- mysql_enable_utf8 => 1,
+ mysql_enable_utf8mb4 => 1,
AutoCommit => 1,
# has to be 0 otherwise a begin_work dies after a
# connection timeout. let DBIC handle it
Siehe
DBD::MySQL - mir ist dafür kein SQL-Äquivalent bekannt. Es lohnt sich aber bestimmt, reinzuschauen, was denn in der Datenbank grade drinsteht, und auf welchen Wegen die Werte rausgeholt werden. Denn das normale Betrachten der 4-Byte-Characters funktioniert ja problemlos, und irgendwie müssen die ja auch in der Datenbank abgelegt sein. Oder auch nicht, wenn alles, was wir normalerweise zu lesen bekommen, aus einem Cache kommt.Es ist nicht auszuschließen, dass der Code in einigen Pfaden um das MySQL-Unicode-Problem herumcodiert hat, aber eben nicht in allen. Und dann führt der primitive Patch in genau diesen Pfaden zu Problemen. Das letzte, was man haben will, sind kaputte Inhalte in der Datenbank. BTST.