??? istedet for æøå i FF 1.5
Argh
Hvad er den tekniske forklaring på at på enkelte hjemmeside bliver der vist
et ? istedet for æ eller ø eller å? Det er som sagt kun på enkelte
hjemmesider, så det må jo være webudvikleren der ikke overhoolder nogle
standarder. Men hvad er forklaringen?
Tak
AA
Ivan V. Klattrup
> Men hvad er forklaringen?
Efter hvad jeg har lagt mfrke til, er det ner der ikke er angivet et
tegnsft i koden (f.eks kan gratis-ting.dk godt drille med ?-tegn), og FF
se falder tilbage til "Unicode (UTF-8)"
Jeg ved ikke om det er muligt at fe FF til at falde tilbage pe "Vestligt
(ISO-8859-1)" altid, i stedet for.
--
Ivan V. Klattrup
http://www.klattrup.dk
Ivan V. Klattrup
><SNIP>
Det blev sq lige så underligt, med de tre tegn.
Efter hvad jeg har lagt mærke til, er det når der ikke er angivet et
tegnsæt i koden (f.eks kan gratis-ting.dk godt drille med ?-tegn), og FF
så falder tilbage til "Unicode (UTF-8)"
Jeg ved ikke om det er muligt at få FF til at falde tilbage på "Vestligt
Christian Bohr-Halling
>Jeg ved ikke om det er muligt at få FF til at falde tilbage på "Vestligt
>(ISO-8859-1)" altid, i stedet for.
Indstillinger -> indhold -> avanceret -> "standard tegnsæt" ?
--
What is life, except excuse for death,
or death, but an escape from life. -Ukendt
Ivan V. Klattrup
>Indstillinger -> indhold -> avanceret -> "standard tegnsæt" ?
der har jeg sat den til "Vestligt (ISO-8859-1)", men det virker som vinden
blæser :-)
Christian Bohr-Halling
>>Indstillinger -> indhold -> avanceret -> "standard tegnsæt" ?
>der har jeg sat den til "Vestligt (ISO-8859-1)", men det virker som vinden
>blæser :-)
Hm, det har du ret i. Jeg prøvede før at sætte den til noget andet
end 8859-1 og gå til www.gratis-ting.dk, hvorefter den også viste
"?" for æ, ø og å -- modsat tidligere. Så satte jeg den tilbage til
8859-1. Jeg blev dog nødt til rent fysisk af lukke fanen ned og
indlæse siden igen, før jeg fik de rigtige æøå igen (opdatering gik
ikke?!). Gik så ud fra, at det virkede ok, men der tog jeg åbenbart
fejl:
Nu, efter at have lukket FF ned og startet den igen, mener den, at
siden i stedet skal vises med UFT-8, selvom den står til 8859-1 per
standard i omtalte indstilling.
Nå, den logik opgiver jeg så at finde mere rundt i her i nat og
lusker hjem til Bcren-land igen ;-)
Carl Drud
> Efter hvad jeg har lagt mærke til, er det når der ikke er angivet et
> tegnsæt i koden (f.eks kan gratis-ting.dk godt drille med ?-tegn), og FF
> så falder tilbage til "Unicode (UTF-8)"
Kører du siden gennem validator på W3C vælger den også utf-8.
http://validator.w3.org/check?uri=http%3A%2F%2Fgratis-ting.dk%2Fny%2Findex.php
--
Med venlig hilsen
Carl
Ivan V. Klattrup
>Kører du siden gennem validator på W3C vælger den også utf-8.
Ja det kan jeg se, og prøver man så WDG's validator tror den på ISO-8859-1
, det er noget mærkeligt noget.
Christian Bohr-Halling
>> Efter hvad jeg har lagt mærke til, er det når der ikke er angivet et
>> tegnsæt i koden (f.eks kan gratis-ting.dk godt drille med ?-tegn), og FF
>> så falder tilbage til "Unicode (UTF-8)"
>Kører du siden gennem validator på W3C vælger den også utf-8.
Kan ikke se, UTF-8 el. andet står angivet noget sted i det, serveren
giver tilbage: http://www.itu.dk/~chr/temp/ukom.txt
Opera kan i øvrigt heller ikke finde noget i den stil:
http://www.itu.dk/~chr/temp/gts.png
Jeg mener ikke, det skal fortolkes som UTF-8, hvis intet er angivet,
men ASCII (kan huske forkert). Gad i så fald vide, hvor UFT-8-ideen
kommer fra?
Carl Drud
> Jeg mener ikke, det skal fortolkes som UTF-8, hvis intet er angivet,
> men ASCII (kan huske forkert).
Sådan er det vist med mail/news beskeder. Om det forholder sig ligeså
med web sider ved jeg ikke.
Her er resultatet med "Encoding: us-ascii" valgt.
> Gad i så fald vide, hvor UFT-8-ideen kommer fra?
Da siden indeholder 8bit tegn har den har vel skønnet det var det bedst
egnede.
Christian Bohr-Halling
>> Jeg mener ikke, det skal fortolkes som UTF-8, hvis intet er angivet,
>> men ASCII (kan huske forkert).
>Sådan er det vist med mail/news beskeder. Om det forholder sig ligeså
>med web sider ved jeg ikke.
Nå, så må jeg vel hellere se, om jeg kan finde ud af en mulig årsag
og få en opfrisket HTML/HTTP-læsning :-)
En meget hurtigt HTTP-læsning giver, at det per standard skal ses
som ISO-8859-1 (muligt jeg har misset noget i farten):
|The "charset" parameter is used with some media types to define the
|character set (section 3.4) of the data. When no explicit charset
|parameter is provided by the sender, media subtypes of the "text"
|type are defined to have a default charset value of "ISO-8859-1"
|when received via HTTP.
-- http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1
|Some HTTP/1.0 software has interpreted a Content-Type header without
|charset parameter incorrectly to mean "recipient should guess."
|Senders wishing to defeat this behavior MAY include a charset
|parameter even when the charset is ISO-8859-1 and SHOULD do so when
|it is known that it will not confuse the recipient.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4.1
Det er jo så meget rart, at HTML 4 siger noget andet og overfrumfer
dette:
|The HTTP protocol ([RFC2616], section 3.7.1) mentions ISO-8859-1 as
|a default character encoding when the "charset" parameter is absent
|from the "Content-Type" header field. In practice, this
|recommendation has proved useless because some servers don't allow a
|"charset" parameter to be sent, and others may not be configured to
|send the parameter. Therefore, user agents must not assume any
|default value for the "charset" parameter.
-- http://www.w3.org/TR/html401/charset.html
... og videre....
|To sum up, conforming user agents must observe the following
|priorities when determining a document's character encoding (from
|highest priority to lowest):
|1. An HTTP "charset" parameter in a "Content-Type" field.
|2. A META declaration with "http-equiv" set to "Content-Type" and a
|value set for "charset".
|3. The charset attribute set on an element that designates an external
|resource.
(omtalte gratis-ting-side har intet af dette angivet)
|In addition to this list of priorities, the user agent may use
|heuristics and user settings. For example, many user agents use a
|heuristic to distinguish the various encodings used for Japanese
|text. Also, user agents typically have a user-definable, local
|default character encoding which they apply in the absence of other
|indicators.
Altså kan vi vel slutte, at validatorens og til tider FFs heuristik
i omtalte tilfælde ikke rammer plet, og det er altså dér, UTF-8
kommer ind i billedet. Værre er det, at FF ikke helt kan blive enig
med sig selv om at anvende den angivede "local default character
encoding which they apply in the absence of other indicators",
news:2o1f021lkslpnraf8...@dtext.news.tele.dk - en bug?
Christian Bohr-Halling
>> Jeg mener ikke, det skal fortolkes som UTF-8, hvis intet er angivet,
>> men ASCII (kan huske forkert).
>Sådan er det vist med mail/news beskeder. Om det forholder sig ligeså
>med web sider ved jeg ikke.
Nå, så må jeg vel hellere se, om jeg kan finde ud af en mulig årsag
--
Carl Drud
> Nå, så må jeg vel hellere se, om jeg kan finde ud af en mulig årsag
> og få en opfrisket HTML/HTTP-læsning :-)
Jeg orker ikke at læse det. Har lige været igennem en intern audit i
firmaet på tysk. "Liegt eine konsistenten datenverdichtung vor?".
Velbekomme.;-)
> En meget hurtigt HTTP-læsning giver, at det per standard skal ses
> som ISO-8859-1 (muligt jeg har misset noget i farten):
Her bliver den også vist som iso-8859-1.
[klip div standarder]
> Altså kan vi vel slutte, at validatorens og til tider FFs heuristik
> i omtalte tilfælde ikke rammer plet, og det er altså dér, UTF-8
> kommer ind i billedet. Værre er det, at FF ikke helt kan blive enig
> med sig selv om at anvende den angivede "local default character
> encoding which they apply in the absence of other indicators",
> news:2o1f021lkslpnraf8...@dtext.news.tele.dk - en bug?
Du skriver højere oppe at "per standard skal ses som ISO-8859-1". Dit
screenshot af din Opera tidligere i tråden viser den som "windows-1252"
- en bug?
Christian Bohr-Halling
>> Altså kan vi vel slutte, at validatorens og til tider FFs heuristik
>> i omtalte tilfælde ikke rammer plet, og det er altså dér, UTF-8
>> kommer ind i billedet. Værre er det, at FF ikke helt kan blive enig
>> med sig selv om at anvende den angivede "local default character
>> encoding which they apply in the absence of other indicators",
>> news:2o1f021lkslpnraf8...@dtext.news.tele.dk - en bug?
>
>Du skriver højere oppe at "per standard skal ses som ISO-8859-1". Dit
Og jeg skriver lige efter, at HTML 4 overtrumfer dette og siger, at
det ikke skal være sådan alligevel.
>screenshot af din Opera tidligere i tråden viser den som "windows-1252"
>- en bug?
Nej, en "local default character encoding which they apply in the
absence of other indicators"
--