Zeichenkodierung

[El Supremo]

Hallo,

ich bin gerade mehr oder weniger zufällig auf die selfhtml-Kategorie "Internationalisierung" gestoßen und habe sie natürlich sofort gelesen - man ist ja schließlich wissensdurstig...
Allerdings weiß ich jetzt zwar einige Dinge mehr als vorher, bin aber auch recht verwirrt. Darum würde ich gerne nachfragen, ob mein bisheriges Verfahren eigentlich sinnvoll ist.

In allen HTML Dateien habe ich bisher immer <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> angegeben, was mir richtig erscheint, da ich in deutscher Sprache schreibe und somit auch Umlaute und das ß vorkommen.
Außerdem ersetze ich Umlaute, Sonderzeichen & Co durch die entsprechenden HTML-Entities. Doch daran zweifle ich jetzt ein wenig: Eigentlich dürfte ich doch alle in ISO 8859-1 definierten Zeichen auch unmaskiert verwenden, oder? Warum aber meldet sich der HTML Validator immer dann zu Wort, wenn ich einen Umlaut mal nicht durch das entsprechende HTML-Entity ersetze?
Das führt mich zum dritten Punkt, an dem ich an meinem bisherigen Vorgehen zweifle. Ich speichere HTML Dokumente (und sonstige Dokumente auch) immer als ANSI. Ist das vielleicht der Grund, weshalb ich auch unter ISO 8859-1 keine Umlaute schreiben darf?

Und nach so vielen Fragen noch eine finale: Sollte ich besser UTF-8 als Zeichenkodierung angeben und als "was" sollte ich das Dokument dann speichern?

Ich hoffe, ihr könnt mir ein wenig aus meiner Verwirrung helfen. Danke schonmal...

Gruß

[Gunnar Bittersmann]

Hello out there!

In allen HTML Dateien habe ich bisher immer <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> angegeben, was mir richtig erscheint, da ich in deutscher Sprache schreibe und somit auch Umlaute und das ß vorkommen.

Nö, da solltest du nicht angeben, was dir richtig erscheint, sondern die Codierung angeben, mit der das Dokument tatsächlich gespeichert wurde.

Außerdem ersetze ich Umlaute, Sonderzeichen & Co durch die entsprechenden HTML-Entities. Doch daran zweifle ich jetzt ein wenig: Eigentlich dürfte ich doch alle in ISO 8859-1 definierten Zeichen auch unmaskiert verwenden, oder?

Ja. Das macht den Quelltext lesbarer und ist die favorisierte Vorgehensweise: “It is almost always preferable to use an encoding that allows you to represent the characters in their normal form, rather than using character entities or NCRs.” [QA-ESCAPES]

Warum aber meldet sich der HTML Validator immer dann zu Wort, wenn ich einen Umlaut mal nicht durch das entsprechende HTML-Entity ersetze?

Welche Codierung gibt dein Webserver im HTTP-Header an? (Firefox: rechte Maustaste, Seiteninformationen anzeigen) Diese Angabe hat Vorrang vor der HTTP-EQUIV-Angabe.

Und nach so vielen Fragen noch eine finale: Sollte ich besser UTF-8 als Zeichenkodierung angeben und als "was" sollte ich das Dokument dann speichern?

Als UTF-8 (könnte auch fälschlicherweise als "Unicode" bezeichnet sein), vorzugsweise ohne BOM. Und natürlich muss der Server dann auch diese Codierung angeben.

Dann kannst du nicht nur deutsche, sondern alle Schriftzeichen im Quelltext verwenden (entsprechende Fähigkeiten des Editors vorausgesetzt), auch richtige Gedankenstriche '–' und Anführungszeichen '„', '“'.

See ya up the road,
Gunnar

[El Supremo]

Hello out there!

Hallo und danke dir für die Antwort!

Nö, da solltest du nicht angeben, was dir richtig erscheint, sondern die Codierung angeben, mit der das Dokument tatsächlich gespeichert wurde.

Oder eben das Dokument in der Kodierung speichern, die ich angegeben habe, richtig?

Ja. Das macht den Quelltext lesbarer und ist die favorisierte Vorgehensweise: “It is almost always preferable to use an encoding that allows you to represent the characters in their normal form, rather than using character entities or NCRs.” [QA-ESCAPES]

Huch, das war mit völlig unbekannt. Ich habe mich die ganze Zeit mit ä, „, ß usw. abgemüht...

