kaufmännisches Und: & unverzichtbar?
0 0 0 0 
Gunnar Bittersmann
0 0 0 
molily
kaufmännisches Und: & unverzichtbar?
AugeHallo,
trotz utf-8 sind <,> und & nicht direkt als Zeichen im Text verwendbar.
Nun ist nachvollziehbar, dass besonders ein zusätzliches "<" als HTML-spezifisches Zeichen im Text zu Problemen führt und nachfolgende Inhalte verändert werden. Damit ist dann schließlich auch das & nicht mehr sorglos einsetzbar, da es für < immer noch benötigt wird.
Führt nun ein & -ohne Entity- im Text automatisch immer zu Parsingfehlern, oder gibt es doch eine Möglichkeit das kaufmännische Und einfach so verwenden zu können?
Grüsse
Cyx23
-
Hi,
trotz utf-8 sind <,> und & nicht direkt als Zeichen im Text verwendbar.
das hat nicht das geringste mit dem Zeichensatz zu tun: Die von Dir genannten Zeichen sind in HTML mit einer Sonderbedeutung versehen. Und exakt so wie in den meisten Programmiersprachen ein Doublequote innerhalb eines in Doublequotes eingekleideten Strings maskiert werden *muss*, *müssen* diese Sonderzeichen in HTML maskiert werden.
Führt nun ein & -ohne Entity- im Text automatisch immer zu Parsingfehlern, oder gibt es doch eine Möglichkeit das kaufmännische Und einfach so verwenden zu können?
Mal angenommen es gibt eine Situation, in der ein einzelnes "&" in HTML nicht maskiert werden muss. Welchen Vorteil hast Du davon, auf die Maskierung zu verzichten?
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
*müssen* diese Sonderzeichen in HTML maskiert werden.
nein, das ist nicht richtig - das hier zb ist völlig valide und verursacht in einem standardkonformen browser keine parsingfehler:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>foobar</title> </head> <body> <p title="foo & bar">foo< bar&>baz</p> </body> </html>sgml ist allerdings in puncto html eine gefährliche sprache - viele kurzschreibweisen oder syntaxfeinheiten sind nur unter bestimmten voraussetzungen erlaubt
entfernt man an der falschen stelle ein leerzeichen
<p title="foo &bar">foo< bar&>baz</p>
oder so
<p title="foo & bar">foo<bar&>baz</p>oder fügt an der falschen stelle einen einzigen buchstaben ein
<p title="foo & bar">foo< bar&x>baz</p>ist die katastrophe komplett
wenn man präventiv alles maskiert, hat man das problem garnicht erst
-
Hi,
*müssen* diese Sonderzeichen in HTML maskiert werden.
nein, das ist nicht richtigsagst Du das tatsächlich mir?
sgml ist allerdings in puncto html eine gefährliche sprache - viele kurzschreibweisen oder syntaxfeinheiten sind nur unter bestimmten voraussetzungen erlaubt
Ja, beispielsweise ist "<meta [Attribute] />" völlig korrekt, sofern der <head> hier endet und weder "</head>" noch "<body>" angegeben werden. Ich frage mich allerdings, warum man das für die Anwendung der Sprache wissen sollte.
wenn man präventiv alles maskiert, hat man das problem garnicht erst
Exakt. Oder um es anders auszudrücken: Ausnahmen bestätigen die Regel, was aber kein Grund ist, sie anzuwenden.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
sagst Du das tatsächlich mir?
natürlich - oder fühlst du dich nicht angesprochen :D du hast schließlich eine aussage gemacht, die suggeriert, dass es pflicht ist etwas zu tun, obwohl die fragestellung des op eindeutig darauf abziehlt, ob es eben sonderfälle gibt, in denen es nicht pflicht ist - und die gibt es in der tat
Ich frage mich allerdings, warum man das für die Anwendung der Sprache wissen sollte.
es schadet nicht, ein bisschen über allgemeine sgml-regeln bescheid zu wissen, damit sind html oder xml als auszeichnungssprache allgemein etwas verständlicher - aber notwendig ist es selbstredend nicht
Ausnahmen bestätigen die Regel, was aber kein Grund ist, sie anzuwenden.
naja, in dem fall sind die ausnahmen als regelfall gedacht, da die kurzschreibweisen einem sgml-autor erlauben, schneller zur arbeiten - wobei ich bezweifle, dass man noch effizient arbeiten kann, wenn man derart viele sonderkonstruktionen und kurzschreibweisen im kopf haben muss - für einen normalen menschen die beiden features OMITTAG und SHORTTAG schon zu hoch und in komplexeren strukturen auch für hartgesottene leute extrem unleserlich - da log ich mir doch xml als schöne, wohlgeformte sprache
-
Hi,
sagst Du das tatsächlich mir?
natürlich - oder fühlst du dich nicht angesprochen :Dich habe einen Moment lang überlegt :-)
du hast schließlich eine aussage gemacht, die suggeriert, dass es pflicht ist etwas zu tun, obwohl die fragestellung des op eindeutig darauf abziehlt, ob es eben sonderfälle gibt, in denen es nicht pflicht ist - und die gibt es in der tat
Es ist ja auch Pflicht - wie gesagt bestätigen Ausnahmen die Regel. Die Suggerierung, es gäbe keine solche, war Absicht.
Ich frage mich allerdings, warum man das für die Anwendung der Sprache wissen sollte.
es schadet nicht, ein bisschen über allgemeine sgml-regeln bescheid zu wissen, damit sind html oder xml als auszeichnungssprache allgemein etwas verständlicher - aber notwendig ist es selbstredend nichtNein, manche Dinge machen SGML definitiv *nicht* verständlicher ;-)
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes -
Hallo
... da log ich mir doch xml als schöne, wohlgeformte sprache
Und das sollen wir glauben? ;-)
Tschö, Auge
-
-
Hallo,
Ja, beispielsweise ist "<meta [Attribute] />" völlig korrekt, sofern der <head> hier endet und weder "</head>" noch "<body>" angegeben werden. Ich frage mich allerdings, warum man das für die Anwendung der Sprache wissen sollte.
Man sollte den Unterschied zwischen Transitional und Strict kennen, denn in Strict sind Zeichendaten direkt unterhalb von body nicht erlaubt. ;)
Mathias
-
-
-
Hallo,
Die von Dir genannten Zeichen sind in HTML mit einer Sonderbedeutung versehen.
Das hatte ich ja schon bereits ausgeführt.
das hat nicht das geringste mit dem Zeichensatz zu tun
UTF-8 ermöglicht weitestgehend den Verzicht auf Sonderzeichen/Entities.
Welchen Vorteil hast Du davon, auf die Maskierung zu verzichten?
Weniger Sonderbehandlung dürfte doch grundsätzlich vorteilhaft sein. Es wirkt irgendwie unwirtschaftlich auf mich, nur wegen der in manchen Bereichen womöglich verzichtbaren Darstellung von "<" auch gleich noch auf ein unmaskiertes "&" verzichten zu müssen.
Grüsse
Cyx23
-
Moin,
das hat nicht das geringste mit dem Zeichensatz zu tun
UTF-8 ermöglicht weitestgehend den Verzicht auf Sonderzeichen/Entities.Maßgeblich ist nicht der verwendete Zeichensatz sondern die verwendete DTD.
Grüße
Swen
-
Hallo,
Maßgeblich ist nicht der verwendete Zeichensatz sondern die verwendete DTD.
Welche DTD? Wenn du jetzt geschrieben hättest "sondern der verwendete Browser" oder was vom verwendeten OS. Mit UTF-8 komme ich doch nicht wegen einer dtd über die ASCII-Zeichen hinaus, sondern wegen zusätzlicher Bytes?
Grüsse
Cyx23
-
Moin,
Maßgeblich ist nicht der verwendete Zeichensatz sondern die verwendete DTD.
Welche DTD? Wenn du jetzt geschrieben hättest "sondern der verwendete Browser" oder was vom verwendeten OS. Mit UTF-8 komme ich doch nicht wegen einer dtd über die ASCII-Zeichen hinaus, sondern wegen zusätzlicher Bytes?Eine ziemlich abstrakte, eher theoretische Antwort, die die grundlegende Denkrichtung verdeutlichen soll. Dass es da in der Praxis viele "ja, aber" gibt, ist mir klar:
Der Browser interpretiert die HTML-Datei aufgrund eines Regelwerkes. Das Regelwerk ist die verwendete DTD, nicht (in erster Linie) der Zeichensatz. Deshalb ist es ein erstrebenswerter Zustand, HTML-Dokumente regelkonform, valide zu verfassen. Und im Zweifel sollte man - getreu dem Grundsatz "konservativ im Sprechen, liberal im Hören" eher zurückhaltend mit möglichen Ausnahmen umgehen, deshalb das *müssen* von Cheatah.
Ich sollte mich darauf verlassen können, dass ein Browser HTML-Dokumente anhand der einschlägigen DTD korrekt darstellt (dass in der Praxis nicht immer eindeutig ist, was denn nun eine korrekte Darstellung ist, ist eine andere Baustelle). Und wenn die Regel (die HTML-Spezifikation, die DTD) nun vorsieht, dass ein bestimmtes Zeichen so und so interpretiert/dargestellt werden soll, dann ist das halt so - unabhängig von Zeichensatz, denn die HTML-DTDs kennen meiner Erinnerung nach keine "wenn-dieser-Zeichensatz-dann-so und wenn-jener-Zeichensatz-dann-halt-anders Interpretationsregeln.Zu der SGML-Frage nebenbei meine Meinung: Da Webbrowser in der Regel darauf ausgelegt sind, HTML (neuerdings auch: XML)-Dokumente darzustellen, ist ein Rückgriff auf SGML-Konformität theoretisch sicher interessant aber mit Vorsicht zu genießen, da (zu Recht) kaum vermutet werden kann, dass sich Browser-Hersteller ernsthaft viel Gedanken darüber gemacht haben, dass Webseiten-Ersteller auf die Idee kommen, ihr HTML SGMLisch einzukürzen. Zumal SHORTTAG und OMITTAG in HTML noch erlaubt sind, in XML/XHTML jedoch nicht mehr.
Grüße
Swen
-
Hallo,
bislang bin ich davon ausgegangen, dass es nicht möglich ist, per eigener dtd auf ein & bei XHTML verzichten zu können.
Grüsse
Cyx23
-
bislang bin ich davon ausgegangen, dass es nicht möglich ist, per eigener dtd auf ein & bei XHTML verzichten zu können.
du kannst auch eine dtd schreiben, in der in einem <ul>-element nur <head>-elemente vorkommen dürfen und das <head>-element muss ein attribut mit dem namen "honolulu" haben, dessen wert darf nur nummerisch sein
der praktische nutzen hierfür ist im falle von xhtml aber sehr begrenzt, da der sinn von xhtml bzw. jeder anderen verbreiteten html dtd das gemeinsame regelwerk ist, bzw dass es ein standard ist ;)
-
Hallo,
du kannst auch eine dtd schreiben, in der in einem <ul>-element nur <head>-elemente vorkommen dürfen und das <head>-element muss ein attribut mit dem namen "honolulu" haben, dessen wert darf nur nummerisch sein
das könnte ich in der Tat, hilft mir aber nicht bei der Realisierung einer dtd für das frei nutzbare "&" oder auch "<". Falls das im Prinzip genauso machbar ist, muß ich nochmal recherchieren.
bzw dass es ein standard ist
Du meinst, dass Browser sich nicht an die dtd halten, sondern an einen HTML-Standard?
Grüsse
Cyx23
-
das könnte ich in der Tat, hilft mir aber nicht bei der Realisierung einer dtd für das frei nutzbare "&" oder auch "<". Falls das im Prinzip genauso machbar ist, muß ich nochmal recherchieren.
mir erschließt sich die sinnhaftigkeit immer noch nicht ganz - jede halbwegs brauchbare scriptsprache hat eine funktion wie zb htmlspecialchars() in php zum maskieren von den "5 magischen zeichen" - asp/vb kennt zb Server.HTMLEncode() - wie gesagt, das problem wird mir nicht klar
<p/foobar/zb wäre so ein fall - hier gehört das < zum ungeschlossenen p-element und obDu meinst, dass Browser sich nicht an die dtd halten, sondern an einen HTML-Standard?
nein, ich meinte damit dass die dtd der standard ist ;)
-
Moin,
Falls das im Prinzip genauso machbar ist, muß ich nochmal recherchieren.
http://de.selfhtml.org/xml/dtd/allgemeines.htm@title=Das könnte der Anfang der Recherche sein.
Du meinst, dass Browser sich nicht an die dtd halten, sondern an einen HTML-Standard?
Ich denke, weiß es aber nicht definitiv, dass der üblicher Browser sich nicht um die Eigentümlichkeiten einer eigenen DTD kümmert.
Grüße
Swen
-
-
-
-
-
-
-
-
@@Cheatah:
trotz utf-8 sind <,> und & nicht direkt als Zeichen im Text verwendbar.
das hat nicht das geringste mit dem Zeichensatz zu tun
Vom Zeichensatz war auch nicht die geringste Rede.
Live long and prosper,
Gunnar--
Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.
-
-
Führt nun ein & -ohne Entity- im Text automatisch immer zu Parsingfehlern, oder gibt es doch eine Möglichkeit das kaufmännische Und einfach so verwenden zu können?
du kannst & ohne es als entity zu maskieren in vielen fällen problemlos einsetzen (das ist in sgml durchaus erlaubt, daraus resultierend auch in html) - auch ist es möglich < oder > unter gewissen vorausetzungen im klartext zu verwenden zb, wenn danach ein leerzeichen folgt
die sichere methode ist allerdings, einfach jedes vorkommen von &, <, >, " und ' kontextspezifisch zu maskieren - dann kann nix schiefgehen
-
Hallo,
du kannst & ohne es als entity zu maskieren in vielen fällen problemlos einsetzen (das ist in sgml durchaus erlaubt, daraus resultierend auch in html) - auch ist es möglich < oder > unter gewissen vorausetzungen im klartext zu verwenden zb, wenn danach ein leerzeichen folgt
Ja danke, also eigentlich eine einfache Sache wenn HTML statt XHTML eingesetzt wird, und dann noch auf die Leerzeichen achten. Letzteres mag natürlich ein unnötiges Restrisiko bedeuten, und die Beschränkung auf HTML ist vielleicht auch nicht so überzeugend.
Grüsse
Cyx23
-
Ja danke, also eigentlich eine einfache Sache wenn HTML statt XHTML eingesetzt wird, und dann noch auf die Leerzeichen achten. Letzteres mag natürlich ein unnötiges Restrisiko bedeuten, und die Beschränkung auf HTML ist vielleicht auch nicht so überzeugend.
wenn du xhtml einsetzt, wirds gefährlich, da viele der sgml-features zur codeminimierung entfernt wurden - das schränkt die möglichkeiten auch hier ein
das problem dabei ist wie erwähnt nicht, dass es nicht mögliche wäre, sondern dass es praktisch kaum einen nutzen dafür gibt, besonders nicht, wenn du den text generiert in ein (x)html-template einfügst - insbesondere die dtd wird dir einen strich durch die rechnung machen
aber nähres dazu hier, wurde ja schon beantwortet
https://forum.selfhtml.org/?t=175801&m=1156138
-
-
-
Hi,
Führt nun ein & -ohne Entity- im Text automatisch immer zu Parsingfehlern,
HTML-Browser parsen aus Rücksichtnahme auf Schnullibullis so ziemlich jeden Scheiß. "&" ist natürlich trotzdem fehlerhaft, aber praktisch (i.d.R.) ohne Konsequenz. Man findet auch besonders in URLs sehr oft unkodierte "&".
Bei X(HT)ML-Parsern, die halt strenger sind, sieht das anders aus. Die brechen einfach mit Fehlermeldung das Parsen ab, sofern ...
oder gibt es doch eine Möglichkeit das kaufmännische Und einfach so verwenden zu können?
... das "&" nicht in einem als CDATA deklarierten Abschnitt liegt (und also überhaupt nicht geparst wird).
Es wird also passieren, daß, wenn jemand in "XHTML" codet, "&" nicht maskiert, und das Dokument praktisch problemlos als HTML ausliefert, beim gleichen Dokument der Browser die Grätsche macht, falls der Autor es wirklich mal als XHTML ausliefern sollte.
Gruß, Cybaer
--
Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
(Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
-
Hallo,
HTML-Browser parsen aus Rücksichtnahme auf Schnullibullis so ziemlich jeden Scheiß. "&" ist natürlich trotzdem fehlerhaft, aber praktisch (i.d.R.) ohne Konsequenz. Man findet auch besonders in URLs sehr oft unkodierte "&".
Gerade dort kann die Fehlertoleranz auch False Positives produzieren, bspw. führt
<a href="bla?param=1¥=1®=1¢=1£=1¬=1">uri</a>
im Firefox und IE zu folgender URI:
bla?param=1¥=1®=1¢=1£=1¬=1Das ist allerdings nicht bei allen Entities der Fall, es scheint recht willkürlich zu sein. Jedenfalls sollte man mit der Auswahl der Parameternamen vorsichtig sein, falls man sich auf die "Fehlertoleranz" verlässt. Oder halt gleich konformes und damit eindeutiges HTML schreiben.
Mathias
-