Umlaute März statt März

naomi_watts schrieb:
Für die Verwirrten:
Allgemein ist es wichtig zu begreifen, das es primär auf die richtige Speicherung und die richtige Auslieferung des Dokuments ankommt. Die läßt sich beides nicht über einen Meta-Tag im HTML-Dokument angeben.
Zum Vergrößern anklicken....
UPS? Hä? :p

Was meinst du denn damit? ...verwirrt....
 
Difool schrieb:
UPS? Hä? :p

Was meinst du denn damit? ...verwirrt....
Zum Vergrößern anklicken....

Entscheidend ist nicht der (X)HTML-Header (Datei) sondern der HTTP-Header (Auslieferung Server).
 
maceis schrieb:
Sobald es eine guten Grund dafür gibt, werde ich das in Betracht ziehen. Bis dahin sehe ich keinen Handlungsbedarf.
Zum Vergrößern anklicken....

iso-8859-1 beinhaltet ja nichtmal das Eurozeichen oder den Gedankenstrich …
 
ah, danke naomi :)
 
naomi_watts schrieb:
at maceis:
Sobald du dich mit der Internationalisierung von Websites beschäftigen wirst, wirst du merken was für ein Unsinn es ist länderspezifische Zeichensätze wie iso-8859-1 zu benutzen, da du hier zwei Zeichensätze auf einer Seite nicht mischen kannst.
...
Zum Vergrößern anklicken....
Das mag ab einem gewissen Komplexitätsrad stimmen.
Ich nehme an, Du meinst damit, dass auf einer Seite sowohl deutsche Umlaute als auch kyrilische Schrift und/oder japanische Zeichen vorkommen (oder habe ich Dich jetzt missverstanden?).
Diese Anforderung hatte ich bisher nicht, und es ist fraglich, ob sie in absehbarer Zeit auf mich zukommt ;).

Insofern erwarte ich keine Probleme, wenn ich meine in iso-8859-1 abgespeicherten Dokumente mit dem char-set 8859-1 ausliefere, solange ich keine Zeichen benötige, die in diesem Zeichensatz nicht enthalten sind.

Wenn es um Internationalisierung im west-/mitelleuropäischen und US-amerikanischen Raum geht, kommt man mit iso-8859-1 meiner Erfahrung nach recht weit. Auf Eurozeichen und Gedankenstrich muss man vielleicht verzichten, das ist wahr. Andererseits kann man AFAIK ohnehin nicht sicherstellen, dass diese Zeichen in jedem verwendeteten Zeichensatz verfügbar sind.

Nicht umsonst wird der Zeichensatz iso-8859-1 von Apache (einem international eingesetzten Webserver) als DefaultCharset verwendet.
naomi_watts schrieb:
...
Entscheidend ist nicht der (X)HTML-Header (Datei) sondern der HTTP-Header (Auslieferung Server).
...
Zum Vergrößern anklicken....
Ist es nicht so, dass letztendlich beides entscheiden ist, wenn beides vorhanden ist?

Was nützt es, wenn der Server die in schönstem utf-8 abgespeicherten Dokumente im HTTP Header korrekt als solche bezeichnet ausliefert, der Browser aber durch den meta Tag im HTML Header z.B. auf japanisch umgestellt wird?

Ich lasse mich aber in allen Punkten auch gerne eines Besseren belehren.
Anscheinend kennst Du Dich ja in diesem ganzen Themenbereich recht gut aus;.
 
Was ich mich vor allem Frage, ist, wo bitte im Header Platz für das
verwendete Charset sein soll :confused:
Code: 
HEAD /test_html.html HTTP/1.0

HTTP/1.1 200 OK
Date: Wed, 15 Mar 2006 14:43:23 GMT
Server: Apache/2.2.0 (Unix) PHP/5.1.2
Last-Modified: Wed, 15 Mar 2006 14:42:01 GMT
ETag: "2a7ff3-3b-941ea040"
Accept-Ranges: bytes
Content-Length: 59
Connection: close
Content-Type: text/html
 
Hier:
Code: 
telnet www.gmx.de 80                                       513 
Trying 213.165.64.215...
Connected to www.gmx.de.
Escape character is '^]'.
GET / HTTP/1.1  
Host: www.gmx.de

HTTP/1.1 302 Found
Date: Wed, 15 Mar 2006 17:31:14 GMT
Server: Apache
Location: http://www.gmx.net/de/
Vary: Accept-Encoding
Content-Length: 206
Connection: close
Content-Type: text/html; [b]charset=iso-8859-1[/b]

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://www.gmx.net/de/">here</a>.</p>
</body></html>
Connection closed by foreign host.
Aber wie Du siehst, überträgt nicht jeder Server von Haus aus ein Charset. Der muss halt richtig konfiguriert sein ;).
Das muss man aber idR mittels .htacces Datei selbst erledigen. Woher soll der Hoster auch wissen, in welchem Charset Deine Dateien vorliegen?
 
