nicht angemeldet
Zeichensatz eines Windows-Arbeitsplatzes
Hello,
bin hier am Verzweifeln. Kollege Chris auch schon.
Wovon hängt die ordnungsgemäße Zeichendarstellung an einem Windows98-Arbeitsplatz mit MSIE 5.5 ab ab? Wieviele Stufen der Manipulation gibt es?
Hat da jemand einen Plan, an welcher Stelle was verbogen wird?
Es handelt sich z.B. um die Seite http://sankt-andreasberg.de/de/index.shtml (nicht unsere Seite), die bei uns auf einem der Geräte leider so <img src="http://bitworks.de/~selfHTML/Zeichensatz.jpg" border="0" alt=""> angezeigt wird.
Unsere eigenen CMS-Seiten werden vernünftig angezeigt http://bitworks.de/~selfHTML/Zeichensatz_Loewen.jpg(92k), allerdings haben wir auch alle Sonderzeichen gegen benannte HTML-Zeichen ersetzt.
Liebe Grüße aus http://www.braunschweig.de
Heute mal vom Chris aus http://Sankt-Andreasberg.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
Hallo,
Ihr müsst im IE bei "Ansicht" --> "Codierung"
dann müsst ihr "WESTEUROPÄISCH (ISO)" wählen!!!mfg
Snoop-
Hello,
Ihr müsst im IE bei "Ansicht" --> "Codierung"
dann müsst ihr "WESTEUROPÄISCH (ISO)" wählen!!!Danke, das war es.
Was ist denn die Standardeinstellung "out of the box" beim MSIE?
Wir haben das sicher mit dem Tool chdoscp.exe verstellt, als wir die Codepage 437 nachgetragen haben.Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Hallo,
Ihr müsst im IE bei "Ansicht" --> "Codierung"
dann müsst ihr "WESTEUROPÄISCH (ISO)" wählen!!!Was ist denn die Standardeinstellung "out of the box" beim MSIE?
Kommt wohl auf die Sprachversion von Windows an. Hier in unserer Gegend sollte er im schlimmsten Fall normalerweise ein Fallback auf die obige Codierung machen.
Aber eigentlich muss eine Webseite ihre Codierung selbst mitschicken, wenn sie es nicht macht, dann hat der Autor versagt. Und sollte keine Codierung kommen, so kann es sein, dass der Browser noch selbst versucht sie zu erraten. (Ich habe hier jedenfalls ein Character-Coding welches ich auf Auto Detect stellen kann, aber was da genau dahintersteckt weiß ich nicht.)
Viele Grüße,
Stefan
-
Hallo,
Ich erlaube ich mir auch noch ein paar Anmerkungen und Ergaenzungen.
Der Fehler liegt hier IMHO eindeutig bei den Leuten von sankt-andreasberg.de:
http://sankt-andreasberg.de/de/index.shtmlDie liefern weder per HTTP
http://cgi.w3.org/cgi-bin/headers?url=http%3A%2F%2Fsankt-andreasberg.de%2Fde%2Findex.shtml
noch im Quelltext (als Meta-Tag)
view-source:http://sankt-andreasberg.de/de/index.shtml
eine Charset-Angabe, was z.B. dazu fuehrt, dass der HTML-Validator
sich weigert, die Seite ueberhaupt anzuschauen:
http://validator.w3.org/check?uri=http%3A%2F%2Fsankt-andreasberg.de%2Fde%2Findex.shtmlAber eigentlich muss eine Webseite ihre Codierung selbst mitschicken, wenn sie es nicht macht, dann hat der Autor versagt.
Genau.
Gemaess der HTML 4.01-Spezifikation sollte jedes Dokument
eine Charset-Angabe haben, entweder vom Webserver her im
HTTP-Header ("staerker") oder im HTML-Quellcode in einem
META-Tag ("schwaecher"), siehe:
http://www.w3.org/TR/html401/charset.html#idx-character_encoding-6
Was XHTML angeht, siehe:
http://www.w3.org/TR/xhtml1/#C_9
http://www.dodabo.de/charset/#xhtml@Kalle:
Bei einer korrekten Charset-Angabe koennen Umlaute (ä, ö, ü)
auch direkt im Quellcode stehen. Die Schreibweise mit
Entities (ä ö ü) ist ueberhaupt nicht
zwingend vorgeschrieben. Siehe:
http://www.dodabo.de/charset/#s2Entities fuer Umlaute sind IMHO nur "notwendig", wenn man mit
untauglichen Werkzeugen arbeitet, welche mit den Charsets
nicht klarkommen (z.B. HTML-Editor, Betriebssystem des Autors
oder des Webservers, FTP-Client und -Server, Webserver ...)Und sollte keine Codierung kommen, so kann es sein, dass der Browser noch selbst versucht sie zu erraten.
Gemaess HTTP/1.1 (RFC 2616) sollte er dann annehmen, dass es ISO-8859-1 ist:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1
"When no explicit charset parameter is provided by the sender,
media subtypes of the "text" type are defined to have a default
charset value of "ISO-8859-1" when received via HTTP."Dies wird wieder aufgehoben in der HTML 4.01 Specification:
http://www.w3.org/TR/html401/charset.html#h-5.2.2
"[...] user agents must not assume any default value for the
'charset' parameter."Fuer _diesen_ Fall, naemlich dass der Autor unfaehig war,
eine Charset-Angabe zu machen, kann man im Browser
manuell ein Charset auswaehlen, das er anwenden soll.
Bei deutschsprachigen Seiten, die auf einem Windows-
Rechner geschrieben wurden, ist dann ISO-8859-1
meist eine brauchbare Loesung.(Ich habe hier jedenfalls ein Character-Coding welches ich auf Auto Detect stellen kann, aber was da genau dahintersteckt weiß ich nicht.)
Was es mit den "Auto Detect" Einstellung von Mozilla auf
sich hat, habe ich auch nicht recht herausgefunden.
Es war bei mir auf "off", und ISO-8859-1 war irgendwie
voreingestellt. Die Seite
http://www.kreml.ru/main.asp
wurde somit zuerst mal kaputt angezeigt, weil sie keine
Charset-Angabe mitliefert. Mit
View -> Character Coding -> Auto-Detect -> Universal
(oder auch Auto-Detect -> Russian) waehlt Mozilla dann
das richtige Charset, naemlich Cyrillic (windows-1251).
Der "Rate-Algorithmus" scheint zu funktionieren ...IMHO sollte automatische Erkennung des _angegebenen_
Charsets die Standard-Einstellung bzw. das Standard-Verhalten
jedes Browser sein. Ein Browser sollte IMHO schauen,
was die Ressource fuer ein Charset angibt (HTTP bzw. Meta)
und sich danach richten.Nur wenn eine Ressource keine Charset-Angabe oder
eine falsche Angabe hat, ist es IMHO ueberhaupt sinnvoll
und z.T. notwendig, im Browser "manuell" ein Charset
auszuwaehlen, um die Sonderzeichen korrekt anzuzeigen.Mit einer fixen Einstellung, z.B. auf ISO-8859-1 (oder mit
nachtraeglicher manueller Auwahl eines Charsets) kann man
natuerlich auch bei Seiten, die ein anderes Charset verwenden
und dieses auch angeben, eine "falsche" Darstellung erhalten,
weil die manuelle Auswahl im Browser eben die korrekte Angabe
der Seite "uebersteuert".Gruesse,
Thomas
--
Bitte keine Mails mit Fachfragen - dafuer gibt es das Forum!
Ich mag es, wenn URLs verlinkt sind (</faq/#Q-19>).
Oft gestellte PHP-Fragen beantwortet die dclp-FAQ bestens: http://www.dclp-faq.de/-
Hello Thomas,
danke, das war schon ein interessanter Ausflug in die Wahrscheinlichkeiten...
Wenn ich jetzt auch noch herausbekommen könnte, was man unter PUNYCODE im Klartext versteht. Da ging es um die leidigen Umlautdomains, die plötzlich jeder (mit Umlaut behaftete) haben will, die aber einfach nicht laufen auf der Mehrzahl der verbreiteten Browser und sich auch nicht anpingen lassen mit den üblichen PING-Programmen.
Aber ich suche noch weiter nach den Ursachen
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
-
-
-
-
-
Hello,
Unsere eigenen CMS-Seiten werden vernünftig angezeigt http://bitworks.de/~selfHTML/Zeichensatz_Loewen.jpg(92k), allerdings haben wir auch alle Sonderzeichen gegen benannte HTML-Zeichen ersetzt.
Irrtum. Bei "Sankt Andreasberg begrüßt ..." finde ich im Quelltext den u-Umlaut und das griechische Beta. Richtig wäre: ü und ß
Und einen Zeichensatz gibt man so an:
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">Liebe Grüße aus Worms, Kalle
-
Hello,
Hello,
Unsere eigenen CMS-Seiten werden vernünftig angezeigt http://bitworks.de/~selfHTML/Zeichensatz_Loewen.jpg(92k), allerdings haben wir auch alle Sonderzeichen gegen benannte HTML-Zeichen ersetzt.
Irrtum. Bei "Sankt Andreasberg begrüßt ..." finde ich im Quelltext den u-Umlaut und das griechische Beta. Richtig wäre: ü und ß
Und einen Zeichensatz gibt man so an:
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">Hallo Kalle,
das sind ja auch nicht unsere Seiten. Steht doch eindeutig dahinter. Aber genau diese Seiten wurden vernünftig angezeigt, bevor wir angefangen haben, dem Windows-Arbeitsplatz auch in der DOS-Box die Umlaute beizubringen. Wir haben Codepage 437 hinzugefügt, sind aber inzwischen schon wieder auf Codepage 850, was abe im Browser auch keine Besserung bringt.
Liegt der Mangel nun in der Seite von sankt-andreasberg.de oder liegt er im Arbeitsplatz? Was machen Windows & Co. denn sonst, wenn es "trotzdem" funktioniert?
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen-
Hallo, Tom,
das sind ja auch nicht unsere Seiten. Steht doch eindeutig dahinter.
OK, habe ich übersehen.
Aber genau diese Seiten wurden vernünftig angezeigt,
bei mir auch, liegt daran, dass im Browser "zufällig" der richtige Zeichensatz eingestellt ist.
bevor wir angefangen haben, dem Windows-Arbeitsplatz auch in der DOS-Box die Umlaute beizubringen. Wir haben Codepage 437 hinzugefügt, sind aber inzwischen schon wieder auf Codepage 850, was abe im Browser auch keine Besserung bringt.
Ich habe DOS- und Windows- Umlaute bisher immer für unvereinbar gehalten. Aber wieso beeinflußt die DOS-Box die Windowsanzeige?
Liegt der Mangel nun in der Seite von sankt-andreasberg.de oder liegt er im Arbeitsplatz?
An der Andreasberg-Seite. Einerseits wollen die weltweit (WEB !!!) erreichbar sein, aber schon ein paar hundert Kilometer von uns gibt es User mit griechischem, türkischem, kyrillischem Zeichensatz.
Was machen Windows & Co. denn sonst, wenn es "trotzdem" funktioniert?
Es funktioniert eben nur zufällig, wenn der WEB- Designer und der Besucher dieselbe Schrift- Grundeinstellung haben.
-
-
Hallo,
Irrtum. Bei "Sankt Andreasberg begrüßt ..." finde ich im Quelltext den u-Umlaut und das griechische Beta. Richtig wäre: ü und ß
Wenn der Zeichensatz bei dieser Seite korrekt mitgeschickt würde, dann wären "ü" und "ß" (anstelle von "ü" und "ß") schon okay (und IMHO auch besser, weil kürzer und im Quelltext einfacher zu lesen etc.).
Und einen Zeichensatz gibt man so an:
<meta http-equiv="content-type" content="text/html;charset=ISO-8859-1">Richtig, wobei dies IMHO nur die zweitbeste Lösung ist. Noch besser wäre es, zusätzlich im HTTP-header unter Content-Type den verwendeten Zeichensatz anzugeben (das muss man am Server einstellen). Die meta-Angabe würde ich aber trotzdem stehenlassen, denn beim lokalen Bearbeiten der Dateien kann der Editor/Browser so auch den benutzten Zeichensatz herausfinden (in diesem Fall wird ja kein HTTP-header mitgeschickt).
Grüße, Alex.
-