webForumDet fria alternativet

HTML-koder för tecken?

7 svar · 505 visningar · startad av AndreasC

AndreasCMedlem sedan mars 20011 964 inlägg
#1

Grävde fram en gammal tabell över html-koder för de flesta tecken vi har i vårat moderna samhälle. Har aldrig använt mig av dem såvida IE inte renderat fel så jag måste använda dem. Tänkte använda dem så mycket som möjligt men den är lite konstig för den inger en del frågor.

Det verkar som den använder olika koder för att få fram samma tecken.

Enligt den renderade tabellen så ska man använda &#34 för att få fram " men i källkoden så har upphovsmannen skrivit &quot för att få fram samma tecken i det renderade resultatet. Då undrar jag om man ska använda sig av &#sifferkombination eller om man istället för sifferkombination ska använda ord som exempelvis quote. För att få fram & så har jag fattat att &amp är det rätta.

Men blir det inte lite dubbelt?

jarvkloMedlem sedan juli 20013 378 inlägg
#2

Nejdå..

http://blooberry.com/indexdot/html/tagpages/text.htm tycker jag ger en ganska bra översikt om varför och hur det funkar samtidigt som den diskuterar lite för- och nackdelar med "numbered entities" versus "named entities"

zcorpanMedlem sedan dec. 20042 245 inlägg
#3

Man kan använda såväl named character reference, decimal character reference, hexadecimal character reference samt tecknet direkt. Exempel:

®
®
®
®

Alla fyra sätten kommer visa "®". Den första (named character reference) funkar eftersom den finns med som en ENTITY i DTDn. Det är ett skäl till att inte använda just den metoden när man jobbar i XML (eller XHTML), då de flesta webbläsare är s.k. non validating parsers, dvs, de läser inte DTDn.

Själv brukar jag skriva in tecknet direkt. (Både för HTML och XML.) :)

jarvkloMedlem sedan juli 20013 378 inlägg
#4

zcorpan skrev:

Det är ett skäl till att inte använda just den metoden när man jobbar i XML (eller XHTML), då de flesta webbläsare är s.k. non validating parsers, dvs, de läser inte DTDn.

Whhooooaaaa there pardener!

Vänta lite...

Eftersom både MSIE och FireFox har validerande XML-parsers inbyggda skulle jag väldigt gärna vilja veta vad du stödjer det där uttalandet på och framförallt vilka webbläsare du innefattar i uttrycket "de flesta webbläsare"

Testa gärna med följande filer - den första innehåller namngivna teckenentiteter som är korrekta enligt DTD:n, den andra innehåller även en felaktig teckenentitet (&foo;) och utlöser därför ett valideringsfel eftersom den inte ingår i DTD:n...

Korrekt XML: http://member.webforum.nu/2241/entitet_validerande.xml
Felaktig XML: http://member.webforum.nu/2241/entitet_icke_validerande.xml

Äh - varför inte testa XHTML-fallet också: (Don't try these in MSIE kids ;) )

Korrekt XHTML: http://xhtml.nu/exempel/entitet_validerande.xhtml
Felaktig XHTML: http://xhtml.nu/exempel/entitet_icke_validerande.xhtml

Så - som jag ser det (baserat bl.a. på de exempel jag gett) så finns det inget som hindrar dig från att använda något av de skrivsätten som zcorpan radar upp varken i XML eller XHTML så länge du ser till att dina namngivna teckenentiteter finns med i DTD:n ;)

zcorpanMedlem sedan dec. 20042 245 inlägg
#5

Fel. Varken Mozilla eller IE (eller Opera, eller Safari) läser in externa DTDer. Ang. Mozilla kan läsas här: http://www.mozilla.org/newlayout/xml/

Mozilla does not load external entities from the web.

Ang. IE antar jag att den känner igen de vanliga HTML-entities... Vet inte säkert.

Hur som helst, jag gjorde ett par egna test cases, vilket visar att en intern DTD fungerar, men inte en extern. (snip) Och här är en XHTML som deklarerats som "standalone" och innehåller den välkända  : (snip)

Jag vet också att Safari inte alls känner igen entities för XHTML även om det inte deklarerats som standalone, vilket Roger Johansson har skrivit om.

:bire

jarvkloMedlem sedan juli 20013 378 inlägg
#6

Hmm..

Visst - vi kan gärna prata fel om du vill :e

XML kan vara svårt - ingen av de DTD:er du använder i dina testfall är korrekta, och eftersom inget av dina dokument alltså överhuvudtaget kan fås att validera (eftersom inget av dem har någon korrekt DTD att validera mot!) så undrar jag vad de egentligen ger som testfall betraktade ;)

Fallet Internal:

<!DOCTYPE foo [
 <!ENTITY bar "PASS">
]>
<foo> &bar; </foo>

Bör vara:

