Umlaut-Fehler

[Predarr]

re *g*

stimmt.. hatte mich mit PHP vertan... an MySQL gedacht und über PHP geredet... übel

so... hat etwas gedauert, war etwas eingespannt die Tage.

Ich hab die DB als latin1 und latin2 hochgeladen. Leider zeigen sich die gleichen Fehler an gleicher Stelle

[oxpus]

Hm, vielleicht kann man die Daten irgendwie auf ISO konvertieren, also das Backup selber.
Bessere Texteditoren können das, meiner macht das aber auch nur über Umwege, kann also nicht genau sagen, welcher das beherrscht.
Ultraedit vielleicht...

[Predarr]

hmm.. verstehe was Du meinst...

Werd mal schauen, was ich da so finde Ich meld mich, wenn ich mehr weiss

[Predarr]

hab grad etwas in der db gesehen... dort steht:

Code: Alles auswählen

ENGINE=MyISAM DEFAULT CHARSET=latin1;

Hilft Dir das schon irgendwie?

[oxpus]

DEFAULT CHARSET=latin1;

Das mal entfernen sollte meist schon helfen.

[Predarr]

[quote="oxpus";p="84826"]Hm, vielleicht kann man die Daten irgendwie auf ISO konvertieren, also das Backup selber.
Bessere Texteditoren können das, meiner macht das aber auch nur über Umwege, kann also nicht genau sagen, welcher das beherrscht.
Ultraedit vielleicht...[/quote]
ich hab mir mal 2 Editoren angesehen... PSPad und Notepad++

Letzteres kann zwar UTF8 (siehe Screenshot), aber das nutzt ja leider nichts

Einen Editor, der in ein ISO-charset konvertiert hab ich nicht gefunden
[quote="oxpus";p="84845"]

DEFAULT CHARSET=latin1;

Das mal entfernen sollte meist schon helfen.[/quote]
hab ich entfernt und als latin1 sowie latin2 wieder hergestellt... erfolglos *heul*

ABER... ich hab etwas festgestellt.... *rotwerd*

Ist ein wenig peinlich, weil ich das mal zwischendurch mal hätte sehen können...

Ich arbeite vorwiegend mit Firefox. Habe aber auch den IE7 (Vista).

db ohne "DEFAULT CHARSET=latin1;".

Ich habe die db nochmal als Latin1 wiederhergestellt und gesehen, dass der FF automatisch UTF8 als Zeichenkodierung wählt. Die Sonderzeichen stimmen nicht.

Stelle ich manuell auf iso-8859-1 ist der Fehler weg.

Spaßeshalber die DB als UTF8 wiederhergestellt und der FF stellt als Zeichenkodierung ebenfalls automatisch auf UTF8 und die Sonderzeichen stimmen nicht. ABER auch hier... stelle ich manuell auf iso-8859-1, stimmen die Zeichen. Interessant hier, dass nach der manuellen Umstellung auf iso-8859-1 sogar die Zeichen in den Beiträgen wieder stimmen...

Der IE stellt es beide Male falsch dar *g*

Es scheint also, als würde irgendwo so früh ein charset übergeben, welches den Browser veranlasst, den "Falschen" voreinzustellen... oder seh ich das falsch?

[oxpus]

Und das Forum läuft auf ISO, oder wie war das noch einmal?

UTF-8 ist Standard unter MySQL, daher solltest Du das DB-Backup auch so wieder herstellen.
Die CHARSET-Einträge im Backup müssen dazu allerdings gelöscht werden!
In 99.99% der Fälle ist das der korrekte Weg.
Das Forum muss dann allerdings auch auf ISO bleiben, damit der Browser alles korrekt darstellen kann.
Ich denke aber, daß hier nun langsam alles knotig und immer mehr defektgemoddet wird, wenn nicht mal eine klare Linie in das Forum kommt.

Noch einmal: Der Browser richtet sich nach automatisch erkannten Schriftsätzen, solange im HTML-Header nicht ein CHARSET angegeben ist. Das phpBB gibt hierzu eben daher ISO an!

[Predarr]

japp, Forum läuft auf iso-8859-1 (steht ja in der lang_main.php). Hab da nichts geändert.

"DEFAULT CHARSET=latin1;" hab ich aus der db-Sicherung herausgelöscht und dann erst wiederhergestellt.

Wiederhergestellt mit UTF8 und Latin1 sowie Latin2 (je ein Versuch, logo *g*)...

Als Basis hab ich eine db-Sicherung genommen, welche Volker für mich an die neue Dim angepasst hatte (vorher Dim 0.2.6).

Dennoch (egal, wie ich die db wiederherstelle), erkennt der FF UTF8 als Standardzeichensatz (bei dem läßt sich das ja leichter erkennen).

Ich habe sogar, um zu sehen ob der Fehler irgendwo im Board ist, die db gelöscht und eine Neuinstalltion durchgeführt. Dort erkennt der FF (und der IE) den korrekten Zeichensatz (iso-8859-1).

Und genau das versteh ich nicht

Einerseits sagtest Du ja, das der Browser durch die Einstellung im header (overall_header.tpl/lang_main.php) den Zeichensatz erkennt... andererseits erkennt der Browser einen anderen Zeichensatz, obwohl im header nichts verändert wurde

Daher vermutete ich, dass der Browser doch vorher noch eine andere Infromations über den Zeichensatz bekommt...

Boah... wie kompliziert Probleme sein können

[oxpus]

