php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 25-04-2013, 12:14
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard Browser-Kodierung erkennen und Formular-Werte wandeln

Hallo Gemeinde,

ich habe das Problem, dass die Umlaute in Formulare von einer Website gelegentlich zerschossen sind.
Jetzt habe ich verschiedenen Tests gemacht und bin zu dem Schluss gekommen, dass es sehr wahrscheinlich an der Browser-Kodierung des Users liegt.

Die Website ist noch in ISO 8859-1 angelegt (und zu umfangreich das mal schnell auf UTF8 umzustellen).
Nun vermute ich, dass wenn ein User keine automatische Erkennung der Textkodierung im Brower aktiviert hat und diese fest auf UTF-8 steht, dass dann eben die Umlaute falsch übertragen werden.
Wenn ich immer mit utf8_decode() die Werte ändere, sind die aber auch teils falsch.

Meine Frage nun: Kann ich irgendwie abfragen, in welcher Kodierung Werte übergeben wurden und dann nur utf8-decode, wenn die Seite auch als UTF-8 aufgerufen wurde?

Grüße,
Andi
Mit Zitat antworten
  #2 (permalink)  
Alt 25-04-2013, 12:29
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von andik2000 Beitrag anzeigen
Hallo Gemeinde,

ich habe das Problem, dass die Umlaute in Formulare von einer Website gelegentlich zerschossen sind.
Jetzt habe ich verschiedenen Tests gemacht und bin zu dem Schluss gekommen, dass es sehr wahrscheinlich an der Browser-Kodierung des Users liegt.

Die Website ist noch in ISO 8859-1 angelegt (und zu umfangreich das mal schnell auf UTF8 umzustellen).
Nun vermute ich, dass wenn ein User keine automatische Erkennung der Textkodierung im Brower aktiviert hat und diese fest auf UTF-8 steht, dass dann eben die Umlaute falsch übertragen werden.
Wenn ich immer mit utf8_decode() die Werte ändere, sind die aber auch teils falsch.
SELFHTML: HTML/XHTML / Formulare / Formulare definieren

Aber in der Regel ist das nicht notwendig. Vermutest du, dass die User eine andere Zeichenkodierung einstellen oder weißt du das? Eine falsch gewählte Kodierung kann übrigens auch an kaputtem HTML-Code liegen. Schon mal deinen HTML-Code mit dem W3C-Validator auf Fehler überprüft?

Zitat:
Zitat von andik2000 Beitrag anzeigen
Meine Frage nun: Kann ich irgendwie abfragen, in welcher Kodierung Werte übergeben wurden
Nein, das ist nicht möglich. Man kann es höchstens erraten, was aber nicht zuverlässig funktioniert.
Mit Zitat antworten
  #3 (permalink)  
Alt 25-04-2013, 14:15
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Prima, accept-charset ist die Lösung!

Ich habe sonst keine andere Erklärung und konnte das Ergebnis auch durch umstellen der Textcodierung im Browser rekonstruieren.
Ich vermute, dass manche Browser mittlerweile fest auf UTF-8 gestellt sind.

Jetzt habe ich in einem Testformular accept-charset verwendet und siehe da - die Mail kommt sauber an, egal auf welche Kodierung ich den Browser stelle.
Nun hoffe ich mal, dass das auf der Live-Website jetzt auch das Problem lösen wird.

Danke, Andi
Mit Zitat antworten
  #4 (permalink)  
Alt 25-04-2013, 14:20
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von andik2000 Beitrag anzeigen
Ich habe sonst keine andere Erklärung und konnte das Ergebnis auch durch umstellen der Textcodierung im Browser rekonstruieren.
Schon den HTML-Code auf Fehler überprüft? Welche Kodierung wird im HTTP-Header gesetzt?

Zitat:
Zitat von andik2000 Beitrag anzeigen
Ich vermute, dass manche Browser mittlerweile fest auf UTF-8 gestellt sind.
Nein.
Mit Zitat antworten
  #5 (permalink)  
Alt 25-04-2013, 14:43
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Zitat:
Zitat von h3ll Beitrag anzeigen
Schon den HTML-Code auf Fehler überprüft? Welche Kodierung wird im HTTP-Header gesetzt?
Ja, ich habe alle Header-Angaben geprüft, was relativ einfach ist, da dieser nur einmalig in einem Template gesetzt wird - aber ich habe auch die Kodierung der Templates und PHP-Dateien geprüft, ob hier irgendwo im Weg mal eine Datei UTF-8 codiert ist, aber habe nichts gefunden.

Da von 100 Formularen nur 2-3 dabei sind, bei denen es Probleme mit den Umlauten gibt, vermute ich halt schon, dass es irgendwie an der Browser-Kodierung liegt.
Ich habe selbst hier in der Agentur mit 15 Rechnern festgestellt, dass bei dreien der Browser nicht auf "Standard" bzw. "automatische Erkennung" sondern auf UTF-8 oder "Western Europe ISO Latin 1" gestellt war. Und das bei Grafikern, die nie irgendetwas an den Einstellungen verändern. Bei nem Programmierer hätte ich das ja noch nachvollziehen können, dass da zum Testen mal was verstellt wurde.