Welche Codierung gibt dein Webserver im HTTP-Header an? (Firefox: rechte Maustaste, Seiteninformationen anzeigen) Diese Angabe hat Vorrang vor der HTTP-EQUIV-Angabe.

Hier wirds schwierig. Ist es möglich, dass der Webserver keine Kodierung im HTTP-Header angibt? Denn Firefox zeigt mir immer die Kodierung an, wie ich als HTTP-EQUIV angegeben habe, egal ob das ISO 8859-1 oder UTF-8 ist. Das Dokument war bei meinen Tests allerdings immer als ANSI gespeichert; das kann ich nicht so schnell ändern, da die Seite aus mehreren Include Dateien zusammen gesetzt wird und ich die ja wohl alle ändern müsste. (Kommt dann aber bald noch)

Als UTF-8 (könnte auch fälschlicherweise als "Unicode" bezeichnet sein), vorzugsweise ohne BOM. Und natürlich muss der Server dann auch diese Codierung angeben.

Ok, das werde ich in Zukunft so machen (warum nicht sofort steht ja oben). Hast du noch Lust, mir zu verraten, was "ohne BOM" bewirkt? (Ich machs zwar auch so, aber jetzt sind wir wieder beim "Wissensdurst" angelangt...)

Dann kannst du nicht nur deutsche, sondern alle Schriftzeichen im Quelltext verwenden (entsprechende Fähigkeiten des Editors vorausgesetzt), auch richtige Gedankenstriche '–' und Anführungszeichen '„', '“'.

Das Klingt verlockend. Ich nehme an, dass es nichts ausmacht, wenn ich in älteren Dokumenten weiterhin HTML-Entities verwende? Aber gut, die kann ich eigentlich auch per "Suchen und Ersetzen" recht schnell alle Umwandeln.

See ya up the road,
Gunnar

Danke nochmal,

Gruß, El Supremo

[Gunnar Bittersmann]

Hello out there!

Ist es möglich, dass der Webserver keine Kodierung im HTTP-Header angibt?

Ja. Dann wirkt die HTTP-EQUIV-Angabe im HTML-Dokument.

da die Seite aus mehreren Include Dateien zusammen gesetzt wird und ich die ja wohl alle ändern müsste.