<!DOCTYPE foo [
 <!ELEMENT foo (#PCDATA)>
 <!ENTITY bar "PASS">
]>
<foo> &bar; </foo>

- och fungerar även efter korrigeringen helt OK.

Fallet External:
Ersätter du DTD-koden

 <!ENTITY foo "PASS">

med den korrekta varianten

 <!ELEMENT foo (#PCDATA)>
 <!ENTITY bar "PASS">

så ser du att MSIE:s XML-parser faktiskt laddar in den externa DTD:n i samband med validering av koden du använder som testfall

<!DOCTYPE foo SYSTEM "foo.dtd" >
<foo> &bar; </foo>

Om du inte tror mig, så ändra &bar; till &barr;... Du konstaterar då snabbt att det är först då som felmeddelandet om "felaktig entitet" dyker upp i MSIE ;)

Fallet "standalone"
Att en extern DTD:n inte laddas om man deklarerar XML-dokumentet som "standalone" säger sig som jag ser det självt eftersom "standalone" per definition innebär att alla typer av externa entiteter (som t.ex. DTD-filen i detta fall) skall ignoreras

Den fristående dokumentdeklarationen [standalone-attributet, min kommentar] MÅSTE ha värdet "no" om någon extern uppmärkningsdeklaration innehåller deklarationer av:
[...]
* entiteter (andra än amp, lt, gt, apos, quot), om anrop till dessa entiteter förekommer i dokumentet
[...]

Källa: http://www.xml.se/xml/REC-xml-sv/#sec-rmd
- så det exemplet ser jag egentligen inte heller som något skäl för att argumentera emot användandet av namngivna teckenkoder i XML eller XHTML eftersom man ju näppeligen lär köra med standalone="yes" i t.ex. XHTML (eller för den delen en XML-fil med extern DTD) speciellt ofta eller "per default" ;)

Jag menar, om man nu säger åt parsern att strunta i att ladda DTD:n känns det i min värld ganska mysko att sedan uppröra sig över att den inte laddats ;)

Sammanfattning
Visst - i materialet hos Roger som du länkar till, framgår att namngivna teckenentiteter inte funkar i Safari och i Opera med version < 7.5 (<= 7.5 på Mac) så det är inte problemfritt - men jag hävdar ändå att det är överdrivet att säga annat än att namngivna teckenentiteter funkar i de flesta webbläsarna när det gäller XHTML, men att det kan bli problem med dem i äldre Operor och i aktuella versioner av Safari ;)

När det gäller XML är läget sämre, men det funkar i MSIE iom att den faktiskt läser externa entiteter - åtminståne de som refereras i en <!DOCTYPE...

:birp

zcorpanMedlem sedan dec. 20042 245 inlägg
#7

OK, jag är medveten om att DTDn var felaktig men jag trodde inte att det skulle göra någon skillnad - my bad.

Jag visste inte heller att MSIE läste den externa DTDn.

Testfallet med standalone visade bara att det inte är alltid entities fungerar... I Mozilla fungerar de bara om dokumentet inte är standalone och DOCTYPEn har en public identifier som Mozilla känner igen.

Jag ser fortfarande ingen anledning att förlita sig på DTDn genom att använda entities. :)

Jag har nu även lagt märke till att IE5 på Mac läser in externa DTDer för XML. Att hämta och tolka DTDn för XHTML 1.0 är riktigt segt vill jag påstå, tar ca 5-7 sekunder extra innan sidan visas...

jarvkloMedlem sedan juli 20013 378 inlägg
#8

zcorpan skrev:

Jag har nu även lagt märke till att IE5 på Mac läser in externa DTDer för XML. Att hämta och tolka DTDn för XHTML 1.0 är riktigt segt vill jag påstå, tar ca 5-7 sekunder extra innan sidan visas...

Det är lika illa i MSIE6/Win om du inte har en blixtsnabb lina till en DTD på en blixtsnabb server :e

Men men... Vara hur det vill med det och de andra detaljerna vi tjabbats om här på slutet...

"Det alla bästa" är väl antagligen, hur man än vrider och vänder på saken, (och som du också varit inne på) att undvika alla former av entiteter så långt man kan (oavsett om de kodas med namn eller numeriska värden) och i ställlet vara noga med att ens kod och innehåll verkligen följer den teckenkodning man anger för sidan - för i praktiken är det ju inte så många tecken man "måste" specialkoda om man bara har en någorlunda modern editor och har besökare med webbläsare nyare än Netscape 3 som målgrupp ;)

Om inte annat för att skriva lite mindre voluminös kod...
Jag menar- ett Å i ISO-8859-1 tar upp en byte, medan &Aring; tar upp sju och gör samma sak

Think about it!

PEACE :birp

137 ms totalt · 3 externa anrop · v20260731065814-full.3ab8d573
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
134 ms — hämta tråd, inlägg och bilagor (db)