Auf jeden Fall füllt das accept-charset hier auch wieder eine Wissenslücke und hoffe, dass dies das Problem dauerhaft löst.
Wir werden es in den nächsten Tagen wissen :-)
Mit Zitat antworten
  #6 (permalink)  
Alt 25-04-2013, 14:57
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von andik2000 Beitrag anzeigen
Ja, ich habe alle Header-Angaben geprüft, was relativ einfach ist, da dieser nur einmalig in einem Template gesetzt wird - aber ich habe auch die Kodierung der Templates und PHP-Dateien geprüft, ob hier irgendwo im Weg mal eine Datei UTF-8 codiert ist, aber habe nichts gefunden.
Ich meinte nicht nur den Header, sondern das gesamte HTML-Dokument.

Außerdem hast du meine Frage zum HTTP-Header (nicht HTML-Header) nicht beantwortet.

Zitat:
Zitat von andik2000 Beitrag anzeigen
Da von 100 Formularen nur 2-3 dabei sind, bei denen es Probleme mit den Umlauten gibt, vermute ich halt schon, dass es irgendwie an der Browser-Kodierung liegt.
Dann hätten aber alle das Problem und nicht nur du, oder?

Zitat:
Zitat von andik2000 Beitrag anzeigen
Ich habe selbst hier in der Agentur mit 15 Rechnern festgestellt, dass bei dreien der Browser nicht auf "Standard" bzw. "automatische Erkennung" sondern auf UTF-8 oder "Western Europe ISO Latin 1" gestellt war. Und das bei Grafikern, die nie irgendetwas an den Einstellungen verändern.
Jaja... Die "ich hab nichts gemacht"-User. Wer kennt sie nicht? Von alleine verstellt sich das jedenfalls nicht.

Zitat:
Zitat von andik2000 Beitrag anzeigen
Auf jeden Fall füllt das accept-charset hier auch wieder eine Wissenslücke und hoffe, dass dies das Problem dauerhaft löst.
Wir werden es in den nächsten Tagen wissen :-)
Naja, Accepted-Charset schadet sicher nicht. Aber wenn der Browser eine falsche Kodierung wählt, sind spätestens bei der Ausgabe wieder Zeichenprobleme vorprogrammiert. Von daher sollte man das Problem an der Wurzel packen und nicht die Folgen umgehen.
Mit Zitat antworten
  #7 (permalink)  
Alt 25-04-2013, 15:30
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Also das Umlaut-Problem berichten mir immer mal wieder drei Kunden, bei denen die Seiten noch in ISO 8859-1 sind.
Im einfachsten Fall haben wir wirklich eine ganz simple Seite mit nem Kontaktformular, wo dahinter die Werte per Mail an den Kunden verschickt werden. Der meldet sich alle halbe Jahre mal, dass er ne Mail mit komischen Zeichen bekommen hat.

Bei nem anderen Kunden laufen halt in der Woche ca. 100 Mails ein. Und da sind dann immer so 2-3 dabei, bei denen es die Umlaute zerhaut.
Wäre das häufiger der Fall, würde ich den Fehler auch an anderer Stelle vermuten - aber ich bin schon mehrfach sämtliche Seiten, Config-Files und Include-Files durchgegangen und habe die Kodierung geprüft.
Und auch egal in welchem Browser und Plattform ich selbst Test-Formulare abschicke, die kommen immer korrekt an.
Nun habe ich eben den Test gemacht, den Browser fest auf UTF-8 zu stellen - und siehe da, die Umlaute werden zerschossen.

Das ist es für mich nach all dem die naheliegendste Vermutung.
Wir werden ja sehen, ob nach der Umstellung mehr oder weniger Mails mit falschen Umlauten ankommen. Zurückstellen und weiter suchen kann man ja dann immer noch
Mit Zitat antworten
  #8 (permalink)  
Alt 25-04-2013, 15:32
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von andik2000 Beitrag anzeigen
Also das Umlaut-Problem berichten mir immer mal wieder drei Kunden, bei denen die Seiten noch in ISO 8859-1 sind.
Im einfachsten Fall haben wir wirklich eine ganz simple Seite mit nem Kontaktformular, wo dahinter die Werte per Mail an den Kunden verschickt werden. Der meldet sich alle halbe Jahre mal, dass er ne Mail mit komischen Zeichen bekommen hat.

Bei nem anderen Kunden laufen halt in der Woche ca. 100 Mails ein. Und da sind dann immer so 2-3 dabei, bei denen es die Umlaute zerhaut.
Wäre das häufiger der Fall, würde ich den Fehler auch an anderer Stelle vermuten - aber ich bin schon mehrfach sämtliche Seiten, Config-Files und Include-Files durchgegangen und habe die Kodierung geprüft.
Und auch egal in welchem Browser und Plattform ich selbst Test-Formulare abschicke, die kommen immer korrekt an.
Nun habe ich eben den Test gemacht, den Browser fest auf UTF-8 zu stellen - und siehe da, die Umlaute werden zerschossen.
Warum machst du nicht einfach das, was ich gesagt habe?
Mit Zitat antworten
  #9 (permalink)  