Bei Includes könnte es vorteilhaft sein, tatsächlich nur Basic-Latin-Zeichen (ASCII-Zeichen) zu verwenden, also Umlaute als Entity-Referenz zu notieren. [</archiv/2005/8/t112994/#m717724>]

Ok, das werde ich in Zukunft so machen (warum nicht sofort steht ja oben). Hast du noch Lust, mir zu verraten, was "ohne BOM" bewirkt?

Bessere Verträglichkeit. Bei Include-Dateien Bedingung, da innerhalb eines (zusammengesetzen) Dokuments kein BOM stehen darf.

Ich nehme an, dass es nichts ausmacht, wenn ich in älteren Dokumenten weiterhin HTML-Entities verwende?

Richtige Annahme.

Aber gut, die kann ich eigentlich auch per "Suchen und Ersetzen" recht schnell alle Umwandeln.

Ob der Aufwand lohnt?

See ya up the road,
Gunnar

[El Supremo]

Hallo und das zweite Dankeschön gleich dazu...

Bei Includes könnte es vorteilhaft sein, tatsächlich nur Basic-Latin-Zeichen (ASCII-Zeichen) zu verwenden, also Umlaute als Entity-Referenz zu notieren. [</archiv/2005/8/t112994/#m717724>]

Ja, das klingt eigentlich überzeugend. Das ist es ja eigentlich, was ich im Moment tu. Aber welche Kodierung sollte ich dann zum Speichern dieser Indludes wählen? Mein Editor (Notepad++) bietet mir "nur" ANSI, UTF-8, UTF-8 ohne BOM, UCS-2 Big Endian oder UCS-2 Little Endian an; ASCII wird nicht angeboten. Oder kann ich statt ASCII einfach ANSI wählen, da es unter den ersten Zeichen keinen Unterschied gibt?

Bessere Verträglichkeit. Bei Include-Dateien Bedingung, da innerhalb eines (zusammengesetzen) Dokuments kein BOM stehen darf.

Falls UTF-8, dann ohne BOM, ok, das macht der Artikel deutlich.

Aber gut, die kann ich eigentlich auch per "Suchen und Ersetzen" recht schnell alle Umwandeln.

Ob der Aufwand lohnt?

Ach, ich denke, es ist kein allzu großer Aufwand. Mit Notepad++ kann man in allen geöffneten Dateien zugleich Suchen und Ersetzen. Ich muss eigentlich nur bei &amp; vorsichtig sein, damit es in URIs bestehen bleibt...

Irgendwie stehe ich aber immernoch auf dem Schlauch, was ich nun am besten anstelle. Allgemein rätst du zu UTF-8 (ohne BOM), soweit klar. Aber wie ist es jetzt in Includes? Dort sollte ich nur ASCII Zeichen verwenden, sagst du (also wohl Entities verwenden), aber soll ich dann trotzdem als UTF-8 speichern?

Was spricht denn dagegen, weiterhin ISO 8859-1 zu verwenden, wenn ich das Dokument dann auch in dieser Kodierung speichere? Doch was wäre diese Kodierung? Notepad++ bietet mir wie oben aufgezählt kein ISO an. Sollte ich also zu einem andern Editor greifen?

Tut mir leid, dass ich im Moment etwas auf dem Schlauch stehe, ich denke zwar, aus deinen Antworten einiges gelernt zu haben, aber mir ist die Umsetzung noch etwas unklar...

Guten Start ins Wochenende,

Gruß, El Supremo

[Gunnar Bittersmann]

Hello out there!

Mein Editor (Notepad++) bietet mir "nur" ANSI,

Damit meint er wohl ISO 8859-1; oder evtl. auch windows-1252.

UCS-2 Big Endian oder UCS-2 Little Endian

Damit meint er wohl UTF-16 (BE bzw. LE). [http://de.wikipedia.org/wiki/UTF-16, http://www.unicode.org/faq/basic_q.html#25]

Oder kann ich statt ASCII einfach ANSI wählen, da es unter den ersten Zeichen keinen Unterschied gibt?

So ist es. Die Basic-Latin-Zeichen U+0000 bis U+007F werden in ISO 8859-1, -2, -3, ... und UTF-8 gleich codiert, nämlich als Oktettwerte 00 bis 7F.

Erst danach wird's anders: Die Zeichen U+0080 bis U+00FF werden in ISO 8859-1 als Oktettwerte 80 bis FF codiert; nicht jedoch in ISO 8859-2, -3, ..., da sind repräsentieren einige Oktettwerte andere Zeichen jenseits von Latin-1. In UTF-8 werden die Zeichen U+0080 bis U+00FF als Sequenz zweier Oktettwerte codiert. [http://de.wikipedia.org/wiki/UTF-8]

Allgemein rätst du zu UTF-8 (ohne BOM), soweit klar. Aber wie ist es jetzt in Includes? Dort sollte ich nur ASCII Zeichen verwenden, sagst du (also wohl Entities verwenden),

Wenn du diese Includes sowohl in ISO-8859-1- als auch in UTF-8-codierte Dokumente einfügen möchtest, ja. Hast du hingegen sämtliche Dokumente UTF-8-codiert, kannst du auch die Includes so codieren und in ihnen 'ä' usw. verwenden. Es liegt an dir, zwischen mehr Flexibilität oder etwas besserer Lesbarkeit des Quelltextes der Includes zu wählen.

Dort sollte ich nur ASCII Zeichen verwenden, sagst du (also wohl Entities verwenden), aber soll ich dann trotzdem als UTF-8 speichern?

Egal, s.o.

See ya up the road,
Gunnar

[El Supremo]

Hallo!

Mein Editor (Notepad++) bietet mir "nur" ANSI,

Damit meint er wohl ISO 8859-1; oder evtl. auch windows-1252.

Soll er das doch gleich sagen, böööse Editor...ok, das wäre geklärt.

Allgemein rätst du zu UTF-8 (ohne BOM), soweit klar. Aber wie ist es jetzt in Includes? Dort sollte ich nur ASCII Zeichen verwenden, sagst du (also wohl Entities verwenden),

Wenn du diese Includes sowohl in ISO-8859-1- als auch in UTF-8-codierte Dokumente einfügen möchtest, ja. Hast du hingegen sämtliche Dokumente UTF-8-codiert, kannst du auch die Includes so codieren und in ihnen 'ä' usw. verwenden.

Dann ist die Sache für mich eigentlich klar, ich werde UTF-8 ohne BOM verwenden - überall. Ich hatte sowieso vor, falls ich an der Kodierung etwas ändern sollte, diese Änderung in allen Dateien vor zu nehmen.

Es liegt an dir, zwischen mehr Flexibilität oder etwas besserer Lesbarkeit des Quelltextes der Includes zu wählen.

Dem kann ich nicht so ganz folgen...UTF-8 sollte mir doch sowohl mehr Flexibilität als auch besser lesbaren Quellcode liefern, oder?
Einschnitte bei der Lesbarkeit des Quellcodes dürfte es doch eigentlich nur in Texteditoren geben, die kein UTF-8 kennen. Aber wenn ich mich recht erinnere, hast du selbst in dem von dir oben verlinkten Thread gesagt, User seien nicht dazu da, Quellcode zu lesen - und ich sehe das eigentlich ähnlich.

Auch wenn jetzt alle für mich im Moment relevanten Fragen geklärt wären, habe ich noch eine allgemeine: Wenn ich in einem Dokument ISO 8859-1 als Kodierung angebe und auch nutze (also nicht nur ASCII Zeichen verwende), welche Kodierung muss ich dann in Notepad++ beim Speichern wählen?

Dankbare Grüße, El Supremo

[Gunnar Bittersmann]

Hello out there!

TOP:

Mein Editor (Notepad++) bietet mir "nur" ANSI,

Damit meint er wohl ISO 8859-1; oder evtl. auch windows-1252.

Soll er das doch gleich sagen, böööse Editor...ok, das wäre geklärt.

Ist es das?

Es liegt an dir, zwischen mehr Flexibilität oder etwas besserer Lesbarkeit des Quelltextes der Includes zu wählen.

Dem kann ich nicht so ganz folgen...UTF-8 sollte mir doch sowohl mehr Flexibilität als auch besser lesbaren Quellcode liefern, oder?

Mit mehr Flexibilität meinte ich, dass du mit Includes, in denen nur Baic-Latin-Zeichen auftauchen, flexibler bist; diese kannst du sowohl in ISO-8859-codierte als auch in UTF-8-codierte Dokumente einbauen.

Wenn ich in einem Dokument ISO 8859-1 als Kodierung angebe und auch nutze (also nicht nur ASCII Zeichen verwende), welche Kodierung muss ich dann in Notepad++ beim Speichern wählen?

GOTO TOP

See ya up the road,
Gunnar

[El Supremo]

Hallo!

Es liegt an dir, zwischen mehr Flexibilität oder etwas besserer Lesbarkeit des Quelltextes der Includes zu wählen.

Dem kann ich nicht so ganz folgen...UTF-8 sollte mir doch sowohl mehr Flexibilität als auch besser lesbaren Quellcode liefern, oder?

Mit mehr Flexibilität meinte ich, dass du mit Includes, in denen nur Baic-Latin-Zeichen auftauchen, flexibler bist; diese kannst du sowohl in ISO-8859-codierte als auch in UTF-8-codierte Dokumente einbauen.

Ach _so_ hast du das gemeint...ich hatte gedacht, du beziehst dich darauf, wie viel Flexibilität/Lesbarkeit auf UTF-8 allgemein bietet und nicht auf das, was ich nachher daraus mache (nur ASCII Zeichen oder nicht).

Soll er das doch gleich sagen, böööse Editor...ok, das wäre geklärt.

Ist es das?

Dachte ich zumindest, aber wenn du so fragst, dann habe ich da wohl was verdreht....oder? *schäm und rot werd*

Wenn ich in einem Dokument ISO 8859-1 als Kodierung angebe und auch nutze (also nicht nur ASCII Zeichen verwende), welche Kodierung muss ich dann in Notepad++ beim Speichern wählen?

GOTO TOP

Hm, dass ich den Zusammenhang nicht erkenne muss wohl an dem Denkfehler liegen, den ich oben schon eingeräumt habe, vermutlich gemacht zu haben...

Gruß, El Supremo

[Gunnar Bittersmann]

Hello out there!

Hm, dass ich den Zusammenhang nicht erkenne muss wohl an dem Denkfehler liegen, den ich oben schon eingeräumt habe, vermutlich gemacht zu haben...

Am Anfang von https://forum.selfhtml.org/?t=156477&m=1018399 sagtest du, "das wäre geklärt", dass Notepad++ mit "ANSI" ISO 8859-1 meint; am Ende desselben Postings fragtest du, "welche Kodierung muss ich dann in Notepad++ beim Speichern [eines Dokuments in ISO 8859-1] wählen?"

See ya up the road,
Gunnar

[El Supremo]

Hallo!

Am Anfang von https://forum.selfhtml.org/?t=156477&m=1018399 sagtest du, "das wäre geklärt", dass Notepad++ mit "ANSI" ISO 8859-1 meint; am Ende desselben Postings fragtest du, "welche Kodierung muss ich dann in Notepad++ beim Speichern [eines Dokuments in ISO 8859-1] wählen?"

Huch, da hast du mich erwischt. Ich muss das falsch gelesen oder direkt danach im Kopf verdreht haben; ich hatte gedacht, dass du mir gesagt hättest, ANSI und ASCII wären in dem Fall das Gleiche. Das du da nicht ASCII, sondern ISO 8859-1 geschrieben hast, ist mir völlig entgangen.
Wenn ANSI und ASCII sich aber gleichermaßen zum Speichern von ISO 8859-1 eignen, warum hast du dann in deinem ersten Posting gesagt, ich solle im Dokument nicht die Kodierung angeben, die mir richtig erscheint, sondern die, in der ich es tatsächlich gespeichert habe? Ich hatte ja ISO 8859-1 angegeben und es in ANSI gespeichert. Wenn sich ANSI (da wie ASCII) zum Speichern von ISO 8859-1 eignet, warum sollte ich dann mein Dokument, in dem ich ISO 8859-1 angegeben habe, nicht in ANSI speichern?

Und leider muss ich noch etwas fragen: wie kann ANSI/ASCII denn dazu geeignet sein, ISO 8859-1 mit nicht als Entities notierten Umlauten zu speichern? Dort gibt es doch keine deutschen Umlaute?

Sorry, ich fürchte, ich stelle mich im Moment recht dumm an...

Danke dir für die Geduld, verwirrte Grüße,

El Supremo

[Gunnar Bittersmann]

Hello out there!

Wenn ANSI und ASCII sich aber gleichermaßen zum Speichern von ISO 8859-1 eignen,

He?? Lass dich von deinem Editor nicht verwirren. Denk dir, dort stünde nicht fälschlicherweise "ANSI", sondern "ISO 8859-1" (bzw. "windows-1252", was bis auf den Bereich 80 bis 9F dasselbe ist).

warum hast du dann in deinem ersten Posting gesagt, ich solle im Dokument nicht die Kodierung angeben, die mir richtig erscheint, sondern die, in der ich es tatsächlich gespeichert habe?

Weil deine Formulierung im OP "bisher immer <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> angegeben, was mir richtig erscheint, da ich in deutscher Sprache schreibe und somit auch Umlaute und das ß vorkommen" suggerierte, du würde die Angabe der Zeichencodierung nach dem Dokumentinhalt wählen, nicht nach der beim Speichern verwendeten Codierung.

Ich hatte ja ISO 8859-1 angegeben und es in ANSI gespeichert. Wenn sich ANSI (da wie ASCII) zum Speichern von ISO 8859-1 eignet, warum sollte ich dann mein Dokument, in dem ich ISO 8859-1 angegeben habe, nicht in ANSI speichern?

Ersetze "ANSI" durch "ISO 8859-1" (s.o.) und die Frage erfreut sich ihrer Selbstbeantwortung. ;-)

Und nein, nichts mit "ANSI wie ASCII"; sondern ANSI wie ISO 8859-1.

Und leider muss ich noch etwas fragen: wie kann ANSI/ASCII denn dazu geeignet sein, ISO 8859-1 mit nicht als Entities notierten Umlauten zu speichern? Dort gibt es doch keine deutschen Umlaute?

Dann erfreut sich wohl auch diese Frage ihrer Selbstbeantwortung.

Vergiss ASCII, eine 7-Bit-Codierung ist heutzutage wohl irrelevant. Vielleicht hätte ich ASCII nicht einmal in Klammern erwähnen sollen, sondern nur von "Basic Latin" sprechen. [http://www.unicode.org/charts/]

See ya up the road,
Gunnar

[El Supremo]

Hallo!

He?? Lass dich von deinem Editor nicht verwirren. Denk dir, dort stünde nicht fälschlicherweise "ANSI", sondern "ISO 8859-1" (bzw. "windows-1252", was bis auf den Bereich 80 bis 9F dasselbe ist).

Ah, ich glaube, da ist ein Groschen gefallen...

Weil deine Formulierung im OP "bisher immer <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> angegeben, was mir richtig erscheint, da ich in deutscher Sprache schreibe und somit auch Umlaute und das ß vorkommen" suggerierte, du würde die Angabe der Zeichencodierung nach dem Dokumentinhalt wählen, nicht nach der beim Speichern verwendeten Codierung.

Naja, im Endeffekt hast du mehr oder weniger Recht. Ich hatte die Kodierung, in der gespeichert wird, ja garnicht bewusst gewählt...was mich verwirrt hatte, war, dass du mir anscheinend wiedersprochen hast, obwohl ich es ja (versehentlich) richtig gemacht habe. Aber genau betrachtet hast du mir ja nicht wiedersprochen.

Ersetze "ANSI" durch "ISO 8859-1" (s.o.) und die Frage erfreut sich ihrer Selbstbeantwortung. ;-)

Und nein, nichts mit "ANSI wie ASCII"; sondern ANSI wie ISO 8859-1.

Wäre mir das beides von Anfang an klar gewesen, hätte ich dir viele seltsamme Fragen erspart. ;-)

Vergiss ASCII, eine 7-Bit-Codierung ist heutzutage wohl irrelevant. Vielleicht hätte ich ASCII nicht einmal in Klammern erwähnen sollen, sondern nur von "Basic Latin" sprechen. [http://www.unicode.org/charts/]

Geht klar Chef, schon vergessen. :D

Ich denke, jetzt sind alle Unklarheiten beseitigt. Danke Dir!

Gruß, El Supremo

[El Supremo]

Hallo,

jetzt habe ich zwar schon mehr oder weniger versprochen, das Thema verstanden zu haben, doch jetzt muss ich doch noch eine Frage stellen. Ich hoffe, dass sich dabei nicht herausstellt, dass ich doch nichts verstanden habe...

Wie kommt es denn jetzt, dass sich der Validator beklagt, wenn ich ihm ein Dokument füttere, das Umlaute enthält, welches aber als ISO 8859-1 gespeichert, gesendet und auch im Quellcode so definiert wurde?

Außerdem ist mir noch eine Seltsamheit in Notepad++ aufgefallen: Wenn ich ANSI als Kodierung wähle (was ja fälschlicherweise für ISO dort steht), kann ich zusätzlich UTF-8 ohne BOM auswählen. Wenn ich jedoch UTF-8 wähle, kann ich UTF-8 ohne BOM nichtmehr wählen. Warum kann ich kein UTF-8 ohne BOM speichern und wie soll es funktionieren, dass ich zugleich als "ANSI" (also ISO) und UTF-8 ohne BOM kodieren kann? Das ist doch absolut sinnfrei...?!

Gruß, El Supremo

[Gunnar Bittersmann]

Hello out there!

Wie kommt es denn jetzt, dass sich der Validator beklagt,

Worüber klagt er denn?

wenn ich ihm ein Dokument füttere,

Willst du das Forum auch damit füttern? (Link zur entsprechenden Ressource)

welches aber als ISO 8859-1 gespeichert, gesendet

Trifft vielleicht eines davon doch nicht zu?

Außerdem ist mir noch eine Seltsamheit in Notepad++ aufgefallen: [...] Das ist doch absolut sinnfrei...?!

Ja. Mehr kann ich dir, da ich Notepad++ nicht weiter kenne, dazu nicht sagen.

See ya up the road,
Gunnar

[El Supremo]

Hallo!

Worüber klagt er denn?

Gut, dass du fragst, dadurch ist mir nämlich aufgefallen, dass es einen Unterschied macht, ob ich den Dokumenteninhalt von meinem Rechner aus mit der Methode "post" an http://validator.w3.org/check schicke, oder ob ich es zuerst auf den Webspace hochlade und von dort aus validieren lasse.

Vermutlich gibt es also eigentlich kein Problem und die Fehlermeldung bei der Übertragung per "post" kommt daher, dass dabei eine falsche Kodierung verwendet wird. (Das Forumlar, das den Dokumenteninhalt per "post" an den Validator sendet ist nicht von mir, sondern ein Bestandteil von Notepad++.)

Sprich, ich gehe jetzt einfach mal davon aus, dass die Meldung irrelevant ist, solange sie nicht auftritt, wenn das Dokument vom Server abgerufen und validiert wird.

Aber...jetzt fällt mir auf, die eigentlich Meldung habe ich ja immernoch nicht geschrieben:

Offensichtlich erwartet der Validator UTF-8, obwohl der Dokumenteninhalt ISO 8859-1 ist. Aber wie gesagt, das muss an dem Forumlar liegen und wenn ich das Dokument vom Server ausliefern und dann validieren lasse, ist alles gut.

Willst du das Forum auch damit füttern? (Link zur entsprechenden Ressource)

Na klar, auch wenn ich denke, das das Problem sich inzwischen ja selbst gelöst hat.

http://el-supremos-place.de/sonstiges/umlaute_validieren/index.html

Und so siehts im Editor aus:

Trifft vielleicht eines davon doch nicht zu?

Doch, falls ANSI in diesem Editor ISO 8859-1 entspricht, dann auf jeden Fall (siehe Bild oben).

Außerdem ist mir noch eine Seltsamheit in Notepad++ aufgefallen: [...] Das ist doch absolut sinnfrei...?!

Ja. Mehr kann ich dir, da ich Notepad++ nicht weiter kenne, dazu nicht sagen.

Schade...leider verliere ich langsam etwas an Vertrauen in diesen Editor, obwohl es sich damit eigentlich so angenehm arbeiten lässt...

Und noch eine kleine Frage hätte ich (irgendwie scheinen da immer neue zu kommen...): Sollte ich CSS und JS Dateien in der gleichen Kodierung speichern wie die (S)HTML Datei?

Gruß, El Supremo

[Gunnar Bittersmann]

Hello out there!

Und noch eine kleine Frage hätte ich (irgendwie scheinen da immer neue zu kommen...): Sollte ich CSS und JS Dateien in der gleichen Kodierung speichern wie die (S)HTML Datei?

Nicht notwendigerweise. Wenn diese nur Basic-Latin-Zeichen bis U+007E enthalten, ist es – wie gesagt – sowieso egal. (Die einzigen Stellen, wo in Stylesheets andere Zeichen als Basic-Latin auftreten können, wären wohl Werte der 'content'-Eigenschaft. In JavaScripts wären es Strings, in denen auch andere Zeichen vorkommen können.)

Ansonsten gilt auch hier: Wichtig ist, welche Codierung der Server im HTTP-Header für diese Ressourcen mitschickt (für CSS: [CSS21 §4.4]) Diese kannst du je nach Datei-Extension oder auch für einzelne Dateien auch einstellen (für Apache in .htaccess): siehe </archiv/2007/1/t144561/#m938013>.

See ya up the road,
Gunnar

[El Supremo]

Hallo!

Nicht notwendigerweise. Wenn diese nur Basic-Latin-Zeichen bis U+007E enthalten, ist es – wie gesagt – sowieso egal. (Die einzigen Stellen, wo in Stylesheets andere Zeichen als Basic-Latin auftreten können, wären wohl Werte der 'content'-Eigenschaft. In JavaScripts wären es Strings, in denen auch andere Zeichen vorkommen können.)

Kommentare hast du denke ich vergessen, aber da greife ich sowieso immer auf ae, ue, ss usw. zurück. content verwende ich sowieso nie, da habe ich viel zu viel Angst um den IE...
Aber du hast Recht, dann ist es ja eh egal...

Ansonsten gilt auch hier: Wichtig ist, welche Codierung der Server im HTTP-Header für diese Ressourcen mitschickt [...]

Jop, stimmt eigentlich (wann stimmt es eigentlich mal _nicht_, was du mir sagst?).

So, dann jetzt hoffentlich zum letzten Mal (denn alles andere würde bedeuten, dass es noch weitere Unklarheiten gibt): Vielen Dank für deine Hilfe!

Gruß, El Supremo

[Gunnar Bittersmann]

Hello out there!

Kommentare hast du denke ich vergessen,

Stimmt. Auch Suchmuster (RegExp).

Jop, stimmt eigentlich (wann stimmt es eigentlich mal _nicht_, was du mir sagst?).

:-)

Sag niemals nie!

Das Gute ist: hier sind immer wachsame Augen, die auch mich bei Bedarf korrigieren. Der besteht durchaus mal hin und wieder, so lerne ich auch noch dazu.

Vielen Dank für deine Hilfe!

Nicht dafür.

See ya up the road,
Gunnar