Welches UTF-8 bei MySQL-DB in phpMyadmin, um das scharfe S (ß) zu bekommen?

Marcus Gräfe · 20. Januar 2013, 22:23

Ich habe lokal in XAMPP eine MySQL-Datenbank via phpMyAdmin angelegt. Als Kollation habe ich utf8_unicode_ci gewählt. Nun meckert MySQL beim Eintrag vom String "ausschnitt" in ein Unique-Feld, wenn ich "Außschnitt" eintragen will (jetzt mal unabhängig von der falschen Rechtschreibung). Also irgendwas scheint er mit dem "ß" zu machen (scheinbar wird es durch ein einfaches "s" ersetzt). Muss ich eine andere Kollation wählen?

joschi240 · 21. Januar 2013, 06:58

ich nutze immer utf8_general_ci.

du kannst es mal probieren dass zu zuerst mysql sagst, wie du kommunizierst ->

PHP-Quellcode

SET NAMES 'utf8'

Marcus Gräfe · 21. Januar 2013, 18:47

"utf8_general_ci" brachte leider auch keinen Erfolg. Ich importiere die Daten mit dem PHP-Skript "bigdump" (neueste Version). Dort ist "utf8" als "db_connection_charset" eingestellt.

Wenn ich die importierten Daten abrufe (ist eine lokale Kopie von VBP), so sind alle "ß", Umlaute usw. korrekt. Nur beim Eintragen gibt es eben den genannten Fehler.

Samus Aran · 21. Januar 2013, 19:54

Dann solltest du bei jedem Eintragen den SET NAMES 'utf8'-Teil zur Query hinzufügen.

Marcus Gräfe · 21. Januar 2013, 20:03

Interessanterweise steht im Header meines SQL-Dumps "/*!40101 SET NAMES utf8 */;". Aber dabei handelt es sich wohl um einen Kommentar, der nicht ausgeführt wird.

Wäre diese Anweisung die einzige Möglichkeit? Scheinbar bietet bigdump mittels einer Variable namens "$pre_query" die Möglichkeit, sowas vor jedem Importvorgang auszuführen, wäre also vermutlich doch kein so großes Problem, wie ich erst dachte.

Samus Aran · 21. Januar 2013, 20:22

Soweit ich weiß, schon. MySQL errät (oder würfelt) ansonsten das Encoding der zu übergebenden Werte, und das geht schief.

Marcus Gräfe · 21. Januar 2013, 21:45

Ich werde das morgen mal testen, in der Hoffnung, dass das die Lösung ist. Ich melde mich dann wieder.

joschi240 · 21. Januar 2013, 21:52

Du kannst in php per mysql_client_encoding($conn) den aktuellen zeichensatz zurückgeben lassen.

ansonsten wie gesagt, einmal mysql_query("SET NAMES 'utf8'", $conn); ausführen.

Marcus Gräfe · 21. Januar 2013, 22:11

Bringt leider nichts. Es kommt der selbe Fehler:

Quellcode

Error at the line 1547806: INSERT INTO `wcf1_tag` VALUES (26024,0,'ausschnitt');
Query: INSERT INTO `wcf1_tag` VALUES (26024,0,'ausschnitt')
MySQL: Duplicate entry '0-ausschnitt' for key 'languageID'

Übrigens weiß ich nun laut dev.mysql.com/doc/refman/5.1/de/charset-unicode-sets.html dass der Unterschied zwischen utf8_general_ci und utf8_unicode_ci der ist, dass letzteres präziser sortiert, dafür aber langsamer ist.

mcandy007 · 22. Januar 2013, 00:13

Grundsätzlich speichert man gar keine Umlaute / Sonderzeichen in einer (MYSQL) Datenank.

Die Umlaute immer in Entities "umwandeln"
unicode.e-workers.de/entities.php

zB. in PHP bietet sich dafür die Funktion htmlentities() an.

Bei der Ausgabe mit html_entity_decode() wieder das "Original" wiederherstellen.

MFG

Marcus Gräfe · 22. Januar 2013, 19:34

Sag das Woltlab.

Ich möchte einen MySQL-Dump (direkt per MySQL an der Konsole gemacht) eines WBB auf einem anderen Server importieren. Egal wie, hauptsache, alles ist richtig.

Ich habe also keine Möglichkeit, irgendwas an den Daten zu verändern. Die sind wie sie sind.

slice · 22. Januar 2013, 21:19

wie wär es mit "replikation"? der mysql server bietet da schon von haus aus ne möglichkeit...
ansonsten gäbe es unter phpmyadmin noch "Synchronize" wobei ich dort nich weiß ob das eine funktion von phpmyadmin oder dem mysql server selbst ist

Marcus Gräfe · 22. Januar 2013, 22:09

Ich möchte aber ein automatisches Backup auf meinem Linux-Server (online) machen und das dann auf meinem lokalen Windows-Server importieren.

Marcus Gräfe · 24. Januar 2013, 21:14

Ich habe mir mal erlaubt, im Woltlab-Forum ebenfalls einen Thread dazu zu eröffnen. Leider gibt's auch da bisher keine Lösung für mich:

woltlab.com/forum/sonstige/ent…%9F-und-einmal-nur-mit-s/

Marcus Gräfe · 3. Februar 2013, 15:01

Ich habe nun die Kollation bei drei "Online-Foren" (u. a. VBP) von general auf unicode geändert (vorher nur im lokalen Testforum). Anschließend habe ich die Daten nochmal neu unter Windows importiert. Leider ist der Fehler immer noch da! Es gibt wieder die Fehlermeldung "Duplicate Entry". Ich dachte eigentlich, der Fehler müsste nun weg sein. Denn in meinem Testforum funktionierte es nach Umstellung der Kollation für neue Daten.

Mein aktueller Code zur Kollationsänderung lautet:

PHP-Quellcode

<?php
$database_host = 'localhost';
$database_name = 'x';
$database_username = 'y';
$database_password = 'z';
set_time_limit(600);
$connection = mysql_connect($database_host, $database_username, $database_password);
if(!$connection)
echo "Keine Verbindung möglich!";
else {
mysql_select_db($database_name);
$result = mysql_query('show tables');
while ($tables = mysql_fetch_array($result)) {
foreach ($tables as $key => $value) {
mysql_query("ALTER TABLE $value CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;");
}
}
echo "Erfolgreich beendet!";
}
?>

Marcus Gräfe · 16. Februar 2013, 17:58

Das Thema hat sich nun erledigt. Der aktuelle Status (keine echte Lösung):

- Woltlab stellt in zukünftigen Versionen des WBB alles auf utf8_unicode_ci (statt utf8_general_ci), damit dürfte im neuen WBB der Fehler nicht mehr auftreten
- Ich lösche nun manuell die fehlerhaften Einträge aus der DB (es beschränkt sich auf Tags) und verknüpfe vorhandene Threads mit den "richtigen" Tags.

Welches UTF-8 bei MySQL-DB in phpMyadmin, um das scharfe S (ß) zu bekommen?

Welches UTF-8 bei MySQL-DB in phpMyadmin, um das scharfe S (ß) zu bekommen?

PHP-Quellcode

Quellcode

PHP-Quellcode

Benutzer online 1

Tags

Ähnliche Themen

3 Benutzer haben hier geschrieben