HTML-Zeichenreferenz
2 
dedlfix
0 0 Take
0 dedlfix
0 
Gunnar Bittersmann
0 Gunnar Bittersmann
0 dedlfix
HTML-Zeichenreferenz
Ich will ein paar polnische Ortsnamen korrekt schreiben. Dafür brauche ich ein paar Buchstaben, die ich in der Tabelle mit den benannten Zeichen für die Kodierung ISO 8859-1 natürlich nicht finden kann. Wo finde ich entsprechende Tabellen für die benannten Zeichen nach anderen Kodierungen - genauer gesagt: mit polnischen Buchstaben?
-
Hi!
Ich will ein paar polnische Ortsnamen korrekt schreiben. Dafür brauche ich ein paar Buchstaben, die ich in der Tabelle mit den benannten Zeichen für die Kodierung ISO 8859-1 natürlich nicht finden kann. Wo finde ich entsprechende Tabellen für die benannten Zeichen nach anderen Kodierungen - genauer gesagt: mit polnischen Buchstaben?
Die gibt es nur für HTML5. Inwieweit dafür die Browserunterstützung fortgeschritten ist, entzieht sich meiner Kenntnis. Auf der sichren Seite helfen dir nur NCRs (numeric character references), also die Zahlenschreibweise.
Aber warum so umständlich? Nimm UTF-8 als Kodierung, damit kannst du nahezu alle Zeichen dieser Welt direkt verwenden und brauchst keine Ersatzschreibweise. Ansonsten muss du dir sowieso die Unicode-Codepoint-Nummer des jeweiligen Zeichens suchen, die du dann in der Hex- oder Dezimalschreibweise als NCR angeben musst. Suche nach "Unicode Charts".
Lo!
-
Hi!
Ich will ein paar polnische Ortsnamen korrekt schreiben. Dafür brauche ich ein paar Buchstaben, die ich in der Tabelle mit den benannten Zeichen für die Kodierung ISO 8859-1 natürlich nicht finden kann. Wo finde ich entsprechende Tabellen für die benannten Zeichen nach anderen Kodierungen - genauer gesagt: mit polnischen Buchstaben?
Die gibt es nur für HTML5. Inwieweit dafür die Browserunterstützung fortgeschritten ist, entzieht sich meiner Kenntnis. Auf der sichren Seite helfen dir nur NCRs (numeric character references), also die Zahlenschreibweise.
Aber warum so umständlich? Nimm UTF-8 als Kodierung, damit kannst du nahezu alle Zeichen dieser Welt direkt verwenden und brauchst keine Ersatzschreibweise. Ansonsten muss du dir sowieso die Unicode-Codepoint-Nummer des jeweiligen Zeichens suchen, die du dann in der Hex- oder Dezimalschreibweise als NCR angeben musst. Suche nach "Unicode Charts".
Lo!
Ich gebe zu, ich bin Anfänger. Ich habe keinen Überblick über die ganzen Kodierungen. Ich weiss weder, was ich da alles beachten muss, noch, was ich dabei alles falsch machen kann. Ich möchte die benannten Zeichen verwenden, um selbst den Überblick nicht zu verlieren, solange ich mich noch nicht besser auskenne.
-
Moin,
Ich gebe zu, ich bin Anfänger. Ich habe keinen Überblick über die ganzen Kodierungen. Ich weiss weder, was ich da alles beachten muss, noch, was ich dabei alles falsch machen kann. Ich möchte die benannten Zeichen verwenden, um selbst den Überblick nicht zu verlieren, solange ich mich noch nicht besser auskenne.
Benutze einen Editor der UTF-8 kann und speichere dein Dokument als UTF-8. Lass dann entweder vom Server im HTTP-Header UTF als charset angeben, oder benutze im <head>:
<meta http-equiv="content-type" content="text/html; charset=utf-8">(einfacher). Dann brauchst du weder irgendwelche Etinities noch sonstwas. Alles was du noch als Etinity schreiben musst ist logischerweise "&" -> & "<" -> < ">" -> > """ -> ".Gruß,
Take-
Lass dann entweder vom Server im HTTP-Header UTF als charset angeben, oder benutze im <head>:
<meta http-equiv="content-type" content="text/html; charset=utf-8">(einfacher).Das sind keine alternativen Möglichkeiten! Wenn der Server ISO-8859-1 sagt, gilt das, unabhängig davon, was du irgendwie in den Seitenquelltext schreibst. Also sorge dafür, dass der Server utf-8 angibt.
-
Lass dann entweder vom Server im HTTP-Header UTF als charset angeben, oder benutze im <head>:
<meta http-equiv="content-type" content="text/html; charset=utf-8">(einfacher).Das sind keine alternativen Möglichkeiten! Wenn der Server ISO-8859-1 sagt, gilt das, unabhängig davon, was du irgendwie in den Seitenquelltext schreibst.
Bis hierhin OK.
Also sorge dafür, dass der Server utf-8 angibt.
Nicht OK. Das bedarf einer differenzierteren Herangehensweise.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Also sorge dafür, dass der Server utf-8 angibt.
Nicht OK. Das bedarf einer differenzierteren Herangehensweise.Ich hab da mal was vorbereitet: SELFHTML-Wiki Themen:Zeichencodierung - Abschitte Webdokumente und Webserver.
Lo!
-
Also sorge dafür, dass der Server utf-8 angibt.
Nicht OK. Das bedarf einer differenzierteren Herangehensweise.Ich hab da mal was vorbereitet: SELFHTML-Wiki Themen:Zeichencodierung - Abschitte Webdokumente und Webserver.
Konztrolliere in http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung/Webdokumente doch noch die Gross-Kleinschreibung in Bezug auf Content-type:
Wildwuchs könnte Anlass für Verwirrung werden.Ein Gedanke für mehr Differenzierung war mir:
Setze auf dem Server nur dann in .htaccess eine Encoding-Angabe, wenn du auch das Encoding aller Ressourcen definieren kannst.
Ansonsten definiere das Encoding per Ressource, entweder indem die Ressource selbst den HTTP-header schreibt, oder die der Inhaltssprache gemässen Möglichkeiten nutzt.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hi!
Konztrolliere in http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung/Webdokumente doch noch die Gross-Kleinschreibung in Bezug auf Content-type: Wildwuchs könnte Anlass für Verwirrung werden.
Höchstens beim Leser. Gemäß RFC2616 (HTTP 1.1) ist "Content-Type" zwar die dort verwendete Schreibweise, jedoch ist dieser Wert case-insensitive.
Lo!
-
-
-
-
-
-
Hi!
Ich gebe zu, ich bin Anfänger. Ich habe keinen Überblick über die ganzen Kodierungen.
Das lässt sich ändern: http://wiki.selfhtml.org/wiki/Doku:Grundlagen/Zeichenkodierung_und_geschriebene_Sprache
Ich möchte die benannten Zeichen verwenden, um selbst den Überblick nicht zu verlieren, solange ich mich noch nicht besser auskenne.
Es gibt praktisch keine für die polnischen Nicht-ASCII/-ISO-8859-1-Zeichen. Nur die Unicode-Zahlen, und die erhöhen den Überblick nun nicht gerade. Die Zeichen direkt zu verwenden, stört noch nicht mal den Lesefluss in der Codeansicht.
Lo!
-
@@dedlfix:
nuqneH
Das lässt sich ändern: http://wiki.selfhtml.org/wiki/Doku:Grundlagen/Zeichenkodierung_und_geschriebene_Sprache
Autsch, was muss man da lesen: „Bei 1-Byte-Codierungen (für Zeichensätze mit bis zu 256 Zeichen) spielt die Unterscheidung zwischen Zeichensatz und Zeichencodierung keine praktische Rolle.“
Das ist Unsinn. Aber wie du sagtest: Das lässt sich ändern.
„Der Zeichensatz für HTML-Dokumente ist seit Version 4.0 stets Unicode.“
Eben. Aber „[d]as bedeutet nicht, dass alle HTML- und XML-Dokumente als Unicode codiert werden müssen […]“ [DOC-CHARSET] Auch bei einem ISO-8859-1-codierten HTML-4-Dokument ist der Zeichensatz Unicode.
Die Unterscheidung zwischen Zeichensatz und Zeichencodierung spielt immer eine Rolle.
Es gibt praktisch keine für die polnischen Nicht-ASCII/-ISO-8859-1-Zeichen.
Was denn nun: Nicht-ASCII oder Nicht-ISO-8859-1? Wenn erstes:
óQapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Hi!
Das lässt sich ändern: http://wiki.selfhtml.org/wiki/Doku:Grundlagen/Zeichenkodierung_und_geschriebene_Sprache
Autsch, was muss man da lesen: „Bei 1-Byte-Codierungen (für Zeichensätze mit bis zu 256 Zeichen) spielt die Unterscheidung zwischen Zeichensatz und Zeichencodierung keine praktische Rolle.“
Das ist Unsinn. Aber wie du sagtest: Das lässt sich ändern.Wenn du jetzt noch erklärst, wie es deiner Meinung nach richtig wäre, denn ich wüsste jetzt nicht, welcher praktischen Nutzen sich an der Stelle von einer Unterscheidung ergibt.
„Der Zeichensatz für HTML-Dokumente ist seit Version 4.0 stets Unicode.“
Eben. Aber „[d]as bedeutet nicht, dass alle HTML- und XML-Dokumente als Unicode codiert werden müssen […]“ [DOC-CHARSET] Auch bei einem ISO-8859-1-codierten HTML-4-Dokument ist der Zeichensatz Unicode.
Die Unterscheidung zwischen Zeichensatz und Zeichencodierung spielt immer eine Rolle.Und was genau bemängelst du jetzt am Wiki-Text? Nach dem zitierten Satz geht es ja noch weiter. Vielleicht kommt durch dessen Formulierung das Ansinnen nicht richtig rüber, aber ich sehe da jetzt nicht, welchen inhaltlichen Handlungsbedarf du da genau siehst.
Ich finde ja übrigens "als Unicode codiert" nicht richtig. Unicode ist keine Kodierung sondern ein Zeichensatz. Aber das W3-Dokument ist nicht meine Baustelle.
Es gibt praktisch keine für die polnischen Nicht-ASCII/-ISO-8859-1-Zeichen.
Was denn nun: Nicht-ASCII oder Nicht-ISO-8859-1? Wenn erstes: óDas eine Zeichen (oder wieviele es nun genau sind) macht das Kraut auch nicht fett. Wenn man das Vorhaben mit ISO-8859-1 als Kodierung der Seite(n) umsetzen will, kommt man so oder so an den NCRs nicht vorbei. Aber dieser Aspekt der Diskussion bringt niemanden so richtig weiter. Es wäre wichtiger, zu klären ob es triftige Gründe gibt, die gegen eine Umstellung des Projekts auf UTF-8 sprechen.
Lo!
-
Es gibt praktisch keine für die polnischen Nicht-ASCII/-ISO-8859-1-Zeichen.
Was denn nun: Nicht-ASCII oder Nicht-ISO-8859-1? Wenn erstes: óDas eine Zeichen (oder wieviele es nun genau sind) macht das Kraut auch nicht fett. Wenn man das Vorhaben mit ISO-8859-1 als Kodierung der Seite(n) umsetzen will, kommt man so oder so an den NCRs nicht vorbei. Aber dieser Aspekt der Diskussion bringt niemanden so richtig weiter. Es wäre wichtiger, zu klären ob es triftige Gründe gibt, die gegen eine Umstellung des Projekts auf UTF-8 sprechen.
Lo!
Ave allerseits!
Das Projekt ist ein Beleg für die Uni und ich weiss nicht, ob meine 67-jährige Professorin es gut heißt, wenn ich ihre Empfehlung, Schreibweisen wie "ó" zu benutzen, ignoriere.
Abgesehen davon brauch ich nicht das "o" mit Strich drüber, sondern das "e" mit Haken drunter...
Irgendwelche Ideen?LG
-
Hi!
Das Projekt ist ein Beleg für die Uni und ich weiss nicht, ob meine 67-jährige Professorin es gut heißt, wenn ich ihre Empfehlung, Schreibweisen wie "ó" zu benutzen, ignoriere.
Abgesehen davon brauch ich nicht das "o" mit Strich drüber, sondern das "e" mit Haken drunter...Striche gibt es viele. Sag doch bitte gleich, dass du das Ogonek meinst.
Irgendwelche Ideen?
Ich kann mich nur wiederholen:
Es gibt praktisch keine für die polnischen Nicht-ASCII/-ISO-8859-1-Zeichen.
Erst ab HTML5, wird es mehr als die in ISO-8859-1 enthaltenen benannten Zeichen geben. Eim Falle des Ęę sind das Ę und ę Derzeit kann von den von mir getesteten Browser IE8, Fx3.6.11, Opera 10.63 und Chrome 6 und 7 lediglich letzterer mit diesen beiden Named character references etwas anfangen. Wenn du jetzt bitte endlich einsehen würdest, dass die benannten Zeichen dir nicht viel nützen ...
Wenn du unbedingt auf dem unpassenden ISO-8859-1 beharren willst, findest du in der englischen Wikipedia die Alternativen, die in einem großen Teil der aktuellen Browsern nutzbar sind:
http://en.wikipedia.org/wiki/Polish_language#OrthographyLo!
-
Wenn du unbedingt auf dem unpassenden ISO-8859-1 beharren willst, findest du in der englischen Wikipedia die Alternativen, die in einem großen Teil der aktuellen Browsern nutzbar sind:
http://en.wikipedia.org/wiki/Polish_language#OrthographySalut!
Endlich mal 'ne aussagekräftige Tabelle!
Genau sowas habe ich gesucht.
Herzlichen Dank!!! :-)LG
-
-
@@Sternchen96:
nuqneH
Das Projekt ist ein Beleg für die Uni und ich weiss nicht, ob meine 67-jährige Professorin es gut heißt, wenn ich ihre Empfehlung, Schreibweisen wie "ó" zu benutzen, ignoriere.
Wenn sie mit ihren 67 noch an der Uni lehrt, sollte sie geistig noch so fit sein zu verstehen, wann keine Escapes zu verwenden sind.
Das dort für Tschechisch gebrachte Beispiel gilt auch für Polnisch (auch wenn im Polnischen nicht ganz so häufig diakritische Zeichen verwendet werden wie im Tschechischen).
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
@@dedlfix:
nuqneH
Autsch, was muss man da lesen: „Bei 1-Byte-Codierungen (für Zeichensätze mit bis zu 256 Zeichen) spielt die Unterscheidung zwischen Zeichensatz und Zeichencodierung keine praktische Rolle.“
Wenn du jetzt noch erklärst, wie es deiner Meinung nach richtig wäreDen Satz streichen.
denn ich wüsste jetzt nicht, welcher praktischen Nutzen sich an der Stelle von einer Unterscheidung ergibt.
Die Nichtunterscheidung ist einfach falsch. Das hieße ja, der Zeichensatz eines ISO-8859-1-codierten Dokuments wäre zwangläufig nur Basic Latin plus Latin-1 Supplement. Dem ist aber nicht so, wenn ein Escape-Mechanismus zur Verfügung steht.
So lässt sich bspw. das Zeichen 'ą' in einem ISO-8859-1-codierten HTML-4.01-Dokument durch die Bytefolge 26 23 78 31 30 35 3B codieren.
Und was genau bemängelst du jetzt am Wiki-Text?
Dass erst etwas falsch gesagt wird, was dann berichtigt wird.
Ich finde ja übrigens "als Unicode codiert" nicht richtig. Unicode ist keine Kodierung sondern ein Zeichensatz.
Ja, das ist etwas grenzwertig. Zumindest heit es „_als_ Unicode“, nicht „_in_ Unicode“. Das sollte als „in einer Unicode-Codierung“ („in einer der Unicode-Codierungen“) verstanden werden.
Wenn ich mich recht entsinne, hatte ich überlegt, in der Übersetzung „in einer Unicode-Codierung“ zu schreiben. Die Frage ist: Wie weit sollte man als Übersetzer gehen? Man ist ja nur Übersetzer, kein Co-Autor.
ó
Das eine Zeichen (oder wieviele es nun genau sind)Zwei. Ó auch. ;-)
Es wäre wichtiger, zu klären ob es triftige Gründe gibt, die gegen eine Umstellung des Projekts auf UTF-8 sprechen.
Wenn die Antwort darauf ja ist, sollte überlegen, ob die Gründe wirklich triftig sind.
Wenn die Antwort darauf ja ist, sollte man zum vorigen Schritt zurückgehen.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Hi!
denn ich wüsste jetzt nicht, welcher praktischen Nutzen sich an der Stelle von einer Unterscheidung ergibt.
Die Nichtunterscheidung ist einfach falsch. Das hieße ja, der Zeichensatz eines ISO-8859-1-codierten Dokuments wäre zwangläufig nur Basic Latin plus Latin-1 Supplement. Dem ist aber nicht so, wenn ein Escape-Mechanismus zur Verfügung steht.Dann werde ich den Kontext klarer stellen, dass es mir an der Stelle nur um Dokumente ohne Escape-Mechanismus geht, reinen Text beispielsweise. Ich will ja den Leser auch da abholen, wo er ist. Der unterscheidet noch nicht, weil er das bei reinem Text nicht musste. Und nun kommt HTML und da ist es anders.
Welche Systeme (außer den HTML-verwandten) sind denn in dieser Hinsicht so ähnlich wie HTML aufgebaut, haben also einen universellen Zeichensatz zuzüglich verschiedener Kodierungsvarianten nebst Escaping-Mechanismus?
Lo!
-
@@dedlfix:
nuqneH
Dann werde ich den Kontext klarer stellen, dass es mir an der Stelle nur um Dokumente ohne Escape-Mechanismus geht, reinen Text beispielsweise. Ich will ja den Leser auch da abholen, wo er ist. Der unterscheidet noch nicht, weil er das bei reinem Text nicht musste. Und nun kommt HTML und da ist es anders.
Ich sehe keinen Sinn darin, dem Leser den Floh ins Ohr zu setzen, man müsse unter bestimmten Gegebenheiten nicht zwischen Zeichensatz und Zeichencodierung unterscheiden.
Besser wäre es IMHO klarzumachen, dass zwischen beidem immer unterschieden werden sollte.
Welche Systeme (außer den HTML-verwandten) sind denn in dieser Hinsicht so ähnlich wie HTML aufgebaut, haben also einen universellen Zeichensatz zuzüglich verschiedener Kodierungsvarianten nebst Escaping-Mechanismus?
CSS, JavaScript, …
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Hi!
Dann werde ich den Kontext klarer stellen, dass es mir an der Stelle nur um Dokumente ohne Escape-Mechanismus geht, reinen Text beispielsweise. Ich will ja den Leser auch da abholen, wo er ist. Der unterscheidet noch nicht, weil er das bei reinem Text nicht musste. Und nun kommt HTML und da ist es anders.
Ich sehe keinen Sinn darin, dem Leser den Floh ins Ohr zu setzen, man müsse unter bestimmten Gegebenheiten nicht zwischen Zeichensatz und Zeichencodierung unterscheiden.Der ist doch schon drin. Ich will ihn nur sichtbar machen.
Besser wäre es IMHO klarzumachen, dass zwischen beidem immer unterschieden werden sollte.
Und ihm dann sagen, dass er doch wichtig ist.
Welche Systeme (außer den HTML-verwandten) sind denn in dieser Hinsicht so ähnlich wie HTML aufgebaut, haben also einen universellen Zeichensatz zuzüglich verschiedener Kodierungsvarianten nebst Escaping-Mechanismus?
CSS, JavaScript, …Danke für die beiden Stichwörter, dazu fehlen noch Abschitte in http://wiki.selfhtml.org/wiki/Themen:Zeichencodierung/Webdokumente. Wobei mir der CSS-Mechanismus bis eben nicht bekannt war. Der ist ja auch nochmal etwas tricky, wenn das CSS im HTML steht (style-Element und -attribute).
Lo!
-
@@dedlfix:
nuqneH
Ich sehe keinen Sinn darin, dem Leser den Floh ins Ohr zu setzen, man müsse unter bestimmten Gegebenheiten nicht zwischen Zeichensatz und Zeichencodierung unterscheiden.
Der ist doch schon drin. Ich will ihn nur sichtbar machen.
Nimmt ihn raus! Juckt doch keinen. ;-)
Lass ihn unsichtbar! Keine schlafenden Hunde wecken! Flohhalsband anlegen!
Wobei mir der CSS-Mechanismus bis eben nicht bekannt war.
Das Original des Artikels [ESCAPES] wurde letztens um Abschnitte zu CSS-Escapes ergänzt, die deutsche Übersetzung noch nicht, ist aber in Arbeit.
Der ist ja auch nochmal etwas tricky, wenn das CSS im HTML steht (style-Element und -attribute).
Siehe CSS-Escapes und Verwendung von Escapes in style-Attributen.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Hi!
Ich sehe keinen Sinn darin, dem Leser den Floh ins Ohr zu setzen, man müsse unter bestimmten Gegebenheiten nicht zwischen Zeichensatz und Zeichencodierung unterscheiden.
Der ist doch schon drin. Ich will ihn nur sichtbar machen.
Nimmt ihn raus! Juckt doch keinen. ;-)
Lass ihn unsichtbar! Keine schlafenden Hunde wecken! Flohhalsband anlegen!Es wird dir sicherlich nicht gänzlich behagen, wie ich den Abschnitt überarbeitet habe, doch ich hoffe, dass du es als Kompromiss akzeptieren kannst. Im oberen Teil der Seite ist ja auch die Geschichte der Zeichensysteme beleuchtet worden, also kann man da unten auch auf die sprachliche Vergangenheit (auch wenn sie oft genug noch Gegenwart ist) eingehen, finde ich.
Lo!
-
-
-
-
-
-
-
-
-
@@Sternchen96:
nuqneH
Ich gebe zu, ich bin Anfänger.
Ich möchte die benannten Zeichen verwenden, um selbst den Überblick nicht zu verlieren
Eben diese erschweren den Überblick.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
@@dedlfix:
nuqneH
Wo finde ich entsprechende Tabellen für die benannten Zeichen nach anderen Kodierungen - genauer gesagt: mit polnischen Buchstaben?
Die gibt es nur für HTML5.
Was haben die sich denn dabei wieder gedacht?? Nicht nur, dass sie mit „named character references“ entgegen der bestehenden eine neue Terminologie einführen. Vor 15 Jahren wären die Entities ja hilfreich gewesen, aber heute, wo die Empfehlung nur sein kann, die richtigen Zeichen zu verwenden und i.a.R. UTF-8? Ziemlich sinnlos, der Wust an Entities. Ziemlich HTML5.
muss du dir sowieso die Unicode-Codepoint-Nummer des jeweiligen Zeichens suchen, die du dann in der Hex- oder Dezimalschreibweise als NCR angeben musst.
Die Umrechnung in dezimal wäre ziemlich überflüssig und kontaproduktiv.
Suche nach "Unicode Charts".
Oder nach Richard Ishidas Tools.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Hi!
muss du dir sowieso die Unicode-Codepoint-Nummer des jeweiligen Zeichens suchen, die du dann in der Hex- oder Dezimalschreibweise als NCR angeben musst.
Die Umrechnung in dezimal wäre ziemlich überflüssig und kontaproduktiv.Ist doch egal. Überflüssige Arbeit (NCRs statt UTF-8-kodierter Zeichen) und Unleserlichkeit wird durch keine der beiden Schreibweisen beseitigt.
Lo!
-
-