utf-8 mbstring
0 0 
molily
0 0 0 0 molily
0 utf-8
Gunnar Bittersmann
utf-8 mbstring
liebe Leuts,
Habe Heute eine Seite auf einen KundenServer (wird wohl von Cipero gehostet)hochgeladen.
Alle Seiten sind
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
- und auch als UTF-8 gespeichert.
Die Seiten liefen bislang einwandfrei auf den Servern wo diese erstellt wurden.
Nun - Hier waren jezt alle Umlaute enstellt!!! Allerdings Im IE7 und Safari Win korrekte Darstellung - FF, Opera (PC & Mac) entstellt.
Daraufhin die Dateien versuchsweise mit Ultra-Edit auf ANSI/ASCII umgewandelt (local) und wieder hochgeladen.
Darstellung in allen Browsern jetzt korrekt!!!????
In der info.php nachgeschaut und siehe:
Der mbstring liefert mit hier UTF-8 für den Local & Master Value !!
Alle anderen Server die ich grade sonst noch zur Verfügung haben liefern mir hier ISO-8859-1 für den Local und für den Master kein Value.
Im Augenblick habe ich nur Zugang zum FTP Bereich!
Kappiere nicht warum die Dateien als ANSI laufen???
Will ich die Dateien mit Ultra-Edit via WS-FTP bearbeiten sind diese wieder zerschossen!!
Lade ich die Dateien lokal wieder hoch um die zu bearbeiten - sind die auch zerschossen und egal wie ich diese umwandle in UTF-8 oder ANSI auch.
Also: Sobald ich dort UTF-8 kodierte Dateien hochladen sind die nicht korrekt lesbar. Umgewandelt in ANSI dann doch. Sobald ich die Lokal oder auf dem Server bearbeite wieder geschrottet.
Da brauch ich dann doch Hilfe um das zu verstehen und damit umzugehen....
liebe Grüße
thomas
-
Hi,
Also: Sobald ich dort UTF-8 kodierte Dateien hochladen sind die nicht korrekt lesbar. Umgewandelt in ANSI dann doch.
Dann liefert der Server wohl eine abweichende Charset-Angabe im Content-Type-Header. Dass diese hoehere Prioritaet hat, als eine per Meta im Dokument selber gemachte, sollte ja bekannt sein.
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“-
hi chris,
ja das scheint auch so zu sein - deckt sich zumindest mit dem was Firefox als Zeichenkodierung anzeigt, also immer iso 8859 1, egal was die Meta sagt.IE7 & Safari lesen allerdings die Codierung als UTF-8 (und stören sich auch an den dann auf ANSI zurückformatierten Dateien).
Das ist mir bislang noch nie untergekommen bei einem Server - also neu.
Macht das Sinn die Ausgabe durch die .htaccess zu ändern?? - bzw. gibt es dadurch andere Problem???
Der mbstring hat hier wohl mit der Ausgabe nichts zu tun, weil ja eigentlch nur für die Verarbeitung von UTF-8 Zeichen in Php und Datenbanken zuständig.
Die Sachen so zu lassen - also Doctype mit Meta Utf-8 und Formatierung mit ANSI - is wohl auch Schwachsinn - zumindest lesen (bzw. interpretieren) es die Browser i.A. richtig.
Frage auch: Ist es mit Problemen behaftet den (oder einen) Server von einer definierten CharsetAusgabe wegzubekommen????
Alles obige erklärt mir aber nicht - warum die Dateien auf dem Server nicht korrekt bearbeitet werden können - bzw. beim wieder lokalem Hochladen die Datei zerschossen ist.
Fragen bleiben also.....
liebe Grüße thomas
Hi,
Also: Sobald ich dort UTF-8 kodierte Dateien hochladen sind die nicht korrekt lesbar. Umgewandelt in ANSI dann doch.
Dann liefert der Server wohl eine abweichende Charset-Angabe im Content-Type-Header. Dass diese hoehere Prioritaet hat, als eine per Meta im Dokument selber gemachte, sollte ja bekannt sein.
MfG ChrisB
-
Macht das Sinn die Ausgabe durch die .htaccess zu ändern??
Ja.
bzw. gibt es dadurch andere Problem???
Du musst halt darauf achten, dass alle HTML-Dokumente dann auch entsprechend kodiert sind. Sonst gibts wieder Anzeigefehler.
(Gut, man kann Ausnahmen definieren.)
(Oder man schaltet diese Standard-Kodierungsangabe aus. Keine Kodierungsangabe im HTTP-Header ist aber auch nicht gerade empfehlenswert.)Alles obige erklärt mir aber nicht - warum die Dateien auf dem Server nicht korrekt bearbeitet werden können - bzw. beim wieder lokalem Hochladen die Datei zerschossen ist.
Da musst du dich irren. Du kannst die Dateien mit Sicherheit auf dem Server korrekt bearbeiten. Wie gesagt darfst du dich nicht von der (falschen) Kodierungsangabe des Webservers narren lassen.
Mathias
-
ne, ne mathias,
so blöd bin ich ooch nicht.....
immer wenn ich die Dateien via Ws-Ftp in den Ultra-Edit geladen hatte zum bearbeiten war nach dem Speichern die Datei zerschossen.
Ebenso wenn ich die Datei lokal hochgeladen hatte und mit UE bearbeitet hatte.Und - ob ich die danach in UTF-8 oder ANSI gewandelt hatte machte es nicht besser.
Bearbeiten war mit Editor war nur möglich, wenn ich die Ursprungsdatei (UFF-8 formatiert) vom anderen Server hochgeladen, bearbeitet und in ANSI gewandelt hatte.
Und da hat läuft ja nix via Browser......
Deswegen hab ich's kaum geglaubt das die Charset Angabe via Htacess das Problem auch gelöst hat.....Und im übrigen weiss ich nicht wozu die Maßregelung des Charsets durch den Server???
liebe Grüße thomasMacht das Sinn die Ausgabe durch die .htaccess zu ändern??
Ja.
bzw. gibt es dadurch andere Problem???
Du musst halt darauf achten, dass alle HTML-Dokumente dann auch entsprechend kodiert sind. Sonst gibts wieder Anzeigefehler.
(Gut, man kann Ausnahmen definieren.)
(Oder man schaltet diese Standard-Kodierungsangabe aus. Keine Kodierungsangabe im HTTP-Header ist aber auch nicht gerade empfehlenswert.)Alles obige erklärt mir aber nicht - warum die Dateien auf dem Server nicht korrekt bearbeitet werden können - bzw. beim wieder lokalem Hochladen die Datei zerschossen ist.
Da musst du dich irren. Du kannst die Dateien mit Sicherheit auf dem Server korrekt bearbeiten. Wie gesagt darfst du dich nicht von der (falschen) Kodierungsangabe des Webservers narren lassen.
Mathias
-
immer wenn ich die Dateien via Ws-Ftp in den Ultra-Edit geladen hatte zum bearbeiten war nach dem Speichern die Datei zerschossen.
Wo zerschossen? Beim erneuten Laden in den Editor oder beim Ansehen über HTTP im Browser?
Ebenso wenn ich die Datei lokal hochgeladen hatte und mit UE bearbeitet hatte.
Was ist lokal hochladen?
Und - ob ich die danach in UTF-8 oder ANSI gewandelt hatte machte es nicht besser.
Wieso danach? Wonach? Nach dem Hochladen? Sorry, aber ich verstehe deine Beschreibungen echt nicht.
Bearbeiten war mit Editor war nur möglich, wenn ich die Ursprungsdatei (UFF-8 formatiert) vom anderen Server hochgeladen, bearbeitet und in ANSI gewandelt hatte.
Mir ist schon klar, dass der Webserver ISO-8859-1 als Kodierungsangabe gesendet hatte. Und es ist logisch, dass du das Dokument unter diesen Umständen in ISO-8859-1 (»ANSI«) kodieren musstest, damit der Webbrowser das Dokument angesichts dieser Kodierungsangabe korrekt darstellen konnte.
Ich weiß gerade nicht, wo du da einen Widerspruch oder ein weiteres Problem siehst? Wie gesagt: Webserver sendet Kodierungsangabe > Dokument-Kodierung muss damit übereinstimmen. D.h. wenn der Webserver ISO-8859-1 sendet, musst du deine ursprünglich UTF-8-kodierten Dokumente in ISO-8859-1 rekodieren. Oder eben die Kodierungsangabe ändern.
Deswegen hab ich's kaum geglaubt das die Charset Angabe via Htacess das Problem auch gelöst hat.....
Eine Anweisung für den Webserver hat auf das Editieren, Hochladen usw. überhaupt keinen Einfluss, sondern nur auf das Betrachten von HTML-Dokumenten im Webbrowser über das HTTP-Protokoll.
Und im übrigen weiss ich nicht wozu die Maßregelung des Charsets durch den Server???
Das weiß nur der Serverbetreiber.
Mathias
-
hallo matthias,
inzwischen geschlafen??Wo zerschossen? Beim erneuten Laden in den Editor oder beim Ansehen über HTTP im Browser?
hab ích docch geschrieben: Beim Ansehen im Editor..........
Was ist lokal hochladen?
Lokal soll heißen: Lokal auf meine Festplatte.......
Wieso danach? Wonach? Nach dem Hochladen? Sorry, aber ich verstehe deine Beschreibungen echt nicht.
Genau - nach dem hochladen auf die Festplatte .......
Ich weiß gerade nicht, wo du da einen Widerspruch oder ein weiteres Problem siehst?
Ich hatte mich gefragt: Warum (ohne eine Charset Angabe via Htaccess) die Dateien zerschossen wurden nachdem ich diese Bearbeitet hatte - oder auch nur vom Server wieder auf die Festplatte geladen hatte.
Und vor allem, nach der Charset Angabe via Htaccess ist dieses Problem zwar erledigt - aber kann ich nicht ganz verstehen - weil die Charset Angabe in der Htaccess doch eigentlich nur für die Sichtweise der Browser bestimmt ist???Das weiß nur der Serverbetreiber.
Was aber weiß der Serverbetreiber????
liebe Grüße thomas
-
-
-
-
-
-
In der info.php nachgeschaut und siehe:
Der mbstring liefert mit hier UTF-8 für den Local & Master Value !!Was soll ein PHP-Modul damit zu tun haben?
Kappiere nicht warum die Dateien als ANSI laufen???
Weil der Browser sie als ISO-8859-1 verarbeitet.
Warum verarbeitet der Browser sie als ISO-8859-1?
Höchstwahrscheinlich weil der Webserver eine entsprechende maßgebliche Kodierungangabe sendet.
Wie kannst du herausfinden, welche er sendet? Zum Beispiel mit dem Websniffer, wie gesagt im HTTP-Header »Content-Type«.Diese Servereinstellung kannst du beim Apache z.B. über eine .htaccess-Datei ändern. Die relevanten Anweisungen lauten AddCharset bzw. AddDefaultCharset. Da gibst du jeweils UTF-8 an.
Mathias
-
hallo matthias,
jetze hab ich grad auch Deine Mail gelesen.
Aber wie Du siehst: Ein paar Fragen bleiben noch.Insbesonder die - Wie das Problem mit dem bearbeiten der Dateien auf dem Server (oder wieder runterladen und Lokal bearbeiten) zu lösen ist???
Das wird sich sicher nicht durch die Angaben in der Htaccess ändern.Und - Warum offensichtlich einzele Server maßgebliche Codierangaben senden???????
Grüße thomas
In der info.php nachgeschaut und siehe:
Der mbstring liefert mit hier UTF-8 für den Local & Master Value !!Was soll ein PHP-Modul damit zu tun haben?
Kappiere nicht warum die Dateien als ANSI laufen???
Weil der Browser sie als ISO-8859-1 verarbeitet.
Warum verarbeitet der Browser sie als ISO-8859-1?
Höchstwahrscheinlich weil der Webserver eine entsprechende maßgebliche Kodierungangabe sendet.
Wie kannst du herausfinden, welche er sendet? Zum Beispiel mit dem Websniffer, wie gesagt im HTTP-Header »Content-Type«.Diese Servereinstellung kannst du beim Apache z.B. über eine .htaccess-Datei ändern. Die relevanten Anweisungen lauten AddCharset bzw. AddDefaultCharset. Da gibst du jeweils UTF-8 an.
Mathias
-
Charset Angaben in der Htaccess
lassen auch das korrekte Bearbeiten auf dem Server wieder zu.Fragen bleiben da aber doch und trotzdem......
ahoi thomas
-
Hi,
bitte zitiere mal vernuenftig!
Fragen bleiben da aber doch und trotzdem......
Welche denn?
MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“ -
Charset Angaben in der Htaccess
lassen auch das korrekte Bearbeiten auf dem Server wieder zu.Es gibt und gab nie ein Problem beim Bearbeiten auf dem Server.
Du lädst Dateien in einer Kodierung hoch, und das funktioniert auch. UTF-8, ISO-8859-1, das ist egal, es wird höchstwahrscheinlich klappen.
Wenn du dann aber die Datei über den Webserver aufrufst, muss eben die Kodierungsangabe stimmen, damit der Browser die Datei korrekt lesen kann. Sobald die Angabe mit der tatsächlich von dir beim Editieren/Speichern verwendeten Kodierung übereinstimmt, ist alles in Butter.Mathias
-
-
-
-
@@thomas:
- und auch als UTF-8 gespeichert. […]
Kappiere nicht warum die Dateien als ANSI laufen???
Nochmal zum Nachlesen: FAQ: Änderung der Zeichencodierung einer (X)HTML-Seite auf UTF-8
Live long and prosper,
Gunnar--
Das einzige Mittel, den Irrtum zu vermeiden, ist die Unwissenheit. (Jean-Jacques Rousseau) - und auch als UTF-8 gespeichert. […]