nicht angemeldet
Der Martin
dedlfix
dedlfix
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
dedlfix
Der Martin
Hallo,
$_POST["Site"] enthält Märchen
Habe eben mal folgendes geschrieben:
$StringNeu = mysql_real_escape_string($_POST["Site"]);
echo"$StringNeu ";
$array_1 = array ( 'ä', 'ü', 'ß' );
$array_2 = array ( 'ae', 'ue', 'ss' );
for ( $x = 0; $x < 3; $x++ )
{
$StringNeu = str_replace ( $array_1[$x], $array_2[$x], $StringNeu );
}
echo"$StringNeu";
Ausgabe: Märchen Märchen
gebe ich aber
$StringNeu = mysql_real_escape_string("Märchen");
an ist die Ausgabe: Märchen Maerchen
Woran könnte das liegen?
Gruß Rainer
Hi,
$_POST["Site"] enthält Märchen
in welcher Codierung - also wie ist das 'ä' dargestellt?
$StringNeu = mysql_real_escape_string($_POST["Site"]);
echo"$StringNeu ";
Da sollte der String unverändert ausgegebenwerden. Eine einzelne Stringvariable nochmal in einen String einzubetten, ist aber sinnlos; das wird auch nicht besser, wenn es noch 6391mal gezeigt wird.
$array_1 = array ( 'ä', 'ü', 'ß' );
Auch hier die Frage: In welcher Codierung - also wie sind 'ä','ü','ß' dargestellt?
Ausgabe: Märchen Märchen
Also wird dein POST-Parameter vermutlich in einer anderen Codierung übergeben als die, in der das Script gespeichert ist. POST-Parameter beispielsweise in UTF-8, Script-Codierung vielleicht ISO-8859-1.
gebe ich aber
$StringNeu = mysql_real_escape_string("Märchen");
an ist die Ausgabe: Märchen Maerchen
Genau. Dann ist das 'ä' genau so codiert, wie es das Script auch erwartet.
So long,
Martin
Hallo Martin,
mein Dictype etc.:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>XX</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Wie kann ich denn die Ausgabe von $_POST angeben/ändern?
Gruß Rainer
Hi!
$_POST["Site"] enthält Märchen
In welcher Zeichenkodierung? Und in welcher Kodierung ist dein Script gespeichert?
$array_1 = array ( 'ä', 'ü', 'ß' );
$array_2 = array ( 'ae', 'ue', 'ss' );
for ( $x = 0; $x < 3; $x++ )
{
$StringNeu = str_replace ( $array_1[$x], $array_2[$x], $StringNeu );
}
Du kennst die Funktion strtr() in ihrer zweiten Aufrufversion anscheinend nicht.
gebe ich aber
$StringNeu = mysql_real_escape_string("Märchen");
an ist die Ausgabe: Märchen MaerchenWoran könnte das liegen?
An anderem Code. Generell wird es wohl daran liegen, dass die Zeichenkodierungen nicht übereinstimmen.
Lo!
Hi,
das wäre die Einstellung.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>XX</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Liegt es daran?
Gruß Rainer
Hi!
das wäre die Einstellung.
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Die wird herangezogen, wenn der gleichnamiger HTTP-Header vom Server keine charset-Angabe enthält. Ob der eine sendet, siehst du mit Tools wie der livehttpheaders-Extension für den Firefox.
Liegt es daran?
Das kann ich so nicht sagen, weil du nicht die Kodierung der Script-Datei angegeben hast. Du kannst ja mal das 'ä' im Script mit bin2hex() ausgeben (urlencode() lässt sich auch dafür missbrauchen) und ebenso das betreffende $_POST-Element.
Lo!
Hallo,
Das kann ich so nicht sagen, weil du nicht die Kodierung der Script-Datei angegeben hast.
Affenformular. Was soll ich da _noch_ angeben?
(urlencode()
echo urlencode($_POST["Site"]); gibt aus: M%E4rchen.
Soweit _nicht_ sogut ;-) Wass müsste ich denn nun ändern?
Gruß Rainer
Hi!
Das kann ich so nicht sagen, weil du nicht die Kodierung der Script-Datei angegeben hast.
Affenformular. Was soll ich da _noch_ angeben?
Dein Editor verwendet zum Speichern deiner Scripte welche Kodierung?
(urlencode()
echo urlencode($_POST["Site"]); gibt aus: M%E4rchen.
Soweit _nicht_ sogut ;-) Wass müsste ich denn nun ändern?
Das ist die eine Hälfte und die zeigt, dass der Browser die Formulardaten ISO-8859-1-kodiert gesendet hat, und das ist üblich so, weil die das Formular enthaltende Seite als ISO-8859-1 deklariert ist. Nun fehlt zum vollständigen Vergleich noch die Ausgabe eines im Script notierten
echo urlencode('Märchen');
Lo!
echo urlencode('Märchen');
Ausgabe: M%C3%A4rchen
Also noch was ganz anderes. Verstehe nun überhaupt nichts mehr.
Gruß Rainer
Hi,
echo urlencode('Märchen');
Ausgabe: M%C3%A4rchen
ja, *das* ist nun eindeutig UTF-8. Dein Script ist also in UTF-8 codiert.
Scriptdatei (*.php): in UTF-8 codiert
Falsche Info im HTTP-Header: ISO-8859-1 (vermutlich, hast du aber immer noch nicht verraten)
Ersatzinfo im meta-Element: ISO-8859-1
Dein Browser geht also nach dem Empfang des Dokuments von einer ISO-Codierung aus, also sendet er auch die POST-Daten wieder in ISO. Im Dokument vorkommende Umlaute müssten dann eigentlich auch falsch angezeigt werden - kannst du das bestätigen?
Ciao,
Martin
Hi!
echo urlencode('Märchen');
Ausgabe: M%C3%A4rchen
ja, *das* ist nun eindeutig UTF-8. Dein Script ist also in UTF-8 codiert.
Wie ich vermutet habe.
Scriptdatei (*.php): in UTF-8 codiert
Falsche Info im HTTP-Header: ISO-8859-1 (vermutlich, hast du aber immer noch nicht verraten)
Ersatzinfo im meta-Element: ISO-8859-1
Es gibt keinen direkten Zusammenhang zwischen der Script-Kodierung und der Kodierung der damit erzeugten Ausgabe. Wenn die keine Nicht-ASCII-Zeichen enthält, ist diese sowieso sowohl ISO-8859-irgendwas als auch UTF-8 (und ASCII sowieso). Aber abgesehen von diesem Sonderfall kann man ja mit utf8_decode() aus UTF-8-Daten ISO-8859-1-Daten machen (ggf. mit Datenverlust) und hätte somit eine Kodierung der Seite, die der Angabe in den Kopfdaten entspricht. Nur wenn man direkt im Script notierte Nicht-ASCII-Zeichen direkt ausgibt, kommt es zur Diskrepanz bei der Anzeige im Browser.
Davon unberührt bleibt jedoch das Problem des OP, denn dafür interessieren nur die im Formular eingegebenen Daten und die im Script notierten Vergleichswerte (welche ja nicht zur Ausgabe gelangen sollen).
Dein Browser geht also nach dem Empfang des Dokuments von einer ISO-Codierung aus, also sendet er auch die POST-Daten wieder in ISO. Im Dokument vorkommende Umlaute müssten dann eigentlich auch falsch angezeigt werden - kannst du das bestätigen?
Deine Vermutung im zweiten Satz könnte zutreffen, muss aber nicht.
Lo!
Hallo,
Das kann ich so nicht sagen, weil du nicht die Kodierung der Script-Datei angegeben hast.
Affenformular. Was soll ich da _noch_ angeben?
na, die Textcodierung! Das ist doch hier der wichtige Punkt.
echo urlencode($_POST["Site"]); gibt aus: M%E4rchen.
Okay, das ist eine 1-Byte-Codierung, vermutlich ISO-8859-1. Dann ist wohl das Script selbst (vermutlich!) in UTF-8 codiert. Allerdings hast du dann eine Diskrepanz. Ich zitiere aus deinem anderen Posting:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>XX</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Hier behauptest du, das Dokument sei in ISO-8859-1 codiert - das ist aber anscheinend nicht wahr. Abgesehen davon ist die Angabe hier, wie dedlfix auch schon schrieb, nur eine Ersatzangabe, die dann zum Tragen kommt, wenn diese Information nicht im HTTP-Header übermittelt wird. Also müssten wir weiter fragen: Welche Codierung gibt der Server im HTTP-Header an? Und welche hast du *wirklich* verwendet?
Soweit _nicht_ sogut ;-) Wass müsste ich denn nun ändern?
Du hast ein generelles Problem, weil die Codierung von URL-Parametern nicht wirklich festgelegt ist. Bei manchen Browsern, wie etwa dem IE, lässt sich das in der Konfiguration fest einstellen, andere scheinen sich nach der Codierung des Dokuments zu richten, das den Request auslöst. - Du hast an anderer Stelle "Affenformular" erwähnt; kommt also der POST-Request aus demselben Dokument, das ihn hinterher auch verarbeitet?
Das sicherste ist natürlich, Zeichen außerhalb des ASCII-Bereichs in URL-Parametern zu vermeiden. Aber wahrscheinlich entspannt sich das Problem schon, wenn du alle beteiligten Dokumente einheitlich in *einer* Codierung speicherst, und diese Codierung dann auch korrekt im HTTP-Header angeben lässt.
So long,
Martin
Hi!
echo urlencode($_POST["Site"]); gibt aus: M%E4rchen.
Okay, das ist eine 1-Byte-Codierung, vermutlich ISO-8859-1. Dann ist wohl das Script selbst (vermutlich!) in UTF-8 codiert.
Das kann man daraus nicht erkennen. Man sieht nur, dass die POST-Daten ISO-8859-1-kodiert sind (andere Möglichkeiten lassen wir mal wegen Unwahrscheinlichkeit weg).
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Hier behauptest du, das Dokument sei in ISO-8859-1 codiert - das ist aber anscheinend nicht wahr.
Warum nicht? Für das Problem ist das jedenfalls egal. Eine falsche Angabe hier wirkt sich nur auf die Anzeige von Nicht-ASCII-Zeichen im Browser aus.
Du hast ein generelles Problem, weil die Codierung von URL-Parametern nicht wirklich festgelegt ist.
URL-Parameter haben wir hier nicht, sonder ein per POST gesendetes Formular. Und die unterschiedlichen Kodierungen kommen nur dann zustande, wenn man URLs händisch eingibt. Wenn der Browser aus Formulardaten einen Querystring zusammenbaut, orientiert er sich an der Kodierung der Seite. Aber, wie gesagt, das interessiert bei diesem Problem nicht.
Lo!
Hallo,
echo urlencode($_POST["Site"]); gibt aus: M%E4rchen.
Okay, das ist eine 1-Byte-Codierung, vermutlich ISO-8859-1. Dann ist wohl das Script selbst (vermutlich!) in UTF-8 codiert.
Das kann man daraus nicht erkennen.
nein, aber daraus, dass das ISO-codierte 'ä' NICHT als identisch mit dem im Script notierten 'ä' erkannt wird, kann man zumindest schließen, dass das Script selbst NICHT in ISO-8859-1 vorliegt. UTF-8 habe ich deshalb angenommen, weil es unter diesen Voraussetzungen am wahrscheinlichsten ist.
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Hier behauptest du, das Dokument sei in ISO-8859-1 codiert - das ist aber anscheinend nicht wahr.
Warum nicht?
Siehe oben. Wenn es so wäre, gälte im Script auch ('ä' von außen) == ('ä' im Script).
Du hast ein generelles Problem, weil die Codierung von URL-Parametern nicht wirklich festgelegt ist.
URL-Parameter haben wir hier nicht, sonder ein per POST gesendetes Formular.
Ja, stimmt. POST-Parameter werden aber genauso behandelt und unterliegen den gleichen Regeln. Sie werden nur anders übermittelt, und dadurch entfällt eine eventuelle Längenbeschränkung.
Und die unterschiedlichen Kodierungen kommen nur dann zustande, wenn man URLs händisch eingibt.
Ansonsten verwendet der Browser wohl die Codierung des Dokuments.
Wenn der Browser aus Formulardaten einen Querystring zusammenbaut, orientiert er sich an der Kodierung der Seite. Aber, wie gesagt, das interessiert bei diesem Problem nicht.
Doch, sicher - das ist anscheinend genau das Kernthema dieses Threads.
Ciao,
Martin
Hi!
echo urlencode($_POST["Site"]); gibt aus: M%E4rchen.
Okay, das ist eine 1-Byte-Codierung, vermutlich ISO-8859-1. Dann ist wohl das Script selbst (vermutlich!) in UTF-8 codiert.
Das kann man daraus nicht erkennen.nein, aber daraus, dass das ISO-codierte 'ä' NICHT als identisch mit dem im Script notierten 'ä' erkannt wird, kann man zumindest schließen, dass das Script selbst NICHT in ISO-8859-1 vorliegt. UTF-8 habe ich deshalb angenommen, weil es unter diesen Voraussetzungen am wahrscheinlichsten ist.
OK, als indirekte Folgevermutung kann man das annehmen.
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Hier behauptest du, das Dokument sei in ISO-8859-1 codiert - das ist aber anscheinend nicht wahr.
Warum nicht?
Siehe oben. Wenn es so wäre, gälte im Script auch ('ä' von außen) == ('ä' im Script).
Er hat aber damit nicht behauptet, das Script sei so kodiert, sondern dessen Ausgabe. Die charset-Angabe des Content-Type ist unabhängig von der Kodierung des Erzeugers dieses Contents.
Du hast ein generelles Problem, weil die Codierung von URL-Parametern nicht wirklich festgelegt ist.
URL-Parameter haben wir hier nicht, sonder ein per POST gesendetes Formular.
Ja, stimmt. POST-Parameter werden aber genauso behandelt und unterliegen den gleichen Regeln. Sie werden nur anders übermittelt, und dadurch entfällt eine eventuelle Längenbeschränkung.
POST-Daten setzen in einem üblichen Browser ein Formular voraus. Die kann man nicht einfach ins Blaue hinein in der Adresszeile oder ähnlichem eingeben. Zur Kodierung der POST-Daten wird der Browser immer die Kodierung der Formularseite verwenden (accept-charset mal nicht beachtet). Die von dir erwähnte Nicht-Festlegung betrifft händisch eingegebene URLs. Und das geht aus Prinzip (auf üblichem Weg) mit POST-Daten nicht.
Und die unterschiedlichen Kodierungen kommen nur dann zustande, wenn man URLs händisch eingibt.
Ansonsten verwendet der Browser wohl die Codierung des Dokuments.
Ja.
Wenn der Browser aus Formulardaten einen Querystring zusammenbaut, orientiert er sich an der Kodierung der Seite. Aber, wie gesagt, das interessiert bei diesem Problem nicht.
Doch, sicher - das ist anscheinend genau das Kernthema dieses Threads.
Nein, weil $_POST und nicht $_GET sein Problem ist.
Lo!
Hallo,
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Hier behauptest du, das Dokument sei in ISO-8859-1 codiert - das ist aber anscheinend nicht wahr.
Er hat aber damit nicht behauptet, das Script sei so kodiert, sondern dessen Ausgabe.
das stimmt natürlich - aber ich glaube kaum, dass jemand ein Script mutmaßlich in UTF-8 speichert, dann aber Ausgaben in ISO-8859-1 generieren will. Von daher halte ich die Unterscheidung zwischen "Codierung des Scripts" und "Codierung der Ausgabe eines Scripts" zwar für interessant, aber aher akademisch.
Ja, stimmt. POST-Parameter werden aber genauso behandelt und unterliegen den gleichen Regeln. Sie werden nur anders übermittelt, und dadurch entfällt eine eventuelle Längenbeschränkung.
POST-Daten setzen in einem üblichen Browser ein Formular voraus.
Ja, ich gehe davon aus, dass ein solches vorliegt (davon hat Rainer aber nichts gesagt).
Ansonsten verwendet der Browser wohl die Codierung des Dokuments.
Ja.
Doch, sicher - das ist anscheinend genau das Kernthema dieses Threads.
Nein, weil $_POST und nicht $_GET sein Problem ist.
Nochmal:
Script (vermutlich) in UTF-8
Scriptausgabe (mittlerweile verifiziert) in UTF-8
Angebliche Codierung laut HTTP-Header unbekannt, vermutlich ISO-8859-1
Angebliche Codierung laut meta-Element: ISO-8859-1
POST-Daten werden in ISO-8859-1 versendet
Ergo ist die falsche Angabe der Codierung sehr wohl das Hauptproblem, denn sie führt dazu, dass der Browser auch die POST-Daten in der falschen Codierung verschickt. Oder?
So long,
Martin
Hi!
Ergo ist die falsche Angabe der Codierung sehr wohl das Hauptproblem, denn sie führt dazu, dass der Browser auch die POST-Daten in der falschen Codierung verschickt. Oder?
Grundlegend stimme ich mit dir überein, aber eben nicht in allen Details. Ich weiß nicht, welche Kodierung er verwenden will, darüber hat er nichts konkret verlauten lassen. Ein Indiz, UTF-8 haben zu wollen, wäre, dass er sich fragte, ob seine META-Angabe ISO-8859-1 etwa ein Fehler wäre. Da er aber von der Kodierung im Editor anscheinend nichts wusste und es auch noch nicht Klick machte, dass ISO-8859-1 und UTF-8 was anderes sind und auch andere Bytefolgen verwenden, als er diese charset-Angabe fand, gehe ich eher davon aus, dass er nicht willentlich UTF-8 einsetzt und sein Editor nur per Zufall/Default-Konfiguration/anderer Grund UTF-8 produziert. (Üblicherweise haben sich die Inhaber solcher Problem gar keine Gedanken über Zeichenkodierungen gemacht. Kann man nachholen: http://wiki.selfhtml.org/wiki/Doku:Grundlagen/Zeichenkodierung_und_geschriebene_Sprache.)
Script (vermutlich) in UTF-8
Ja, kann als bestätigt angesehen werden durch: echo urlencode('Märchen'); => Ausgabe: M%C3%A4rchen
Scriptausgabe (mittlerweile verifiziert) in UTF-8
Ist mir da was entgangen? Zu einer Ausgabe von Umlauten (und Fehlern dabei) gab es weder eine Aussage, noch ein belastbares Indiz. Lediglich die Vermutung, dass ein UTF-8-kodiertes Script eine UTF-8-kodierte Ausgabe erzeuge. Es könnten ja auch noch Daten aus einem dritten System, das ISO-8859-1 liefert, unverändert in die Ausgabe durchgereicht worden sein. Aber wie gesagt, das ist alles für das konkrete Problem nicht relevant, weil das weder das Formular noch die Affentechnik noch die zurückgesendeten Daten betrifft.
Ich hoffe, wir haben ihn jetzt nicht verschreckt und er sagt uns noch, was für eine Zeichenkodierung er eigentlich verwenden möchte[*], denn dann kann er auch noch konkrete Tipps bekommen, was zur Fehlerbehebung zu tun ist und was zu tun ist, damit keine weiteren Fehler auftreten. Auch die Information über weitere Datenquellen (Datenbank) wäre dazu wichtig.
[*] Bei "weiß-nicht" und einem Projekt, das noch keinen Alt-Datenbestand hat, wäre die Empfehlung UTF-8.
Lo!
Hallo,
Ist mir da was entgangen? Zu einer Ausgabe von Umlauten (und Fehlern dabei) gab es weder eine Aussage, noch ein belastbares Indiz.
stimmt, ich hatte die geklammerten Bemerkungen in
Script (vermutlich) in UTF-8
und
Scriptausgabe (mittlerweile verifiziert) in UTF-8
verkehrtrum zugeordnet. Es hätte genau andersrum lauten sollen. :-)
Ciao,
Martin
Hallo,
verschreckt habt ihr mich nicht ;-)
2. Es wurde alles mit Notepad++ von mir geschrieben
3. Mein Firefox sagt mir Kodierung: ISO-8859-1
Also, wo sollen denn nun unterrschiedliche Kodierungen in Script uns Ausgabe herkommen?
Gruß Rainer
Hi!
- nur verstehe ich jetzt nur noch "Bahnhof".
Ich nehme also an, du hast dir keine Gedanken über die Zeichenkodierung gemacht. Das solltest du aber tun und dir dazu der Vor- und Nachteile von UTF-8 vs. ISO-8859-1 bewusst werden. Denn erst wenn du dich auf eine Kodierung festgelegt hast und diese überall durchgehend sowohl verwendest als auch richtig deklarierst, werden deine Probleme damit gegen Null gehen. Im Wiki hab ich schonmal angefangen, einige Teile der komplexen Problematik zu beleuchten: http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung. Das Thema Zeichenkodierungen ist übrigens eine Pflichtveranstaltung für Programmierer. Wenn man sich davor drückt, werden einen die Probleme damit früher oder später einholen.
- Es ist ein sogenanntes Affenformular.
Ist nicht weiter von Belang.
- Es wurde alles mit Notepad++ von mir geschrieben
Dem kann man im Menü "Kodierung" einstellen, was man haben will. "ANSI" ist praktisch gleichbedeutend mit Windows-1252, was verwandt ist mit ISO-8859-1. Wenn du dich für UTF-8 entscheidest, dann die Variante ohne BOM (Byte-Order-Mark).
- Mein Firefox sagt mir Kodierung: ISO-8859-1
Genauer wäre es, wenn du mit der livehttpheaders-Extension in der Response in die Zeile Content-Type schautest und dort ob eine charset-Angabe vorhanden ist und wie die lautet. Wenn leer, dann gilt die META-Angabe im Dokument... hier kürze ich mal ab und verweise auf http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung/Webserver.
Also, wo sollen denn nun unterrschiedliche Kodierungen in Script uns Ausgabe herkommen?
Dein Notepad++ wird auf UTF-8 konfiguriert sein. Im Script wirst du ein UTF-8-kodiertes ä haben. (Mindestens) die META-Angabe sagt dem Browser, er möge ein ISO-8859-1-kodiertes Märchen liefern. Das UTF-8-ä ist nicht gleich dem ISO-8859-1-ä, weil PHP nicht die Zeichen vergleicht sondern die Bytewerte der Kodierungen.
Lo!
Hallo Rainer,
verschreckt habt ihr mich nicht ;-)
da bin ich ja beruhigt ...
- Es ist ein sogenanntes Affenformular.
Das ist nur insoweit von Bedeutung, als wir damit wissen, dass nicht ein zweites Script oder Dokument im Spiel ist.
- Es wurde alles mit Notepad++ von mir geschrieben
Auch unerheblich. Wichtig ist nur die Information, dass es in UTF-8 gespeichert wurde.
- Mein Firefox sagt mir Kodierung: ISO-8859-1
Ja, und das passt nicht zur wirklichen Codierung des Scripts. Also musst du diese Angaben korrigieren. Die erste, wichtigere Stelle ist der HTTP-Header. Das ist im Prinzip eine Sache der Serverkonfiguration; aber da du ja sowieso PHP verwendest, kannst du damit die Defaulteinstellungen des Servers übersteuern, indem du den entscheidenden Header mit PHP ausgibst:
header('Content-Type: text/html; charset=UTF-8');
Wichtig ist, dass vor dieser PHP-Anweisung noch keine Ausgabe an den Browser geht, auch keine BOM oder Leerzeile. Diese Anweisung sollte daher ganz am Scriptanfang stehen.
Die zweite Stelle ist deine meta-Angabe, die als Ersatz hergenommen wird, wenn das Dokument nicht per HTTP übertragen wird oder der Server keine Angabe zur Zeichencodierung macht. Dort sollte also genau dasselbe stehen wie in dem obigen Header.
Also, wo sollen denn nun unterrschiedliche Kodierungen in Script uns Ausgabe herkommen?
Gar nicht. Ich gehe nach wie vor davon aus, dass sowohl das Script selbst als auch seine Ausgabe in UTF-8 sind. Aber du (bzw. dein Server) gibst dem Browser eine andere, falsche Information.
Ich hoffe, ich konnte nun wieder etwas Fahrplan an den Bahnhof bringen ...
Ciao,
Martin
Hallo Martin,
verschreckt habt ihr mich nicht ;-)
da bin ich ja beruhigt ...
Ich hoffe, ich konnte nun wieder etwas Fahrplan an den Bahnhof bringen ...
Danke, der Zug ist angekommen, jetzt passt es wenn ich den Header sende. Habe es im xampp (Localhost) und dem Livesystem geprüft.
Gruß Rainer
