Jump to content
xt:Commerce Community Forum

Umlautdarstellung nach Update auf 4.0.14


elfried

Recommended Posts

Hi,

wir hatten eine restlos fehlerhafte Darstellung der Umlaute nach dem Update auf die 4.0.13. Den Fix eingespielt und das zerschossene Zeichen ist zwar in der Verwaltung noch fehlerhaft, im Kundenbereich aber wieder o.k..

Aber wenn wir jetzt etwas mit normalen Umlauten einstellen werden diese zerschossen angezeigt. Es kann doch nicht sein das wir jetzt nur noch ae ue etc. schreiben dürfen? Solch ein Fehler sollte meines Erachten bei einer Kaufsoftware nicht auftreten. Kann bitte jemand helfen?

Vielen Dank

Heinz

(unsere Seite ist shoppen4kids.de)

Link to comment
Share on other sites

  • 2 weeks later...

Hi,

nun muss auch ich mal kräftig motzen. Bei einer Kaufsoftware erwarte ich eigentlich eine ordentliche Arbeit. Es kann nicht angehen das nach dem Update die Umlaute zerschossen sind. Fix eingespielt...und das Ersatzzeichen wird im Kundenbereich wieder ordentlich angezeigt...aber wenn ich jetzt etwas neu mit Umlauten anlege wird es wieder zerschossen.

Leute, der Sch... kostet mich Geld wenn die Kunden wegen so einem Mist ausbleiben. Im Übrigen war es natürlich das Update auf die 4.0.13... Bin mal gespannt was sonst noch so alles auftaucht.

Eine super Shopsoftware ist gerade auf dem besten Weg sich bei Händlern ins Abseits zu schießen...wir leben vom Verkaufen und nicht vom Programieren...davon habt Ihr Ahnung!

Heinz

www.shoppen4kids.de

Link to comment
Share on other sites

Wenn es Umlautprobleme gibt dann liegt ein serverseitiges Problem vor, welches auch schon vor dem 4.0.13 Update bestand, 4.0.12 war nur etwas großzügiger mit fehlerhaften kodierungen in der Datenbank.

4.0.13 ist strikt utf-8

Das Problem ist hier am Server und Datenbank zu suchen, nicht an der Software (außer es wurde das Update nicht korrekt durchgeführt und nicht alle Datein ersetzt die zu ersetzen sind!).

Link to comment
Share on other sites

  • 1 month later...

Wenn das endlich mal ein Programmierer kapieren würde!

Diese Problem ist ein Problem des Programmierers.

default_charset = "iso-8859-1" oder wie auch immer ist eben ein Default und muss von der Anwendung die diesen Default nicht gebrauchen kann/muss entsprechent überschrieben werden, und zwar bevor noch irgendwas an den Browser übertragen wird. Siehe php.net

Das geht bei PHP nur mit:

header('content-type: text/html; charset=utf-8');

Wenn das Default in utf8 geändert wird, hat man halt das selbe Problem mit anderen Anwendungen die noch nicht UTF8 programmiert sind, nur eben anders herum. Dann gibt es die markanten schwarzen Rauten mit Fragezeichen.

Übrigends, das

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

im generierten html wird seit langem von den Browser nicht mehr ausgewertet und dient heute "nur noch" der Validierung.

Bei dem vorliegenden Problem, von dem ich auch betroffen war, wird das im Frontend gemacht und im Backend eben nicht. Erkennbar wenn man die Headerinfos auswertet. Siehe Screenshoots:

Codierungsfehler.jpg

Link to comment
Share on other sites

  • 5 months later...

Wenn es Umlautprobleme gibt dann liegt ein serverseitiges Problem vor, welches auch schon vor dem 4.0.13 Update bestand, 4.0.12 war nur etwas großzügiger mit fehlerhaften kodierungen in der Datenbank.

Toll, ich habe die 4.0.12. Ich setze jetzt mal "großzügiger mit fehlerhaften kodierungen" gleich mit "fehlerhaftes Veyton". Mein Supportticket für das kostenlose Update auf die 4.0.13 bleibt unbeantwortet. Warum soll ich hier für eine Fehlerbereinigung Geld zahlen?!?

So geht das nicht Herr Zanier!

Im Übrigen hat mir gerade der Amazon-Support bestätigt, dass der Export (das mit der Leerzeile erwähne ich schon gar nicht mehr) nicht in UTF-8 ist (pfannengundel.de/export2/amazon2.txt)

Gruß

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...