Ersetze mal zusätzlich in der overall_header.tpl und ggf. auch simple_header.tpl die Zeile

Code: Alles auswählen

<html dir="{S_CONTENT_DIRECTION}" xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml">

durch

Code: Alles auswählen

<html dir="{S_CONTENT_DIRECTION}">

Vielleicht hilft das auch schon...

[Predarr]

in der simple_header.tpl stand das nicht drin.. in der overall_header.tpl hab ich es ersetzt.

Weder im FF noch im IE eine Veränderung Der IE ist sogar so konfiguriert, dass er die Daten bei jedem Besuch der Website neu lädt... also nicht au den Cache zurück greift

[Predarr]

keine Idee mehr

[oxpus]

Nicht wirklich.
Der mysqldumper soll in der kommenden Version (also dann 1.2.3) damit zurecht kommen. Ansonsten kannst Du nur das Backup so erstellen, wie es der Zielserver auch versteht, also wie der Default-Datensatz bei den Datenbanken eingestellt ist.
Per Standard ist das unter mysql vor 4.1 unterschiedlich, ab 4.1 immer UTF-8.
Dabei nutzt es aber leider nicht immer was, wenn das Backup schon nicht zum Zielserver passend erstellt wurde.
Das habe ich auch schon in den letzten Tagen erfahren müssen...

[Predarr]

es ist irgendwie auch wie verhext...

Standard-Installation funktioniert, Backup nicht... ist schon mehr als merkwürdig...

Ich werd mal sehen... wahrscheinlich muss ich mit dem Fehler leben

Ich danke Dir trotzdem vielmals und heftigst für Deine Hilfe und Deine enorme Mühe

Sollte ich wider Erwarten noch ne Idee haben oder irgendwas hören, was hilft, schreib ich's hier rein

Danke

[Holger]

Sorry, ich muss mich hier mal kurz einmischen.
Das Beispiel auf der ersten Seite mit dem Bedankomat: der Text kommt ja nicht aus der DB.
Ich musste nach einem Server-Umzug ALLE lang-Dateien in UTF-8 abspeichern. Danach hatte ich diese Probleme nicht mehr.

[Predarr]

[quote="Holger";p="85255"]Sorry, ich muss mich hier mal kurz einmischen.
Das Beispiel auf der ersten Seite mit dem Bedankomat: der Text kommt ja nicht aus der DB.
Ich musste nach einem Server-Umzug ALLE lang-Dateien in UTF-8 abspeichern. Danach hatte ich diese Probleme nicht mehr.[/quote]
hmm.. klingt nach einem Versuch

Aber.. wie speichere ich im UTF8-Format, bzw. womit?

[Holger]

Ich mache das mit Textpad ( http://www.textpad.com )
"Speichern unter ..."

[oxpus]

LANGSAM!
NUR wenn auch das Boar dselber dnn auf UTF-8 umgestellt wurde, kann der Browser den korrekten Schriftsatz erkennen und anzeigen!
Sonst wird gemischt und man erhält an diversen Stellen Kuddelmuddel in der Anzeige!

[Predarr]

hehe.. stimmt... *grad das Ergebnis gesehen*

War aber ein Versuch wert..

Jetzt sieht's richtig wild aus... in der Navigation vom Portal fehlen jetzt kpl. Einträge *g* Der Text fehlt sogar teils völlig *g*

Es lebe die Sicherung *g*

[Holger]

[oxpus]

[quote="Holger";p="85264"][/quote]

Wie gesagt: Mit unterschiedlichen Zeichensätzen auf einer Seite muss man immer vorsichtig sein, sonst gibt's Anzeigefehler.
Denn der Browser muss sich ja nach irgendwas richten und in der Regel steht dazu ja der Zeichensatz im HTML-Header.
Passt der nicht immer auf den Rest der Seite, kommen "Sonderzeichen" zum Vorschein, die man vorher nicht gekannt hat

[Holger]

Hmmm, ich habe da ein riesiges Kuddelmuddel bei S4Y glaube ich.
In der Datenbank kann man die Umlaute nicht sehen, sie werden aber auf der Seite richtig dargestellt usw ...
Ich musste wie gesagt alle lang-Dateien auf UTF-8 abspeichern um einiges auszubügeln ...

[oxpus]

Das ist kein Kuddelmuddel, sondern die Zeichen werden ggf. als Steuerzeichen in den Tabellen abgelegt, dem eingestellten Zeichensatz entsprechend.

[Predarr]

hmm...

mir hat das irgendwie keine Ruhe gelassen....

Ich habe die lang-Dateien, die Probleme gemacht haben einfach mal utf8-codiert.. sprich als utf8 gespeichert und hochgeladen...

Ja, ich weiss, das ging doch nicht

Es gibt einen Unterschied... die lang_main hab ich manuell geändert.. sprich aus ä wurde ä usw.

Leider ging das nicht mit allen Sonderzeichen, aber dennoch sind nun 99% aller Fehler weg.

Merkwürdig ist das trotzdem... oder nicht?

[oxpus]

Dazu muss die Kodierung in der lang_main.php angegeben werden, also anstelle ISO-... eben UTF-8 und auch die emailer.php und smtp.php müssen daraufhin angepasst werden, damit die Emails ebenfalls nicht verstümmelt beim User ankommen.
Insgesamt mehr Arbeit, als daß man ein ordentliches Backup wiederherstellt...

[Holger]

Die Sache mit dem emailer.php ist grausam!
Alles kommt korrekt an, nur die Titel der Emails nicht ...