WebsiteBaker Support (2.12.x) > Hilfe & Support (deutsch)

ugradee von 2.8.3 - stell mich dumm an

<< < (8/15) > >>

jacobi22:

--- Quote ---Habe heute das zweite Update gemacht - und dabei auch extra darauf geachtet, dass wirklich UTF8 eingestellt war. Auch in der Datenbank bei wb settings stand utf-8.

Leider waren die Umlaute nach dem Upgrade trotzdem alle verhackstückelt. Hat mich jetzt gerade 1,5 Stunden gekostet, das alles wieder zu richten, weil es viele einzelne Abschnitte und Seiten gab.
--- End quote ---

bitte nicht persönlich nehmen, aber ich denke, du hast die Problematik noch nicht richtig verstanden.

Früher war es üblich, das Webseiten im deutschen Sprachraum den Zeichensatz latin1 oder einer seiner Abwandlungen wie z.b. latin1_swedish benutzt haben.
Mit diesem Zeichensatz werden Sonderzeichen wie unsere Umlaute usw innerhalb der Datenbank kodiert.
Über den in der Auslesedatei (i.d.R der Browser) eingestellten Zeichensatz wird dann der SQL-Code wieder zurück in für uns lesbare Zeichen decodiert.
Einzig möglicher Zeichensatz in WB ist der Standard-Zeichensatz von PHP, also UTF8. Da in deiner Datenbank aber keine UTF8-Zeichen vorhanden sind, sondern mit latin1 kodierte, kann der Browser dies nicht übersetzen, denn der soll und kann ja nur UTF8. Und darum kommt es dann zur Darstellung dieser UTF-Zeichen wie z.b. hier Grüße im Wort "Grüße"

UTF8 ist eine andere Form der Codierung. Mit dieser ist es möglich, alle Schriftzeichen der Welt darzustellen, egal, ob chinesisch, arabisch oder kyrillisch. Latin1 hat dagegen nur einen begrenzten Zeichensatz.  Zudem ist ein UTF8-Zeichen ist mit seinen 2 Stellen auch kürzer als die meist 5-stelligen HTML-Special-Chars in Latin1

Heutzutage verfügen auch die Editoren über interne Konverter, um SQL-Code in lesbare Buchstaben umzuwandeln, sichtbar z.b, wenn man eine reine SQL-Datei in Notepad++ öffnet

Hier ein Bild davon aus einem Backup in Notepad++



und nun das Gleiche in reinem SQL-Code aus einer per utf8 kodierten Datei  (gleiche Stelle der Datei) in einem SQL-Editor



das Gleiche noch einmal in Latin1 mit HTML-Special-Chars (siehe etwa mittig im Feld "name")




Um nun eine alte per Latin1 kodierte SQL-Backup-Datei nach UTF8 zu kodieren, braucht es eigentlich einen Konverter. Im begrenztem Rahmen reicht dafür Notepad++
Sollte es da nicht automatisch geschehen (ist abhängig von den Einstellungen), geht es dort auch über search&replace. Für deutsch-sprachige Seiten sind es ja meist nur ä, ö, ü, ß bzw &auml; &ouml; usw, und das für Groß- und Kleinbuchstaben getrennt. Die Kodierung sollte auf UTF8 stehen. Zu ersetzen wären die Specialchar's mit Buchstaben in Reinschrift, also &auml; mit ä ersetzen, &Auml; mit Ä

Irgendwo habe ich auch mal ein Konvertertool gesehen, hier oder in den Downloads, finde es aber nicht auf die Schnelle.
Dies hat dann auch gleich die Tabellen umgeschrieben, z.b. so etwas hier

  `ftp_server` varchar(255) character set latin1 collate latin1_general_ci NOT NULL,

Als Vorlage zum Abschauen dient z.b. eine Backup-Datei einer WB-Installation ab WB 2.10.0
Dies läßt sich aber auch in PHPmyAdmin per (vielen) Mausklicks erledigen (theoretisch für jede Tabelle und jedes Text-Feld einmal)

Nach dem Ersetzen wird diese dann in PHPmyAdmin oder Adminer usw wieder in die Datenbank importiert.

Die Änderung der sogenannten Table Collation bzw Field Collationen legen fest, mit welcher Kodierung Daten in die Tabelle geschrieben werden, es wirkt also nur beim Speichern neuer und geänderter Datensätze



 

astricia:

--- Quote from: jacobi22 on February 01, 2019, 02:07:02 PM ---bitte nicht persönlich nehmen, aber ich denke, du hast die Problematik noch nicht richtig verstanden.

--- End quote ---