Alt 25-04-2013, 16:25
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

W3c Validator findet Fehler, die sich aber alle auf schließende Klammern beziehen - /> statt >.
Als Encoding wird ISO 8895-1 erkannt.
Ich habe auch mal in Firebug und HTTP-Fox den Header angeschaut, hier wird aber keine Information zum Encoding genannt.
Einzig "Transfer-Encoding: chunked" wird angezegt.
Mit Zitat antworten
  #10 (permalink)  
Alt 25-04-2013, 16:29
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von andik2000 Beitrag anzeigen
Ich habe auch mal in Firebug und HTTP-Fox den Header angeschaut, hier wird aber keine Information zum Encoding genannt.
Kann ich kaum glauben. Aber selbst wenn es so ist, ist es nicht korrekt. Sende beim HTTP-Header das richtige Encoding, dann weiß der Browser auch, was er nehmen muss ohne zu raten.

PHP-Code:
header('Content-Type: text/html; charset=ISO-8859-1'); 
Zitat:
Zitat von andik2000 Beitrag anzeigen
Einzig "Transfer-Encoding: chunked" wird angezegt.
Das ist sicher nicht der ganze Header.
Mit Zitat antworten
  #11 (permalink)  
Alt 25-04-2013, 16:44
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Ach stimmt, so könnte man das ja fix angeben. Teste ich auch mal aus.

Im Anhang mal, wie der Header im Firebug anhezeigt wird. Das ist 1:1 auch im Http-Fox so.
Miniaturansicht angehängter Grafiken
Browser-Kodierung erkennen und Formular-Werte wandeln-screen1.png  
Mit Zitat antworten
  #12 (permalink)  
Alt 25-04-2013, 16:48
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Der fehlt tatsächlich das Encoding im Header. Sollte man immer angeben.

Was ich aber auch sehe: PHP 5.2.5. Dir ist klar, dass der Server ein Sicherheitsrisiko darstellt, da für diese uralte, tote PHP-Version schon seit Ewigkeiten keine Sicherheits-Update mehr erschienen sind?
Mit Zitat antworten
  #13 (permalink)  
Alt 25-04-2013, 16:57
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Ja, zum Glück sind wir aber nicht fürs Hosting zuständig, das betreut eine andere Agentur
Mit Zitat antworten
  #14 (permalink)  
Alt 25-04-2013, 17:17
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.578
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von andik2000 Beitrag anzeigen
Ja, zum Glück sind wir aber nicht fürs Hosting zuständig, das betreut eine andere Agentur
Seid aber trotzdem davon betroffen. Es liegen ja eure Daten und eure Software am Server, oder?
Mit Zitat antworten
  #15 (permalink)  
Alt 25-04-2013, 17:37
andik2000
 Registrierter Benutzer
Links : Onlinestatus : andik2000 ist offline
Registriert seit: Jan 2002
Beiträge: 810
andik2000 ist zur Zeit noch ein unbeschriebenes Blatt
Standard

Da hast du recht. Habe schon den Hoster informiert, ob da schon ne aktuelle Version vorliegt. Oft kann man das ja sogar übers Konfig-Tool schon direkt umstellen.
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Bestimmte Werte erkennen Kalli1990 PHP Developer Forum 13 27-06-2008 19:50
Werte und Formular überprüfen Dave017 BRAINSTORMING PHP/SQL/HTML/JS/CSS 3 12-02-2006 15:33
Browser erkennen usw. Webbi PHP Developer Forum 5 19-05-2003 15:26
Browser erkennen mit PHP ?? Medialution PHP Developer Forum 2 12-07-2001 13:24
Erkennen der Sprache eines Browser Thomas PHP Developer Forum 1 02-04-2001 10:02

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni

Wissensbestand in Unternehmen
Wissensbestand in UnternehmenLebenslanges Lernen und Weiterbilden sichert Wissensbestand in Unternehmen

25.05.2018 | Berni


 

Aktuelle PHP Scripte

PHP Server Monitor

PHP Server Monitor ist ein Skript, das prüft, ob Ihre Websites und Server betriebsbereit sind.

11.09.2018 Berni | Kategorie: PHP/ Security
PHP WEB STATISTIK ansehen PHP WEB STATISTIK

Die PHP Web Statistik bietet Ihnen ein einfach zu konfigurierendes Script zur Aufzeichnung und grafischen und textuellen Auswertung der Besuchern Ihrer Webseite. Folgende zeitlichen Module sind verfügbar: Jahr, Monat, Tag, Wochentag, Stunde Folgende son

28.08.2018 phpwebstat | Kategorie: PHP/ Counter
Affilinator - Affilinet XML Produktlisten Skript

Die Affilinator Affilinet XML Edition ist ein vollautomatisches Skript zum einlesen und darstellen der Affili.net (Partnerprogramm Netzwerk) Produktlisten und Produktdaten. Im Grunde gibt der Webmaster seine Affilinet PartnerID ein und hat dann unmittelb

27.08.2018 freefrank@ | Kategorie: PHP/ Partnerprogramme
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 01:39 Uhr.