Gelöst: vBulletin Suche Sonderzeichen und Umlaute

Ja, ich glaube aber fast nicht, dass da von denen was kommt oder geändert wird, denn es schaut leider nicht nach einem vb-Problem aus
Es muss aber mit den Texten "text" zu tun haben, denn vom Eintippen über senden in die Wort-Tabelle geht. Nur der manuelle Abruf aus der "text" nicht. Also am Import der Daten in die "words" liegt es schon mal nicht, denn das geht ja. Die Frage ist hier also, warum kommen die beim manuellen Erstellen falsch bei "words" an. Oder werden die vielleicht schon falsch aus "text" ausgelesen". Irgendwo dazwischen liegt das Problem.

So, eines mehr, aber immer noch nicht schlauer...

"Fehlermeldung doppelter Key" hatte ich jetzt auch, als ich versuchte von latin1 auf utf8 umzustellen. Ich habe da ein Wort "anderung" und ein "änderung". Und genau aus dem "änderung" versucht er bei der Umstellung auch "anderung" zu machen, was dann doppelt ist.

So, mal soviel dazu. Die Meldung ist richtig. Ist kein Bug von vBulletin und auch nicht von MySQL. Die Darstellung hier mit dem falschen ä ist dem Template geschuldet, Mails und Nachrichten kommen ja auch zerschossen an, Anmeldebestätigungen etc.

So, aber wieder zum Fehler. Laut MySQL ist a=ä=A=Ä und so weiter mit den anderen Sonderzeichen und zwar bei utf8_general_ci und utf8_unicode_ci. Das erklärt, warum es bei mir mit latin1_swedish_ci funktioniert. Bei Dir will er quasi "hätten" eintragen, was dann aber auf Grund des Unique-Key nicht geht, da es mit "hatten" kollidiert. Gut, man könnte mit "IGNORE" die Fehlermeldung umgehen, der Fehler an sich ist aber keiner und laut MySQL korrekt.

So, Ergänzung. Lösungen sind da laut MySQL mehrere.

1. Entweder "latin1_swedish_ci", was in etwa wie Binary arbeitet, aber nicht den Zeichensatz von utf8 umfasst.

2. Auf utf8_bin umsteigen. Das Problem mit utf8_bin ist, dass es unterscheidet zwischen Groß- und Kleinschreibung, was utf8_general_ci und utf8_unicode_ci auch nicht taten.

Allerdings sollte das klein Problem sein, denn wie man oben sieht, setzt vBulletin alle Suchbegriffe automatisch auf Kleinbuchstaben um.

Oder Lösung 3, die da wäre, auf MySQL 6 zu warten, das utf8_german2_ci enthalten soll. Wobei das schon da ist und nicht enthalten ist. Aktuell wohl geplant für MySQL 6.1, aber in der Beta auch noch nicht enthalten.

ich rufe da mal wieder nach MariaDB

Ach ja, die Änderungen wurden irgendwann bei der 5.1.2x vollzogen.

Doch, kompatibel ist das schon. Hier kommen nur gerade zwei unterschiedliche Sachen zusammen.

1. Die Fehlermeldung oben:
Auf die bezog sich mein Post. Daran ist nicht vBulletin schult, sondern utf8_gereral_ci, da eben "hatte" und "hätte" das gleiche ist. In der words-Tabelle ist zudem noch ein Unique-Index, der dann eben die Meldung auslöste. Wäre da ein "INSERT IGNORE" gewesen, dann hättest Du die Mail nicht bekommen, der Fehler selbst wäre aber dennoch da - wobei es ja eben kein Fehler ist, sondern ein gewünschter Zustand von utf8_gereral_ci.

2. Das ist das Thema mit den fehlenden Sonderzeichen bei der Suchindexerstellung. Wo genau das her kommt ist unklar. Das kann an utf8_gereral_ci liegen, muss aber nicht. Wobei noch nicht mal klar ist, ob da überhaupt ein Fehler ist. Es werden ja auch Sonderzeichen in die words geschrieben. So ist das ja nicht. Nur "Hundebürste" könntest Du nicht finden, da "Hundeburste" drinnen ist. Also wieder das Spiel mit dem "u = ü". "schön" ist auch nicht drinnen "schon" aber. Meine "hundebürsten" (mehrzahl) sind auch da. "hundebursten" würde nun wieder nicht gehen.

"Meinst du nicht auch das utf8_general_ci viele einsetzen?"
Eigentlich ja, ich selbst auch durchgängig. Aber general ist halt auch veraltet. Unicode ist der Nachfolger, aber der würde das Problem auch nicht lösen, denn dort ist nur ein Unterschied bei der Sortierung und beim ß. Ansonsten gibt es die jeweiligen länderspezifischen oder eben die "_bin", die wirklich Zeichen für Zeichen exakt vergleichen..

Ich kanns noch nicht mal bei mir im System (mein Server) testen, da ich das Problem damals schon umgangen habe. Ich wandle bei mir alle Sonderzeichen um, also ü > u, ä > usw. und mache mir den Sachverhalt von utf8_general_ci zu Nutze, dass der eben bei einem a auch ein ä findet. Bei mir steht etwa "Überlingen" klein als "uberlingen" in der Datenbank.

Das kann aber z.B. vBulletin so nicht auch global umsetzen, da es eben nur bei utf8_general_ci funktioniert. Bei latin1_swedish_ci würde es Fehler liefern.

Daher das Beste eigentlich, was den Fehler betrifft: Suche Dir eine Kollation, die damit klar kommt. Entweder latin1_swedish_ci oder utf8_bin. Muss auch nicht bei der Tabelle geändert werden, es reicht bei den Spalten und da eigentlich auch in der forum_words

Zitat

deine test DB

Du meinst Die von dem Textforum?

Ich habe noch nichts gemacht... Wollte was tippen, aber da war es weg...

Also jetzt noch mal:

swedish kannst knicken, da da vieles andere auch drinnen ist. Russisch und weiß der Geier was.

10-5

Nein, das ist nicht "Zehn bis Fünf", das ist dieser Bindestrich aus Word oder so, aber kein normaler 10-5

Dann steht das "viel" aber auch das nicht das Wort ala Gegenteil von wenig. Das ist "viel?" und das ? steht für eine "NO ASCII CHAR". Daher eben auch nicht sichtbar im pma.

Oder "wir" als "?wir". Wieder "NO ASCII CHAR".

Oder "kam" als "?kam". Wieder "NO ASCII CHAR".

¦¦¦¯_¯_¯_¦¦¦¦ Das aber als Grafik. Schaut fast aus wie eine Formel-1-Zielflagge.

oder "?lichen" wobei hier das ? ein "Herz" ist.

oder "g…gle" Das sind diese drei unteren Punkte, auch aus Word.

Also alles Zeichen, die swedish nicht kann.

Wir könnten die einfach löschen, aber dann würdest Du bei jedem Versuch, so ein Wort einzutragen wieder eine Fehlermeldung bekommen und das zu Recht.

Können wir hier nun mal 30-45 Min testen? Betrifft auch nur die Suche!

Also, wenn man das Testen kann, dann ok. Suchindex bitte löschen.

Ich stelle die forum_words.word nun mal auf utf8_bin um - nachdem gelöscht ist.