Da hast du wohl recht und ich nehme das auch gar nicht persönlich - ich mag es gar nicht und fühle mich sehr unsicher dabei, auf SQL-Ebene rumzuhantieren. Aber wenn ich dich jetzt richtig verstanden habe, komme ich da nichtdrum herum.

Nur noch mal zum Verständnis. Die Vorgehensweise wäre wie folgt:
- Datenbank runterladen
- Sicherheitskopie machen (sicher ist das...)
- Datenbank mit dem Notepad++ Editor öffnen
- Überprüfen ob das reine Öffnen bereits die Umlaute bereinigt hat
- Falls nicht, hier ein manuelles Bereinigen über die Suche und Ersetze Funktion (so hatte ich das in den einzelnen Textabschnitten hinterher gemacht..)
- Datenbank dann wieder speichern
- Geänderte Datenbank hochladen

Ich habe jetzt mal eine gespeicherte Datenbank mit dem Notepad++ geöffnet. Da wird bei mir nichts konvertiert. Ich finde sowohl HTML Entities (also &auml; für ä) als auch diese Hieroglyphen (ä für ä). Muss ich dann beides über Suchen+Ersetzen ändern, oder nur die Hieroglyphen?

Ersetze ich also ä durch ä oder ä durch &auml; ? Und muss ich noch irgendwas ersetzen außer ä,ö,ü,Ä,Ö,Ü,ß ?

Und mache ich das Ganze VOR Upgrade auf 2.12.1 oder nachher?

Sorry für die doofen Fragen, aber bei SQL bin ich echt raus. Gibts da nix in WB, was man installieren kann, dass das dann automatisiert gemacht wird?

jacobi22:

--- Quote ---Sorry für die doofen Fragen
--- End quote ---

es gibt keine doofen Fragen   :wink:


--- Quote ---Und mache ich das Ganze VOR Upgrade auf 2.12.1 oder nachher?
--- End quote ---

spielt keine Rolle
Wenn du es vorher machst, könntest du es sogar in der alten Version schon testen, die noch die Zeichensatzeinstell ungen in den WB-Optionen haben


--- Quote ---Ersetze ich also ä durch ä oder ä durch &auml; ? Und muss ich noch irgendwas ersetzen außer ä,ö,ü,Ä,Ö,Ü,ß ?
--- End quote ---

kommt auf die Einstellungen in Notepad an (Kodierung soll auf UTF8 stehen)
dann aber ä durch ä und &auml; durch a - wobei Letzteres nicht ganz so wichtig wäre


--- Quote ---Ich finde sowohl HTML Entities (also &auml; für ä) als auch diese Hieroglyphen (ä für ä). Muss ich dann beides über Suchen+Ersetzen ändern, oder nur die Hieroglyphen?
--- End quote ---

Ja, wenn man einmal dabei ist, beides. Zwingend wäre aber ä für ä
Ursache ist hier entweder eine Umstellung in der Datenbank, vielleicht wurde manuell das Charset geändert oder vom Anbieter beim Upgrade der Serversoftware
Auch möglich: diese Textteile wurden mit älteren FCK- oder CKEditor-Versionen eingefügt. Dort wurde beim Speichern noch mal ein htmlspecialchars() benutzt. Dies stammt noch aus den Zeiten unterschiedlicher Zeichensätze. Die Browser können mit Zeichensatz UTF8 alle diese HTMLSpecialChars (like &auml;) lesen und "übersetzen" und einige ältere Module

gottfried:
Hallo Jacobi !

Ich hab den upgrade meiner 2.8.4 auf die aktuelle 2.12.1 nach deiner Beschreibung selber durchgeführt.
Mit einer config.php
Alles ist grün .....
Ich kann mich danach in das Backend einloggen und mir das alles ankucken.
Nur wenn ich aus dem Backend die aktuelle Seite aufrufe, lande ich immer auf der Startseite.
Auch wenn ich das Frontend aufrufe, komme ich nicht über die hinaus.

Dann habe ich die Seite, die du upgegradet hast auf den Server gelegt. Wenn ich da versuche in den admin zu kommen, kommt eine weiße Seite.
Aber ich komme im Frontend genau soauch nicht über die Startseite hinaus.

(ich hab momentan auf dem Server 3 Versionen und 3 Datenbanken, die sich nicht überschneiden)

Die Startseite läuft quasi in Schleife.

Das kann ja nur noch eine Kleinigkeit sein?

php ist immer noch 5.6 ????

 :-)

jacobi22:
Hast du zufällig in den WB-Optionen -> erweiterte Optionen oben unter allgemeine Einstellungen den Punkt URL Umleitung zur Homepage aktiviert?

der macht nämlich genau das

Werde mir deine Installation noch einmal "auflegen" - die war nach dem PC-Crash schon wieder fort. Wird aber heute nix mehr, hab zuviel aufzuholen

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version