Ahh, danke :)

Wie genau heißt den die Direktive, in der ich das Charset einstellen
kann?
 
Standardmäßig ist beim Apache iso-8859-1 eingestellt.
Wenn beim Server aber
Code: 
Options AddDefaultCharset Off
konfiguriert ist macht man für iso-8859-1:
Code: 
AddDefaultCharset On
Für andere (hier z.B utf-8)
Code: 
AddDefaultCharset utf-8
Man kann jedes bei der IANA registrierte Charset verwenden.

Das Default Charset wird dann dem Content-Type Header angefügt wenn der Content-Type der Antwort entweder text/plain oder text/html ist. Wie das dann genau ausgewertet wird, hängt allerdings auch vom Client ab.
 
at maceis:

maceis schrieb:
oder habe ich Dich jetzt missverstanden?
Zum Vergrößern anklicken....

Nein, genau so war's gemeint.

maceis schrieb:
Diese Anforderung hatte ich bisher nicht, und es ist fraglich, ob sie in absehbarer Zeit auf mich zukommt ;).
Zum Vergrößern anklicken....

Haushaltsgerät benutzen seit Jahren Unicode/UTF-8 (da dies der Standard-Zeichensatz von Java ist). Ist sehr praktisch in einer globalen Welt. Ich war früher sehr genervt als mein "Apple ][" als "Apple ÜÄ" oder sowas angezeigt wurde.

Die Suchmaschinen sind bereits seit längerem auf Unicode umgestiegen, länderspezifische Zeichensätze sind daher aus meiner Sicht ein Anachronismus. Derartige Voreinstellungen gibt es - richtig bemerkt - nach wie vor. Allerdings gibt es auch genügend Webdesigner/Webdeveloper, die nicht mal wissen wie sie überhaupt nach der einen oder anderen Form speichern oder ob ihr Editor das überhaupt kann.

naomi_watts schrieb:
Entscheidend ist nicht der (X)HTML-Header (Datei) sondern der HTTP-Header (Auslieferung Server).
Zum Vergrößern anklicken....

maceis schrieb:
Ist es nicht so, dass letztendlich beides entscheiden ist, wenn beides vorhanden ist?
Zum Vergrößern anklicken....

Das ist richtig, allerdings gibt es eine Gewichtung. Der Parser schaut nicht erst ins Dokument um dort nachzusehen wie die Kodierung ist. Sondern orientiert sich am HTTP-Header.

Speichert man nun ein Dokument lokal, gibt es beim erneutem Öffnen keinen HTTP-Header, weshalb die zusätzliche Angabe im (X)HTML-Header Sinn macht.

Es gibt noch ein paar weitere Details, aber das dürfte die meisten hier sowieso nicht interessieren.
 
maceis schrieb:
Das Default Charset wird dann dem Content-Type Header angefügt wenn der Content-Type der Antwort entweder text/plain oder text/html ist. Wie das dann genau ausgewertet wird, hängt allerdings auch vom Client ab.
Zum Vergrößern anklicken....

Ich glaube du meinst den MIME-Type. Womit wir dann auch beim Thema code-soup sind. Was hier schon ausgiebig erläutert wurde:
https://www.macuser.de/forum/showthread.php?t=149426
 
Nein, ich meinte das DefaultCharset.
So steht es jedenfalls explizit in der Dokumentation zum Apache.

naomi_watts schrieb:
...
Das ist richtig, allerdings gibt es eine Gewichtung. Der Parser schaut nicht erst ins Dokument um dort nachzusehen wie die Kodierung ist. Sondern orientiert sich am HTTP-Header.
...
Zum Vergrößern anklicken....
Anders als ich bisher angenommen hatte, sollte das Charset im HTTP Header laut Dokumentation auch beim Client höher bewertet erden als die Angabe im meta Tag. Das machen aber anscheinend nicht alle Clients so.
naomi_watts schrieb:
...
Es gibt noch ein paar weitere Details, aber das dürfte die meisten hier sowieso nicht interessieren.
Zum Vergrößern anklicken....
Die meisten vielleicht nicht.
Wenn es nicht zuviel Aufwand ist, würden sie mich aber trotzdem interessieren.

Vielleicht schwing ich ja doch noch irgendwann auf utf-8 um ;).
 
In der aktuellen c't (9/2006) gibt's einen guten Artikel zu
exakt diesem Thema, siehe S. 214.
 
moses_78 schrieb:
In der aktuellen c't (9/2006) gibt's einen guten Artikel zu
exakt diesem Thema, siehe S. 214.
Zum Vergrößern anklicken....

Steht nichts neues drin. Und auf das Thema code-soup wurde gar nicht eingegangen. Es ist auch nicht widersinnig im Quellcode eine Definition zu haben, da nun einmal kein HTTP-Header existiert, falls die Seite zuvor lokal gespeichert wurde. Trotzdem ein guter Grundlagen-Artikel.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten