Kandu.dk - HTML5 tegnsæt


/ Forside / Teknologi / Udvikling / HTML / Nyhedsindlæg

Glemt dit kodeord?

Brugernavn*

Kodeord *

Husk mig

Brugerservice

Kom godt i gang

Bliv medlem

Seneste indlæg

Find en bruger

Stil et spørgsmål

Skriv et tip

Fortæl en ven

Pointsystemet

Kontakt Kandu.dk

Emnevisning

Kategorier

Alfabetisk

Karriere

Interesser

Teknologi

Reklame

Top 10 brugere

HTML

#	Navn	Point
1	molokyle	11184
2	Klaudi	5506
3	bentjuul	3377
4	severino	2040
5	smorch	1950
6	strarup	1525
7	natmaden	1396
8	scootergr..	1320
9	e.c	1150
10	miritdk	1110

HTML5 tegnsæt
Fra : Jørgen Farum Jensen

Dato : 08-03-11 14:53

Jeg er begyndt at bruge en HTML5 dokumenttypeerklæring.

Min tegnsæt-markør er flg.
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">

Når jeg ikke bruger utf-tegnsæt får jeg følgende
advarsel fra W3C's validator:
Using windows-1252 instead of the declared encoding iso-8859-1

Er det noget jeg skal tage mig af?

Jeg gider ikke utf-8 og det medfølgende besvær
med HTML tegnækvivalenter.

--
Jørgen Farum Jensen
http://webdesign101.dk
..

scootergrisen (08-03-2011)

Kommentar
Fra : scootergrisen

Dato : 08-03-11 15:28

Fejlbeskeden er meget tydelig.
Du har gemt filen i windows-1252 men du skriver i din HTML fil at den er
skrevet i ISO-8859-1.

Så du skal gemme filen som ISO-8859-1 i det program du gemmes filen med.

Jeg ville da "tage mig af det" hvis det var min kode.
Ellers kommer du jo til og skulle se på den fejl besked hele tiden.

Jørgen Farum Jensen (08-03-2011)

Kommentar
Fra : Jørgen Farum Jensen

Dato : 08-03-11 16:50

Den 08-03-2011 15:28, scootergrisen skrev:
> Fejlbeskeden er meget tydelig.
> Du har gemt filen i windows-1252 men du skriver i din HTML
> fil at den er skrevet i ISO-8859-1.
>
> Så du skal gemme filen som ISO-8859-1 i det program du
> gemmes filen med.

Hvad er forskellen?

> Jeg ville da "tage mig af det" hvis det var min kode.
> Ellers kommer du jo til og skulle se på den fejl besked hele
> tiden.

Det er ikke en fejl men en advarsel. Jeg kan
sagtens leve med den.

Det jeg er interesseret
i er hvorfor HTML5-validatoren kommer med den
advarsel, når jeg i 14 år har lavet tusinder
af websider i HTML0.9, HTML2, HTML3.2, HTML4.01
og XHTML1.0 med den samme tegnsæt-markør uden
nogensinde før at have fået den warning.

--
Jørgen Farum Jensen
http://webdesign101.dk
..

scootergrisen (08-03-2011)

Kommentar
Fra : scootergrisen

Dato : 08-03-11 17:09

> Hvad er forskellen?

Forskellen på windows-1252 og ISO-8859-1 ?
Tegn fra hex 80 til 9F.

Du kan se tegnene her :
http://en.wikipedia.org/wiki/ISO/IEC_8859-1
http://en.wikipedia.org/wiki/Windows-1252

> Det er ikke en fejl men en advarsel. Jeg kan
> sagtens leve med den.

Du kan bare rette din meta kode til :
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">

> Det jeg er interesseret
> i er hvorfor HTML5-validatoren kommer med den
> advarsel, når jeg i 14 år har lavet tusinder
> af websider i HTML0.9, HTML2, HTML3.2, HTML4.01
> og XHTML1.0 med den samme tegnsæt-markør uden
> nogensinde før at have fået den warning.

Måske fordi w3c validatoren først er begyndt at checke det nu.

Birger Sørensen (08-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 08-03-11 15:54

Jørgen Farum Jensen formulerede spørgsmålet:
> Jeg er begyndt at bruge en HTML5 dokumenttypeerklæring.
>
> Min tegnsæt-markør er flg.
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
>
> Når jeg ikke bruger utf-tegnsæt får jeg følgende
> advarsel fra W3C's validator:
> Using windows-1252 instead of the declared encoding iso-8859-1
>
> Er det noget jeg skal tage mig af?
>
> Jeg gider ikke utf-8 og det medfølgende besvær
> med HTML tegnækvivalenter.

Mener de to er ens, i hvert fald havd angår printbare karakterer.
Ved ikke om det betyder noget, men iso bør vist være ISO. Måske
validatoren vil have det med stort for at genkende.
Overvej i øvrigt ISO-8859-15 i stedet. Det har ¤ med - til gengæld
mangler er nogle andre også ændret.
http://en.wikipedia.org/wiki/ISO/IEC_8859-15

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Jørgen Farum Jensen (08-03-2011)

Kommentar
Fra : Jørgen Farum Jensen

Dato : 08-03-11 16:54

Den 08-03-2011 15:53, Birger Sørensen skrev:

> Ved ikke om det betyder noget, men iso bør vist være ISO.
> Måske validatoren vil have det med stort for at genkende.
> Overvej i øvrigt ISO-8859-15 i stedet. Det har € med - til
> gengæld mangler er nogle andre også ændret.
> http://en.wikipedia.org/wiki/ISO/IEC_8859-15

Tak for input. Validatoren køber
ISO-8859-15 uden kommentarer.
--
Jørgen Farum Jensen
http://webdesign101.dk
..

Bertel Lund Hansen (09-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 09-03-11 00:07

Jørgen Farum Jensen skrev:

> Jeg gider ikke utf-8 og det medfølgende besvær
> med HTML tegnækvivalenter.

Kan man da ikke bare skrive lige ud ad landevejen?

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 14:08

Den 09-03-2011 00:06, Bertel Lund Hansen skrev:
> Jørgen Farum Jensen skrev:
>
>> Jeg gider ikke utf-8 og det medfølgende besvær
>> med HTML tegnækvivalenter.
>
> Kan man da ikke bare skrive lige ud ad landevejen?

Jeg kan godt forstå ham for da jeg bruger UTF8 i PHP giver det problemer
med mange af de indbyggede funktioner som ser 1 byte som værende 1 tegn
fordi sådan var det jo før.

Så det er helt klart ikke problemfrit at bruge multibyte UTF-8.
Der er også det med at hvis man gemme BOM i starten af filen så giver
det også problemer. Nu kan man så selv vælge om man vil gemme med BOM
men hvis man ikke er klar over det så kommer der 3 tegn som man ikke
lige kan forstå hvor stammer fra.

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 16:54

Den 09-03-2011 14:07, scootergrisen skrev:
> Den 09-03-2011 00:06, Bertel Lund Hansen skrev:
>> Jørgen Farum Jensen skrev:
>>
>>> Jeg gider ikke utf-8 og det medfølgende besvær
>>> med HTML tegnækvivalenter.
>>
>> Kan man da ikke bare skrive lige ud ad landevejen?
>
> Jeg kan godt forstå ham for da jeg bruger UTF8 i PHP giver det problemer
> med mange af de indbyggede funktioner som ser 1 byte som værende 1 tegn
> fordi sådan var det jo før.

Findes der da ikke en UTF8toISO function i PHP?

Fordelen ved UTF-8 er jo også, det er det, som XML bygger på. Så man kan
få lidt prooblemer med AJAX, f.eks. hvis ikke man kører rent UTF-8.

I ASP har jeg en fornemmelse af, at alt fallback er til ISO8859, også
når der gemmes tekst-filer. Det gør, jeg ikke selv kan bruge UTF-8, for
det ville give bøvl både ved gamning og ved hentning.

Stig lavede på et tidspunkt en ANSIToUTF-8 i ASP, som jeg bruger til at
gøre 8859-indhold "UTF-ificeret" for XML. Hvis ikke den function findes
i PHP, kan nogen måske oversætte:

Function AnsitoUTF8 (AnsiString)
   Dim Ps ' Startposition
   Dim P ' position
   Dim L ' len
   Dim C ' char no
   L = Len (AnsiString)
   Ps = 1
   For P = 1 to L
      C = Asc(Mid (AnsiString,P,1))
      If C > 127 Then
         If Ps < P Then
            AnsitoUTF8 = AnsitoUTF8 + Mid (AnsiString,Ps,P-Ps) ' non ascii
         End If
         Ps = P + 1
         If C < 192 Then
            AnsitoUTF8 = AnsitoUTF8 + chr(194) + chr(128 + C mod 64) ' table
under is 194
         Else
            AnsitoUTF8 = AnsitoUTF8 + chr(195) + chr(128 + C mod 64) ' table
under is 195
         End If
      End If
   Next
   If Ps < L Then
      AnsitoUTF8 = AnsitoUTF8 + Mid (AnsiString,Ps,L-Ps+1) ' non ascii
   End If
End Function ' AnsitoUTF8

MVH
Rune Jensen

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 17:03

Den 09-03-2011 16:54, Admin skrev:

> Stig lavede på et tidspunkt en ANSIToUTF-8 i ASP, som jeg bruger til at
> gøre 8859-indhold "UTF-ificeret" for XML. Hvis ikke den function findes
> i PHP, kan nogen måske oversætte:

Lad os sige, du har noget tekst-indhold, som er gemt i ISO8859, men at
dette skal bruges i et RSS-feed (XML/UTF-8).

Funktionen bruges så:

Set charset UTF-8
Hent Dit8859indhold
Response.Write AnsitoUTF8 ( Dit8859indhold)

....Charencoding til det, som udskrives skal så selvfølgelig være UTF-8
også som antydet.

MVH
Rune Jensen

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 17:02

> Findes der da ikke en UTF8toISO function i PHP?

Jo. Det er bare nogen gange besværligt at bruge.

Lad os sige du har et associativt array med UTF8 encoded data og med
tegn som øæå i.

Så lad os sige du vil gøre det første bogstav stort i hvert index og
derefter sorter arrayet stå det står i alfabetisk rækkefølge fra a-å.
Det er ikke så let.

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 17:11

Den 09-03-2011 17:02, scootergrisen skrev:
>> Findes der da ikke en UTF8toISO function i PHP?
>
> Jo. Det er bare nogen gange besværligt at bruge.
>
> Lad os sige du har et associativt array med UTF8 encoded data og med
> tegn som øæå i.
>
> Så lad os sige du vil gøre det første bogstav stort i hvert index og
> derefter sorter arrayet stå det står i alfabetisk rækkefølge fra a-å.
> Det er ikke så let.

Det kan du have ret i, hvis PHP kun forstår singlebyte. Men på nuværende
tidsounkt, og med PHPs popularitet, undrer det mig også, hvis disse
funktioner ikke er fulgt med, så de forstår multibyte.

MVH
Rune Jensen

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 17:24

Admin sendte dette med sin computer:
> Den 09-03-2011 17:02, scootergrisen skrev:
>>> Findes der da ikke en UTF8toISO function i PHP?
>>
>> Jo. Det er bare nogen gange besværligt at bruge.
>>
>> Lad os sige du har et associativt array med UTF8 encoded data og med
>> tegn som øæå i.
>>
>> Så lad os sige du vil gøre det første bogstav stort i hvert index og
>> derefter sorter arrayet stå det står i alfabetisk rækkefølge fra a-å.
>> Det er ikke så let.
>
> Det kan du have ret i, hvis PHP kun forstår singlebyte. Men på nuværende
> tidsounkt, og med PHPs popularitet, undrer det mig også, hvis disse
> funktioner ikke er fulgt med, så de forstår multibyte.
>
>
> MVH
> Rune Jensen

utf8_encode() og utf8_decode, svjh...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 17:40

> utf8_encode() og utf8_decode, svjh...

Lad os sige vi ville lave hvert ord med stort forbogstav i for eksempel
iso-8859-1 så kunne vi skrive :

echo ucwords('der var engang en lille gris');

Der Var Engang En Lille Gris

Let nok.
Hvad så med multibyte som UTF8 ? :

echo utf8_encode(ucwords(utf8_decode('der var engang en lille gris')));

Mest besværligt lort at bruge.
Og det var et let eksempel så forstild jer at man skal gøre dit og dat
frem og tilbage mellem funktioner der kun returnere i singlebyte så
ender det altså med at blive besværligt.

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 18:05

Den 09-03-2011 17:40, scootergrisen skrev:

> Let nok.
> Hvad så med multibyte som UTF8 ? :
>
> echo utf8_encode(ucwords(utf8_decode('der var engang en lille gris')));
>
> Mest besværligt lort at bruge.
> Og det var et let eksempel så forstild jer at man skal gøre dit og dat
> frem og tilbage mellem funktioner der kun returnere i singlebyte så
> ender det altså med at blive besværligt.

Det er fordi sådanne encoding-funktioner egentlig ikke er beregnet til
mere end én operation. F.eks. til direkte udskrivning i XML/UTF-8 af et
8859 dokument. Det er ikke meningen, de skal ind i komplekse
beregninger, da det fordobler hver underoperation.

I stedet burde man have tilrettet de andre funktioner, så de også
fungerede med multibyte. Funktionen er jo lavet, det er kun charendong,
som er forskellen.

I ASP er der et lign. problem. Hvis jeg har brug for at HTMLencode en
streng, vil det give forkert resultat, hvis den streng er i multibyte.
HTMLencode modtager kun singlebyte.

Response.Write Server.HTMLEncode( streng)

Virker ikke med UTF-8. Så man laver her sin egen HTMLEncode-funktion til
dét med tre-fire Replace - ret åndsvagt.

Hvis alt, man laver, er i samme encoding, bør scriptsproget vel nærmere
rette sig efter det. Sætter man f.eks. selve scriptets encoding til
UTF-8, burde en HTMLEncode i ASP således kun tage UTF-8 ind og udspy
UTF-8. Det sker ikke - ASP accepterer stadig kun 8859.

MVH
Rune Jensen

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 18:13

PHP forstår heller ikke BOM i starten af UTF filer med BOM.
Det kommer PHP til i version 6 har jeg læst.

Stig Johansen (10-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 10-03-11 09:24

scootergrisen wrote:

> PHP forstår heller ikke BOM i starten af UTF filer med BOM.
> Det kommer PHP til i version 6 har jeg læst.

Først en korrektion - UTF-8 filer - forhåbentlig.

XML 'var' pr. default utf-8, og der skulle IKKE BOM på disse.

En 'vis herre' lagde BOM på XML (utf-8), hvilket gav mange grå hår omkring
årtusindeskiftet.

Man kunne virkelig udvikle had til 'denne person', for netop den skide BOM
gjorde at andre parsere brokkede sig over XML'et (andre = non MS, aka
libxml, xerces m.m.fl).

Jeg snakker æraen med 'webservices', hvor 'en vis herre' var en stor klods
om benet.

--
Med venlig hilsen
Stig Johansen

Stig Johansen (10-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 10-03-11 09:24

Admin (10-03-2011)

Kommentar
Fra : Admin

Dato : 10-03-11 10:47

Den 10-03-2011 09:24, Stig Johansen skrev:

> Jeg snakker æraen med 'webservices', hvor 'en vis herre' var en stor klods
> om benet.

"Onde" tunger vil måske påstå, at "visse herrer" i Mountain View, og
med et helt andet syn på standarder, forlængst har overtaget førersædet
fra herren i Redmond, og at der derfor blæser andre vinde nu.

Det frie broowservalg har nok ikke gjort det bedre, at MS ikke ligefrem
har vadet i succéer de seneste år. For nogle, der er selve computeren
lig med IE. Hvis først de skifter browser, kunne de jo finde på at
skifte OS også... Ren blasfemi :)

MVH
Rune Jensen

Stig Johansen (14-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 14-03-11 18:05

Admin wrote:

> Den 10-03-2011 09:24, Stig Johansen skrev:
>
>> Jeg snakker æraen med 'webservices', hvor 'en vis herre' var en stor
>> klods om benet.
>
> Det frie broowservalg har nok ikke gjort det bedre

Kort - jeg snakkede ikke om browsere, men integration via 'webservices',
hvor MS og IBM lavede sololæb og pressede SUN ud af 'samarbejdet'.

Been there, done that, heard that....

--
Med venlig hilsen
Stig Johansen

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 18:22

scootergrisen tastede følgende:
>> utf8_encode() og utf8_decode, svjh...
>
> Lad os sige vi ville lave hvert ord med stort forbogstav i for eksempel
> iso-8859-1 så kunne vi skrive :
>
> echo ucwords('der var engang en lille gris');
>
> Der Var Engang En Lille Gris
>
> Let nok.
> Hvad så med multibyte som UTF8 ? :
>
> echo utf8_encode(ucwords(utf8_decode('der var engang en lille gris')));
>
> Mest besværligt lort at bruge.
> Og det var et let eksempel så forstild jer at man skal gøre dit og dat frem
> og tilbage mellem funktioner der kun returnere i singlebyte så ender det
> altså med at blive besværligt.

Jeg bruger dem kun i forbindelse med AJAX.
utf8_decode for modtagne data og utf8_encode, for data der skal
returneres.
Kan ikke se problemet.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 18:44

Den 09-03-2011 18:21, Birger Sørensen skrev:
> scootergrisen tastede følgende:

>> Mest besværligt lort at bruge.
>> Og det var et let eksempel så forstild jer at man skal gøre dit og dat
>> frem og tilbage mellem funktioner der kun returnere i singlebyte så
>> ender det altså med at blive besværligt.
>
> Jeg bruger dem kun i forbindelse med AJAX.
> utf8_decode for modtagne data og utf8_encode, for data der skal returneres.
> Kan ikke se problemet.

Bruger du UTF-8 som encoding til dine hjemmesider?

Det var SVJKS præmissen for Scootergrisens indlæg.

Det burde ikke være nødvendigt at decode, hvis man bruger UTF-8 i
forvejen til HTMLen, da AJAX kører UTF-8 også.

MVH
Rune Jensen

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 19:04

Admin forklarede:
> Den 09-03-2011 18:21, Birger Sørensen skrev:
>> scootergrisen tastede følgende:
>
>>> Mest besværligt lort at bruge.
>>> Og det var et let eksempel så forstild jer at man skal gøre dit og dat
>>> frem og tilbage mellem funktioner der kun returnere i singlebyte så
>>> ender det altså med at blive besværligt.
>>
>> Jeg bruger dem kun i forbindelse med AJAX.
>> utf8_decode for modtagne data og utf8_encode, for data der skal returneres.
>> Kan ikke se problemet.
>
> Bruger du UTF-8 som encoding til dine hjemmesider?
>
> Det var SVJKS præmissen for Scootergrisens indlæg.
>
> Det burde ikke være nødvendigt at decode, hvis man bruger UTF-8 i forvejen
> til HTMLen, da AJAX kører UTF-8 også.
>
>
> MVH
> Rune Jensen

Nej, jeg bruger latin-1 (ISO-8859-1) eller latin-9 (ISO-8859-15), også
i databaser.
Fordi man så er ude over problemet, undtagen med AJAX, hvor det er
enkelt at løse ...

Der blev spurgt efter utf8 <-> ISO.
Jeg gav bare navnene på funktionerne.

De danske - ÆØÅæøå findes også i utf8. Så hvis grisen har problemer, må
det vel være fordi han ikke er konsekvent - eller forventer af utf8, at
når nu han er dansker, laver vi lige det internationale alfabet om, så
det indeholder de danske karakterer, på de pladser vi gerne vil have
dem. Men det gør det altså bare ikke...
Det er det ene eller det andet - og man må leve med konsekvenserne af
det valg man gør, uanset hvor "Mest besværligt lort at bruge." man
syntes det er. Så har man vel dybest set, valgt forkert fra
begyndelsen.
I hvert fald nytter det ikke så meget at beklage sig.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 19:22

> De danske - ÆØÅæøå findes også i utf8. Så hvis grisen har problemer, må
> det vel være fordi han ikke er konsekvent

Konsekvent med hvad ?

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 19:29

Den 09-03-2011 19:03, Birger Sørensen skrev:

> Nej, jeg bruger latin-1 (ISO-8859-1) eller latin-9 (ISO-8859-15), også i
> databaser.
> Fordi man så er ude over problemet, undtagen med AJAX, hvor det er
> enkelt at løse ...
>
> Der blev spurgt efter utf8 <-> ISO.

Ja - af mig.

Men du skal højere op i tråden for at se Scootergrisens indlæg, som
udløste det indløg.

Han skriver, at det er nemmere, hvis ens hjemmeside er i ISO 8859, end i
UTF-8, fordi PHPs funktioner internt kun kører singlebyte - og så giver
han et eksempel, dog i et senere indløg.

Det kan jeg godt forstå, han mener, hvis PHP er bygget over singlebyte,
og man så skal konvertere konstant imellem dem, bare for at kunne bruge
charset UTF-8 på sin hjemmesides HTML.

Du må vel have samme mening, siden du ikke selv kører UTF-8 heller.

MVH
Rune Jensen

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 20:03

Admin tastede følgende:
> Den 09-03-2011 19:03, Birger Sørensen skrev:
>
>> Nej, jeg bruger latin-1 (ISO-8859-1) eller latin-9 (ISO-8859-15), også i
>> databaser.
>> Fordi man så er ude over problemet, undtagen med AJAX, hvor det er
>> enkelt at løse ...
>>
>> Der blev spurgt efter utf8 <-> ISO.
>
> Ja - af mig.
>
> Men du skal højere op i tråden for at se Scootergrisens indlæg, som udløste
> det indløg.
>
> Han skriver, at det er nemmere, hvis ens hjemmeside er i ISO 8859, end i
> UTF-8, fordi PHPs funktioner internt kun kører singlebyte - og så giver han
> et eksempel, dog i et senere indløg.
>
> Det kan jeg godt forstå, han mener, hvis PHP er bygget over singlebyte, og
> man så skal konvertere konstant imellem dem, bare for at kunne bruge charset
> UTF-8 på sin hjemmesides HTML.
>
> Du må vel have samme mening, siden du ikke selv kører UTF-8 heller.
>
>
> MVH
> Rune Jensen

Lidt længere ude, end jeg har haft brug for at være...
Mener PHP gemmer værdier i variable (og det må være dem det handler
om), i det karatersæt filen gemmes som.
Så hvis man gemmer i utf8 og vil arbejde med ISO, får man et problem.

Jeg har valgt fra starten, at bruge latin-1 (før latin-9 fandtes), og
jeg har aldrig (knock on wood) haft problemer, ud over dem AJAX giver,
fordi AJAX, kun kan utf8. Jeg bruger heller JSON - der må være det
samme problem, for det kan også kun utf8. Og der er sikkert flere
tilfælde.

Så herfra hvor jeg står er det klart nemmere, at bruge latin-1.
Det er sikkert lige så nemt at bruge utf8, hvis man er konsekvent, men
man må så tage konsekvensen af at der er tilfælde, hvor tingene ikke
stemmer overens.
latin-1, er heller ikke dansk - sortering er formentlig forkert (i
forhold til det danske alfabet), og jeg ved ikke om PHP's funktioner
kan finde ud af at Æ er en stor udgave af æ. Jeg har aldrig haft brug
for det. Men den dag jeg får det, er det vel bare at kreere en fuktion
der gør tingene som ønsket (eller finde en på google). Værre er
problemet vel ikke. Og så er det vel egentlig ligegyldigt om
karaktersættet er det ene eller det andet.
Så for mig at se, er det et spørgsmål om at være konsekvent - det går
galt, hvis man forsøger at blande tingene sammen, bevidst eller
ubevidst.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Bertel Lund Hansen (10-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 10-03-11 03:22

Birger Sørensen skrev:

> Så hvis man gemmer i utf8 og vil arbejde med ISO, får man et problem.

Du har ikke helt forstået problemet. I PHP kan man slet ikke
arbejde i UTF-8. Alle funktioner er enkeltbyte-funktioner. Man
ville være nødt til at designe sin egen wrapper til dem alle for
at de kan håndtere UTF-8. Så kan man lige så godt begybde at
designe sit eget sprog [1].

At man kan få lov at oversætte én outputlinje ad gangen, er ikke
til nogen nytte i den forbindelse.

[1] eller overtale serverpersonalet til at sætte Python op som
serverscriptsprog. Det er i øvrigt et lækkert og stærkt sprog.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Admin (10-03-2011)

Kommentar
Fra : Admin

Dato : 10-03-11 04:21

Den 10-03-2011 03:22, Bertel Lund Hansen skrev:

> [1] eller overtale serverpersonalet til at sætte Python op som
> serverscriptsprog. Det er i øvrigt et lækkert og stærkt sprog.

Ville så absolut og til hver en tid foretrække Python for PHP.

Undskyld til PHP-folket, men min helt ærlige mening.

Dette er dog ønsketænkning på faktisk alle danske hosts... så din hoster
må være lidt speciel, eller tage sig godt betalt for det.

MVH
Rune Jensen

Bertel Lund Hansen (10-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 10-03-11 04:25

Admin skrev:

> Dette er dog ønsketænkning på faktisk alle danske hosts... så din hoster
> må være lidt speciel, eller tage sig godt betalt for det.

Jeg bruger PHP på mine hjemmesider, og jeg laver alting i
ISO-8859-1. Jeg har ikke nogen steder hvor jeg har brug for
UTF-8.

Jeg bruger Python som scriptsprog på mit hjemmesystem. Det er
lækkert og nemt at arbejde med. Jeg vil anbefale det til alle der
skriver programmer eller scipts.

Jeg vil da lige for sjovs skyld høre hvad Gigahost ville sige til
at installere Python på deres servere.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Admin (10-03-2011)

Kommentar
Fra : Admin

Dato : 10-03-11 04:54

Den 10-03-2011 04:24, Bertel Lund Hansen skrev:
> Admin skrev:
>
>> Dette er dog ønsketænkning på faktisk alle danske hosts... så din hoster
>> må være lidt speciel, eller tage sig godt betalt for det.
>
> Jeg bruger PHP på mine hjemmesider, og jeg laver alting i
> ISO-8859-1. Jeg har ikke nogen steder hvor jeg har brug for
> UTF-8.

XML som f.eks. AJAX, RSS feeds... XHTML (*rigtig* XHTML sendt via
application/XML, ikke det dér IE-html text/html blabberfis-noget..)
Og HTML5.

....siger mig, at UTF-8 er fremtiden :)

Derfor må et scriptsprog naturligt følge med, hvis det vil være en del
af den fremtid...

> Jeg bruger Python som scriptsprog på mit hjemmesystem. Det er
> lækkert og nemt at arbejde med. Jeg vil anbefale det til alle der
> skriver programmer eller scipts.

Jeg har brugt det (lidt), dog ikke til hjemmesider endnu, da det ikke
har været muligt at finde hoster i DK.

En sidenote; Et krav fra Google for at blive ansat dér er, man kan
Python på højt niveau. Og så kan man sige og mene meget om Google, men
de plejer at have god næse for, hvad der rør sig.
Python er også SVJV hovedsproget i Linux. Så der er altså en vis power
bag det sprog.

> Jeg vil da lige for sjovs skyld høre hvad Gigahost ville sige til
> at installere Python på deres servere.

Spændt på at høre resutatet :)

MVH
Rune Jensen

Bertel Lund Hansen (10-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 10-03-11 05:37

Admin skrev:

> En sidenote; Et krav fra Google for at blive ansat dér er, man kan
> Python på højt niveau. Og så kan man sige og mene meget om Google, men
> de plejer at have god næse for, hvad der rør sig.
> Python er også SVJV hovedsproget i Linux. Så der er altså en vis power
> bag det sprog.

Python er meget logisk opbygget med mange indbyggede kommandoer.
Det kører næsten lige så hurtigt som ren C (de skriver om ca.
90 %) og skal ikke kompileres. Desuden er der mange færdige
moduler.

Hvis Python ikke skal være det færdige sprog der bruges, så
benytter man det alligevel ofte i udviklingsfasen fordi det
nedsætter tidsforbruget til en brøkdel.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Birger Sørensen (10-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 10-03-11 10:17

Bertel Lund Hansen formulerede spørgsmålet:
> Det kører næsten lige så hurtigt som ren C (de skriver om ca.
> 90 %) og skal ikke kompileres.

CPU'en forstår Python?
Eller skal kunne, hvis der ikke skal compileres?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Stig Johansen (10-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 10-03-11 10:39

Birger Sørensen wrote:

> Bertel Lund Hansen formulerede spørgsmålet:
>> Det kører næsten lige så hurtigt som ren C (de skriver om ca.
>> 90 %) og skal ikke kompileres.
>
> CPU'en forstår Python?
> Eller skal kunne, hvis der ikke skal compileres?

Birger, er du sarkastisk? Glad

Det samme blev sagt om Transact (4GL fra '80-erne) i forhold til et
optimeret Cobol program.

De 90% er baseret på primitive operationer hvor man kun flytter data fra
f.eks. en database til noget memory.

Dette kan gøres med ganske få (fortolkede) statements.

Men prøv at lave beregninger på et flerdimensionelt array - 'and you shall
see'.

(I mit tilfælde blev det pascal, som performede bedre med en faktor 1392).

Har man ikke behov for andet end at flytte lidt data fra et sted til et
andet, skal de 90% nok holde, men husk begrænsningerne.

--
Med venlig hilsen
Stig Johansen

Birger Sørensen (10-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 10-03-11 10:56

Stig Johansen har bragt dette til verden:
> Birger Sørensen wrote:
>
>> Bertel Lund Hansen formulerede spørgsmålet:
>>> Det kører næsten lige så hurtigt som ren C (de skriver om ca.
>>> 90 %) og skal ikke kompileres.
>>
>> CPU'en forstår Python?
>> Eller skal kunne, hvis der ikke skal compileres?
>
> Birger, er du sarkastisk? Glad

> Det samme blev sagt om Transact (4GL fra '80-erne) i forhold til et
> optimeret Cobol program.
>
> De 90% er baseret på primitive operationer hvor man kun flytter data fra
> f.eks. en database til noget memory.
>
> Dette kan gøres med ganske få (fortolkede) statements.
>
> Men prøv at lave beregninger på et flerdimensionelt array - 'and you shall
> see'.
>
> (I mit tilfælde blev det pascal, som performede bedre med en faktor 1392).
>
> Har man ikke behov for andet end at flytte lidt data fra et sted til et
> andet, skal de 90% nok holde, men husk begrænsningerne.

Hej Stig.
Rart at se dig igen Flov

Det var nu mere, en forklaring på, hvordan man kan skrive i et
server-side sprog, og så mene at det ikke skal kompileres. Specielt når
man også mener det er et script-sprog.
Styrken - eller måske i virkeligheden enkeltheden i syntaxen, må da
netop ligge i compileren. Det er da der oversættelsen til maskinkode
foregår.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Stig Johansen (10-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 10-03-11 13:33

Birger Sørensen wrote:

> Det var nu mere, en forklaring på, hvordan man kan skrive i et
> server-side sprog, og så mene at det ikke skal kompileres. Specielt når
> man også mener det er et script-sprog.
> Styrken - eller måske i virkeligheden enkeltheden i syntaxen, må da
> netop ligge i compileren. Det er da der oversættelsen til maskinkode
> foregår.

Scriptsprog, og diverse 4GL sprog osv, og Java, er alle bygget på
underliggende biblioteker, som laver abstraktionslaget til CPU'en.

Kig på f.eks. PHP/ASP, og fortæl mig hvilke underliggende funktioner, der
IKKE er lavet i et kompileret sprog.

Som gl Delphi mand, så tænk på alle mulige klasser/objekter osv, som kan
ligge som prekompilerede stumper, så er opgaven blot at
1) Bygge disse klasser
2) Strikke et metasprog sammen, der benytter netop disse klasser.

Hvis du kigger godt efter kan du sikkert finde udvidelser til f.eks. PHP,
skrevet i Delphi, eller du kan lave din egen.

Det gør ikke scriptsprogene stærke, da man på andre måder kan lave et
objekt/klassehieraki, som reducerer 'kodelængden' til et minimale.

'Alt' kan reduceres til een linie:
'run'

Men til gengæld er man låst fast i denne virkemåde.

Nu er det ikke .clientside, men tænk på jQuery.

Det er nemt, og omfangsrigt, men 'it takes you far - but only THIS far', og
hvis du vil længere er du på skideren hvis man ikke behersker tingene selv.

--
Med venlig hilsen
Stig Johansen

Admin (11-03-2011)

Kommentar
Fra : Admin

Dato : 11-03-11 20:34

Den 10-03-2011 13:33, Stig Johansen skrev:

> Men til gengæld er man låst fast i denne virkemåde.
>
> Nu er det ikke .clientside, men tænk på jQuery.
>
> Det er nemt, og omfangsrigt, men 'it takes you far - but only THIS far', og
> hvis du vil længere er du på skideren hvis man ikke behersker tingene selv.

JQuery er ligesom scriptsprog beregnet til visse ting, ikke generelle
ting. Programmeringssproog som Delphi kan man lave alt i, det kan du
ikke i scriptsprog.

Derfor er hemmeligheden at bruge "det værktæj, som passer bedst til
opgaven". Og hvis opgaven ikke _kræver_ f.eks. hastigheden fra et
kompileret sprog, er der ingen grund til at bruge et kompileret sprog.

Mht. JQUery er det det samme, for brug det, hvis det kan løse opgaven,
og det iøvrigt kan betale sig i forhold til "pakken" (de dér 46kb, som
JQuery i sig selv fylder). Dvs. hvis man sparer i plads på selve
JQerykodningen i forhold til, hvad JQuery selv fylder, og performance
iøvrigt ikke er et issue.

Med scriptsprog sparer webmasteren tid på at compile, og de sprog er
nemmere at gå til, end mere handlekraftige programmeingssprog, men man
betaler med mindre performance. Med JQuery sparer man tid på selve
kodningen, og betaler så med tid i udførelsen og plads, som frameworket
fylder.

Du får intet gratis. Heller ikke i "rigtige" programmeringssprog, hvor
man må betale med tid til compileringen ved hver eneste rettelse.
Fuldstændigt åndsvagt, hvis det, du vil i virkeligheden bare er et par
includes.

MVH
Rune Jensen

Bertel Lund Hansen (10-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 10-03-11 14:22

Birger Sørensen skrev:

>> Det kører næsten lige så hurtigt som ren C (de skriver om ca.
>> 90 %) og skal ikke kompileres.

> CPU'en forstår Python?

Nej, det er et fortolket sprog. CPU'en forstår heller ikke C, så
jeg forstår ikke helt dit spørgsmål.

> Eller skal kunne, hvis der ikke skal compileres?

Ved du hvad et fortolket sprog er?

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Birger Sørensen (10-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 10-03-11 16:27

Bertel Lund Hansen har bragt dette til verden:
> Birger Sørensen skrev:
>
>>> Det kører næsten lige så hurtigt som ren C (de skriver om ca.
>>> 90 %) og skal ikke kompileres.
>
>> CPU'en forstår Python?
>
> Nej, det er et fortolket sprog. CPU'en forstår heller ikke C, så
> jeg forstår ikke helt dit spørgsmål.
>
>> Eller skal kunne, hvis der ikke skal compileres?
>
> Ved du hvad et fortolket sprog er?

Det kan være, det er et spørgsmål om ord.
For at et script skal kunne bruges til noget, skal det oversættes til
maskinkode.
Om man nu kalder det fortolkes eller compiles (eller buildes eller
linkes...), så giver den ene metode maskinkoden i hukommelsen, mens den
anden giver det som en .exe (eller .com i gamle dage).
Men uanset hvilket ben man stiller sig på, skal koden oversættes -
compileres eller fortolkes.
Og i mit hoved, er det kompileren der oversætter. Det har Python så til
fælles med PHP og ASP - og en masse andre, og for den sags skyld også
clientside scritsprog. Så hvorfor fremhæve det for Python?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Bertel Lund Hansen (10-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 10-03-11 17:40

Birger Sørensen skrev:

>> Ved du hvad et fortolket sprog er?

> Det kan være, det er et spørgsmål om ord.
> For at et script skal kunne bruges til noget, skal det oversættes til
> maskinkode.
> Om man nu kalder det fortolkes eller compiles

Det er to forskellige ting selv om den centrale proces sådan set
er den samme.

Alle sprog skrives i kode. Hvis koden skal kompileres, kan den
ikke afvikles før dette er sket. En compiler for koden som input
og producerer en exefil. Der er altså to filer at holde styr på.

Ved et fortolket sprog - også kaldet et scriptsprog - kan selve
tekstkoden afvikles (på en måde). Det fungerer naturligvis kun
ved at koden også her bliver oversat til maskinkode, men det sker
løbende. Den proces kaldes ikke kompilering, men fortolkning.

(eller buildes eller linkes...)

Builde og linke er noget lidt andet der har at gøre med at flere
afsnit skal stykkes sammen til den færdige exefil.

>, så giver den ene metode maskinkoden i hukommelsen, mens den
> anden giver det som en .exe (eller .com i gamle dage).

Det er ikke helt rigtigt. Ved et kompileret sprog bliver alt
oversat samlet, og når exefilen afvikles, ligger hele
maskinkodeprogrammet i hukommelsen (i princippet). En kompilering
kan gøres mest effektivt fordi compileren kan danne sig et
overblik over hele koden.

Ved et fortolket sprog ligger der kun lige så meget af den
oversatte kode som der er brug for lige nu - i princippet. En
moderne fortolker fylder formodentlig en hel del standardfiduser
op i hukommelsen så det kan gå lidt tjept. En fortolker er nødt
til at benytte genrelle standardrutiner så der hvert øjeblik
hurtigt kan hentes de nødvendige rutiner ind.

> Men uanset hvilket ben man stiller sig på, skal koden oversættes -
> compileres eller fortolkes.

Spørgsmålet er om det sker i ét hug (eller flere - moderne
compilere tager flere ture) eller om koden løbende nyfortolkes
hver gang den skal afvikles. Det sidste er brugervenligt fordi
der kun er én fil at holde styr på.

Java laver en mellemting melem de to principper fordi den
prækompilerer til et system som de kalder bytekode. Det er ikke
maskinkode, men er en effektivisering og en form for komprimering
så den egentlige afvikling kan gå meget hurtigere.

> Og i mit hoved, er det kompileren der oversætter. Det har Python så til
> fælles med PHP og ASP - og en masse andre, og for den sags skyld også
> clientside scritsprog. Så hvorfor fremhæve det for Python?

Nu var det jo altså Python jeg skrev om. Det er en egenskab ved
Python, så derfor skrev jeg det - og så også fordi det er
usædvanligt at et fortolket sprog kører så hurtigt som Python
gør.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Birger Sørensen (10-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 10-03-11 19:35

Bertel Lund Hansen udtrykte præcist:
> Birger Sørensen skrev:
>
>>> Ved du hvad et fortolket sprog er?
>
>> Det kan være, det er et spørgsmål om ord.
>> For at et script skal kunne bruges til noget, skal det oversættes til
>> maskinkode.
>> Om man nu kalder det fortolkes eller compiles
>
> Det er to forskellige ting selv om den centrale proces sådan set
> er den samme.
>
> Alle sprog skrives i kode. Hvis koden skal kompileres, kan den
> ikke afvikles før dette er sket. En compiler for koden som input
> og producerer en exefil. Der er altså to filer at holde styr på.
>
> Ved et fortolket sprog - også kaldet et scriptsprog - kan selve
> tekstkoden afvikles (på en måde). Det fungerer naturligvis kun
> ved at koden også her bliver oversat til maskinkode, men det sker
> løbende. Den proces kaldes ikke kompilering, men fortolkning.
>
> (eller buildes eller linkes...)
>
> Builde og linke er noget lidt andet der har at gøre med at flere
> afsnit skal stykkes sammen til den færdige exefil.
>
>> , så giver den ene metode maskinkoden i hukommelsen, mens den
>> anden giver det som en .exe (eller .com i gamle dage).
>
> Det er ikke helt rigtigt. Ved et kompileret sprog bliver alt
> oversat samlet, og når exefilen afvikles, ligger hele
> maskinkodeprogrammet i hukommelsen (i princippet). En kompilering
> kan gøres mest effektivt fordi compileren kan danne sig et
> overblik over hele koden.
>
> Ved et fortolket sprog ligger der kun lige så meget af den
> oversatte kode som der er brug for lige nu - i princippet. En
> moderne fortolker fylder formodentlig en hel del standardfiduser
> op i hukommelsen så det kan gå lidt tjept. En fortolker er nødt
> til at benytte genrelle standardrutiner så der hvert øjeblik
> hurtigt kan hentes de nødvendige rutiner ind.
>
>> Men uanset hvilket ben man stiller sig på, skal koden oversættes -
>> compileres eller fortolkes.
>
> Spørgsmålet er om det sker i ét hug (eller flere - moderne
> compilere tager flere ture) eller om koden løbende nyfortolkes
> hver gang den skal afvikles. Det sidste er brugervenligt fordi
> der kun er én fil at holde styr på.
>
> Java laver en mellemting melem de to principper fordi den
> prækompilerer til et system som de kalder bytekode. Det er ikke
> maskinkode, men er en effektivisering og en form for komprimering
> så den egentlige afvikling kan gå meget hurtigere.
>
>> Og i mit hoved, er det kompileren der oversætter. Det har Python så til
>> fælles med PHP og ASP - og en masse andre, og for den sags skyld også
>> clientside scritsprog. Så hvorfor fremhæve det for Python?
>
> Nu var det jo altså Python jeg skrev om. Det er en egenskab ved
> Python, så derfor skrev jeg det - og så også fordi det er
> usædvanligt at et fortolket sprog kører så hurtigt som Python
> gør.

Det er så også en egenskab ved PHP og ASP - og alle de andre
scriptsprog.
Det du mener må så være at Pythons fortolker laver kode der køres
hurtigere end de andres.
PHP (som er det jeg kender), har også en masse indbyggede kommandoer og
funktioner, så der skiller python sig heller ikke ud.
Og af det jeg har set, er det ikke min opfattelse, at det er specielt
nemmere forståeligt eller mere overskueligt.
Jeg har heller aldrig oplevet at PHP giver lange eksekveringstider.
Eneste rigtige problem jeg har haft med det, er hukommelsesforbrug ved
billedbehandling. Det var så one.com's opsætning, og deres politiker
der reelt gav problemet, så det kan man ikke laste PHP for. Skal siges,
at jeg skriver ikke vanvittigt store applicationer i PHP.

Så alt i alt, siger jeg ikke, at Python er hverken bedre eller
dårligere end de andre - men jeg syntes argumenter du giver er lidt
søgte - og ikke helt rigtige, hvis formålet er at reklamere for Python,
frem for andre...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Admin (11-03-2011)

Kommentar
Fra : Admin

Dato : 11-03-11 00:20

Den 10-03-2011 19:34, Birger Sørensen skrev:

> Det er så også en egenskab ved PHP og ASP - og alle de andre scriptsprog.

Hvis Python afvikles generelt hurtigere end ASP og PHP, så er hastighed
en egenskab ved Python, som ASP og PHP ikke har.

Der er vel meget forståeligt skrevet...

Nuvel, .NET f.eks., som bruges til bl.a. hjemmesider, kan compiles, og
i så fald kører det formentlig en del hurtigere end Python og andre
fortolkede srog. Men det HTML-kode, som .NET i sidste ende spytter ud,
minder om Frontpagekode fra sluthalvfemserne, bare på et højere niveau.
Altså ren slamkode, med viewstate som det mest pinlige slam.

Pythin kan også kompiles, så kører det også hurigere, men jeg ved ikke
særligt meget om det, om det kan bruges til hjemmesider i compiled
form- Python er både et programmeringssprog og et scriptsprog.

> Det du mener må så være at Pythons fortolker laver kode der køres
> hurtigere end de andres.

Sådan opfatter jeg Bertels skriv.

> PHP (som er det jeg kender), har også en masse indbyggede kommandoer og
> funktioner, så der skiller python sig heller ikke ud.

PHP er, som jeg har set det en gang smadder oveni noget andet smadder
Eller man kan kalde det lap på lap. Jeg synes på ingen måde overhovedet
det er logisk, tværtimod. Og det er ikke fordi ASP (VBScript i denne
forb.) på nogen måde er logisk, men det er sgu langt langt mere logisk
end PHP er. Til gengæld er ASP også et skodsprog hvad angår indbyggede
funktioner, og det halter på hastighed. Det stiller heller ikke særloge
krav til "programmøren", udover, man kan sætte en flag, så der kræves,
man dimensionerer sine variable (en god ting trods alt), men virker
ikke på hele programmet, kun den del, som fortolkes.

Python er bygget helt fra start over nogle best ppractices, sådan man er
tvunget til at lave logiske indrykninger. Det tvinger én til at
følge best practice, ellers virker programmet bare ikke.

Såvidt jeg ved, så er Python iøvrigt et ægte objektoriennteret sprog.

MVH
Rune Jensen

Andreas Andersen (12-03-2011)

Kommentar
Fra : Andreas Andersen

Dato : 12-03-11 12:36

Den 11-03-2011 00:19, Admin skrev:
> Nuvel, .NET f.eks., som bruges til bl.a. hjemmesider, kan compiles, og
> i så fald kører det formentlig en del hurtigere end Python og andre
> fortolkede srog. Men det HTML-kode, som .NET i sidste ende spytter ud,
> minder om Frontpagekode fra sluthalvfemserne, bare på et højere niveau.
> Altså ren slamkode, med viewstate som det mest pinlige slam.

Har du nogensinde forsøgt at lave noget i .NET? Hvis man har Windows på
sin webserver, er det overordentligt svært at komme uden om .NET som det
oplagte valg til programmering af serverside-kode. Det kræver, at man
har lidt tålmodighed til at sætte sig ind i, hvordan det fungerer, så
man ikke får spyttet 1 megabyte viewstate ud, men når man har gjort det,
er der intet i vejen for at generere kode, der ser ud præcis som man
ønsker, og det bliver altså afviklet flere gange hurtigere end noget
fortolket scriptsprog.

--
Andreas

Admin (12-03-2011)

Kommentar
Fra : Admin

Dato : 12-03-11 13:10

Den 12-03-2011 12:35, Andreas Andersen skrev:

> Har du nogensinde forsøgt at lave noget i .NET?

Nej.

> Hvis man har Windows på
> sin webserver

Det har jeg, men jeg har ikke Windows derhjemme. Og det får jeg heller
aldrig mere...

Uden at betale til Microsoft for en Windows, kan jeg ikke compile,
derfor heller ikke køre NET på egen PC. Ikke fordi jeg ville, men
muligheden er der altså heller ikke.

> Det kræver, at man
> har lidt tålmodighed til at sætte sig ind i, hvordan det fungerer, så
> man ikke får spyttet 1 megabyte viewstate ud, men når man har gjort det,
> er der intet i vejen for at generere kode, der ser ud præcis som man
> ønsker,

Det er ikke hvad jeg har læst, ejheller hvad jeg har hørt fra andre,
eller hvad jeg kan se ud fra hvad "professionelle" laver (selv MS kan
ikke finde ud af deres eget sprog). Frameworket har altid det sidste
ord, lige meget hvad, og det kan jeg ikke bruge.

> og det bliver altså afviklet flere gange hurtigere end noget
> fortolket scriptsprog.

Det har du helt ret i :) Og har man brug for egentlig programmering til
sin hjemmeside, er der i DK ikke andre muligheder end .NET, hvis det
skal væære til at betale.

Det betyder bare ikke, at .NET er det bedste, ejheller det hurtigste
compiled sprog. Der er andre compiled sprog, de findes bare ikke i DK
til en overkommelig pris (via hoster - man kan selvfølgelig selv hoste
det, men det gider jeg ikke).

Det er forkert at tro, at fordi NET er mest udbredt i DK, så er det også
det bedste/hurtigste compiled sprog. Windows er også mere udbredt end
Linux, men stadig er Windows ca. 3 gange så langsomt som Linux, og tager
dobbelt så mange ressourcer.

MVH
Rune Jensen

Andreas Andersen (12-03-2011)

Kommentar
Fra : Andreas Andersen

Dato : 12-03-11 13:37

Den 12-03-2011 13:09, Admin skrev:
> Det er ikke hvad jeg har læst, ejheller hvad jeg har hørt fra andre,
> eller hvad jeg kan se ud fra hvad "professionelle" laver (selv MS kan
> ikke finde ud af deres eget sprog). Frameworket har altid det sidste
> ord, lige meget hvad, og det kan jeg ikke bruge.

Det er altså lodret forkert, men det lyder som om din mening er fastlåst...

>> og det bliver altså afviklet flere gange hurtigere end noget
>> fortolket scriptsprog.
>
> Det har du helt ret i :) Og har man brug for egentlig programmering til
> sin hjemmeside, er der i DK ikke andre muligheder end .NET, hvis det
> skal væære til at betale.
>
> Det betyder bare ikke, at .NET er det bedste, ejheller det hurtigste
> compiled sprog. Der er andre compiled sprog, de findes bare ikke i DK
> til en overkommelig pris (via hoster - man kan selvfølgelig selv hoste
> det, men det gider jeg ikke).

Jeg ved ikke lige, hvilke sprog, du taler om, men jeg har vist heller
ikke påstået, at IL-kode er det hurtigst afviklede kode i verden. Kun at
det er væsentligt hurtigere end scriptsprog.

> Det er forkert at tro, at fordi NET er mest udbredt i DK, så er det også
> det bedste/hurtigste compiled sprog. Windows er også mere udbredt end
> Linux, men stadig er Windows ca. 3 gange så langsomt som Linux, og tager
> dobbelt så mange ressourcer.

3 gange så langsomt... Det var noget af en påstand. Hvad mener du præcis
med "3 gange så langsomt"?

Jeg kan godt lide ideen med Linux, og har haft det installeret af flere
omgange, men jeg ender altid med at miste tålmodigheden. Der skal altid
liiiige rettes en config-fil eller downloades en driver, man selv skal
kompilere, men som ikke kan kompilere, fordi man mangler et eller andet
library, man bruger 3 timer på at finde i den rigtige version.

--
Andreas

Admin (12-03-2011)

Kommentar
Fra : Admin

Dato : 12-03-11 15:02

Den 12-03-2011 13:36, Andreas Andersen skrev:

> Jeg ved ikke lige, hvilke sprog, du taler om, men jeg har vist heller
> ikke påstået, at IL-kode er det hurtigst afviklede kode i verden. Kun at
> det er væsentligt hurtigere end scriptsprog.

Jeg ved ikke, hvor hurtigt Python kører compiled, men det kan lade sig gøre.

>> Det er forkert at tro, at fordi NET er mest udbredt i DK, så er det også
>> det bedste/hurtigste compiled sprog. Windows er også mere udbredt end
>> Linux, men stadig er Windows ca. 3 gange så langsomt som Linux, og tager
>> dobbelt så mange ressourcer.
>
> 3 gange så langsomt... Det var noget af en påstand. Hvad mener du præcis
> med "3 gange så langsomt"?

Mit system har 1GB RAM. Før lå der Vista på den. Jeg var nødt til at slå
samtlige grafiske effekter fra (at køre i Win98-modus) for overhovedet
at have noget, der *nogenlunde* var til at holde ud, når der skulle
køres programmer. Men så var der åbning af programmer - ca. 20-30
sekunder om åbning selv i varmstart..

Kravet til Vista er officielt 512MB for min version.
http://windows.microsoft.com/en-us/windows-vista/products/system-requirements

I realiteten er det langt langt højere, nok minimum 4GB. Og Microsoft
har selv indrømmet, at de snød så vandet drev med kravene til Vista (for
at tækkes Intel, som havde nogle gamle lortechips, de ville af med).
Dvs. de snød brugerne med vilje og løj for dem, men ikke bare det.
Systemet i sig selv var fejlhæftet og bloated.
http://www.bloomberg.com/apps/news?pid=newsarchive&sid=aakoxXKmuWwU

Ressourceforbruget er estimeret. Jeg har nu en Kubuntu kørende med fuld
Compiz (effekterne er _meget_ federe end Vista og Win7), systemet kører
glat, bruger nærmest intet hukommelse, og er yderst responsivt.
Koldstart af f.eks. Chrome max. 3-4 sekunder, varmstart ca 0-2 sekund...
Alle effekter er der med det samme; F.eks. rotering af de fire
skriveborde i 3D cubus, vise vinduerne i 3D "ring" og selve effekterne
på vinduerne (wobbling windows f.eks. - fed effekt) og det rent grafiske
med skygger, gennemsigtighed mv. har ingen problemer.

Kravene til Kubuntu er 256MB RAM (absolut minimum 128MB) - korrekte tal,
ikke en fed løgn som Microsoft.
http://www.buzzle.com/articles/kubuntu-system-requirements.html

> Jeg kan godt lide ideen med Linux, og har haft det installeret af flere
> omgange, men jeg ender altid med at miste tålmodigheden. Der skal altid
> liiiige rettes en config-fil eller downloades en driver, man selv skal
> kompilere, men som ikke kan kompilere, fordi man mangler et eller andet
> library, man bruger 3 timer på at finde i den rigtige version.

Min erfaring er helt anderledes. Det hele virkede fra start med både
Ubuntu, xUbuntu, Kubuntu og Linux Mint. Derimod, så havde Vista svært
ved at acceptere min USB, det var intet problem for Linux. Desuden er
det da vidst anerkendt, at Vista ikke var god til at genkende nogetsomhelst.

Måske det er lidt tid siden, du forsøgte dig med Linux :)

Forskellen er slet ikke dér, men i filsystemet og i den måde man
installerer (fra Software Center). Det er det eneste, som man skal bruge
lidt tid på at lære. Jeg kører med et XP-theme, så min Linux ligner
fuldstændigt (og opfører sig som) en Windows XP ud over det.

MVH
Rune Jensen

Andreas Andersen (12-03-2011)

Kommentar
Fra : Andreas Andersen

Dato : 12-03-11 15:52

Den 12-03-2011 15:02, Admin skrev:
> Mit system har 1GB RAM. Før lå der Vista på den. Jeg var nødt til at slå
> samtlige grafiske effekter fra (at køre i Win98-modus) for overhovedet
> at have noget, der *nogenlunde* var til at holde ud, når der skulle
> køres programmer. Men så var der åbning af programmer - ca. 20-30
> sekunder om åbning selv i varmstart..
>
> Kravet til Vista er officielt 512MB for min version.
> http://windows.microsoft.com/en-us/windows-vista/products/system-requirements
>
>
> I realiteten er det langt langt højere, nok minimum 4GB. Og Microsoft
> har selv indrømmet, at de snød så vandet drev med kravene til Vista (for
> at tækkes Intel, som havde nogle gamle lortechips, de ville af med).
> Dvs. de snød brugerne med vilje og løj for dem, men ikke bare det.
> Systemet i sig selv var fejlhæftet og bloated.
> http://www.bloomberg.com/apps/news?pid=newsarchive&sid=aakoxXKmuWwU

Ja, Vista var ikke noget at være stolt af. XP har jeg dog aldrig haft
problemer med, og Windows 7 er jeg ret begejstret for.

> Måske det er lidt tid siden, du forsøgte dig med Linux :)

Det er 5 år siden, jeg havde det installeret sidst. Dengang var det
enten noget Fedora (og før det Red Hat) eller XP. XP fungerede bare, det
gjorde Fedora altså ikke. Men ja, 5 år er lang tid.

--
Andreas

Admin (12-03-2011)

Kommentar
Fra : Admin

Dato : 12-03-11 17:15

Den 12-03-2011 15:52, Andreas Andersen skrev:

> XP har jeg dog aldrig haft
> problemer med,

Windows XP er det mest brugervenlige system. Ikke det hurtigste, men
mest brugervenlige. Hvilket er årsagen til, jeg har et XP theme til min
Linux.

> og Windows 7 er jeg ret begejstret for.

Mit pproblem med Windows 7 er, at det for mig vil være som når
bilsælgeren siger til kunden "Det var vel nok ærgerligt, at den bil jeg
solgte dig kun kører 2km på literen, selv om jeg sagde 20km, og at
max-hastigheden kun er 30km/t selv om jeg sagde 200km/t. Men nu skal du
se... jeg har en helt ny model, som helt sikkert kan det, jeg sagde. Den
kan du købe for den samme pris..."

Det var her, filmen knækkede for mig, og jeg lavede et løfte om aldrig
mere nogensinde at betale til MS.

Der er - grundlæggende - intet du kan lave med Windows, som du ikke også
kan lave med Linux. Forskellen er bare, at Linux gør det hurtigere, og
gratis.

Det er selvfølgelig subjektivt, men jeg vil også vove at påstå, at Linux
stadig er mindre bloated og hurtigere end Windows 7. Minimumskravet
(hvis MS da ikke lyver som sædvanligt) er officielt 1GB RAM, hvor
Kubuntu kan nøjes med 256MB:
http://www.microsoft.com/windows/windows-7/get/system-requirements.aspx

MVH
Rune Jensen

Admin (12-03-2011)

Kommentar
Fra : Admin

Dato : 12-03-11 15:14

Den 12-03-2011 13:36, Andreas Andersen skrev:
> Den 12-03-2011 13:09, Admin skrev:
>> Det er ikke hvad jeg har læst, ejheller hvad jeg har hørt fra andre,
>> eller hvad jeg kan se ud fra hvad "professionelle" laver (selv MS kan
>> ikke finde ud af deres eget sprog). Frameworket har altid det sidste
>> ord, lige meget hvad, og det kan jeg ikke bruge.
>
> Det er altså lodret forkert, men det lyder som om din mening er fastlåst...

http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx

Der spørges:

"
How can I get rid of ViewState completely. I am using pure AJAX
callbacks in javascript for everything. I just don't want those hidden
inputs at all. Is it possible.
"

....og der svares:

"
The only way to drop the hidden fields completely is to not have a form,
or at least not one with runat="server". Some controls require one
though, so may not be feasible if you are using them.
"

....lyder bestemt ikke for mig, som om man kan kontrollere nogetsomhelst,
hvis man har en form. Man kan ikke slippe for det 100%, ergo har man
ikke fuld kontrol.

MVH
Rune Jensen

Andreas Andersen (12-03-2011)

Kommentar
Fra : Andreas Andersen

Dato : 12-03-11 15:45

Den 12-03-2011 15:14, Admin skrev:
> "
> The only way to drop the hidden fields completely is to not have a form,
> or at least not one with runat="server". Some controls require one
> though, so may not be feasible if you are using them.
> "
>
> ...lyder bestemt ikke for mig, som om man kan kontrollere nogetsomhelst,
> hvis man har en form. Man kan ikke slippe for det 100%, ergo har man
> ikke fuld kontrol.

Det er rigtigt, at hvis man har en <form runat="server"> kan man ikke
100% slippe for viewstate. Det er fordi viewstaten bruges til at styre
postback fra formen og fyre events og den slags. Man kan dog sagtens
have forms uden runat="server" og så fungerer de bare som almindelige
forms, som man kan læse data fra ved postback - præcis ligesom man
gjorde i det gamle ASP, hvis du har brugt det.

Jeg kan dog ikke se nogen særlig grund til, at man skulle være religiøs
omkring helt at undgå viewstate. Det giver adgang til noget ganske smart
funktionalitet i .NET. Hvis det bruges rigtigt, fylder det ikke alverden
- de meget store viewstates du ser rundt omkring er fra folk, der ikke
forstår at bruge det rigtigt.

--
Andreas

Admin (12-03-2011)

Kommentar
Fra : Admin

Dato : 12-03-11 17:22

Den 12-03-2011 15:44, Andreas Andersen skrev:

> Jeg kan dog ikke se nogen særlig grund til, at man skulle være religiøs
> omkring helt at undgå viewstate. Det giver adgang til noget ganske smart
> funktionalitet i .NET. Hvis det bruges rigtigt, fylder det ikke alverden
> - de meget store viewstates du ser rundt omkring er fra folk, der ikke
> forstår at bruge det rigtigt.

Det er jeg klar over, men min anke går også på, at systemet i sig selv
ikke lægger op til en best practice.

*Hvis* det gjorde det, så var viewstate helt slået væk pr. default, og
man sulle selv slå det til.

Jeg har måske nogle underlige krav til et serverside sprog, ud over at
jeg foretrækker håndkodning. Men jeg vil have, det skal være
overskueligt, og man skal kunne kontrollere alt - og jeg mener alt -
100% selv. Der må ikke være noget, som er sat som default, som så går
ind og laver noget, jeg ikke har bedt om.

Og så må sproget også gerne være lavet, så det lægger op til pæn
kodning. Python har krav om indrykning, men der kan være mange andre
ting. Jo mere strict des bedre.

MVH
Rune Jensen

Andreas Andersen (12-03-2011)

Kommentar
Fra : Andreas Andersen

Dato : 12-03-11 20:21

Den 12-03-2011 17:21, Admin skrev:
> Det er jeg klar over, men min anke går også på, at systemet i sig selv
> ikke lægger op til en best practice.
>
> *Hvis* det gjorde det, så var viewstate helt slået væk pr. default, og
> man sulle selv slå det til.
>
> Jeg har måske nogle underlige krav til et serverside sprog, ud over at
> jeg foretrækker håndkodning. Men jeg vil have, det skal være
> overskueligt, og man skal kunne kontrollere alt - og jeg mener alt -
> 100% selv. Der må ikke være noget, som er sat som default, som så går
> ind og laver noget, jeg ikke har bedt om.

Fair nok, smag og behag er jo forskellige.

> Og så må sproget også gerne være lavet, så det lægger op til pæn
> kodning. Python har krav om indrykning, men der kan være mange andre
> ting.Jo mere strict des bedre.

Nu kender jeg ikke ret meget til Python, men har det ikke dynamiske
typer? Det burde du da hade med den holdning Blink

--
Andreas

Stig Johansen (14-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 14-03-11 18:02

Andreas Andersen wrote:

> 3 gange så langsomt... Det var noget af en påstand. Hvad mener du præcis
> med "3 gange så langsomt"?

Nu er vi lidt ude i bit-flækkeriet, men hvis man har adgang til egne
servere, og 'rigtige' compilere, så er her lidt historie.

'Der var engang...' - ja sådan starter alle historier, men vi snakker æraen
hvor Linux thrads kørte efter 'fork-modellen'.

I denne æra var multithreaded 'ting' faktisk hurtigere på Windows end på
linux.

(Her taler jeg om tiden for at spawne nye threads).

Jeg husker ikke det præcise årstal, men omkring 2003-2005 kom NPTL, hvor jeg
har både HP og IBM _stærkt_ mistænkt for at have ydet bidrag.

Hver især har de spyttet mia. af $ i Linux, for at tilbyde Linux på high-end
udstyr.

Jeg har engang lavet noget HPC med brug af NPTL, og fy for s*.. det sparker
røv.

Vi snakker ikke en faktor 3, nærmere faktor 1:100 mellem Windows threads og
NPTL.

MEN det er stadig et trade-off.
Hvis man vil udnytte den, som vi kalder det: 'insane performance', så kræver
det mere indsigt end 'scriptsprog'.

--
Med venlig hilsen
Stig Johansen

Bertel Lund Hansen (11-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 11-03-11 08:49

Admin skrev:

> Såvidt jeg ved, så er Python iøvrigt et ægte objektoriennteret sprog.

Ikke helt op til version 2. I version 3 er det lavet strengt
objektorienteret. Der er flere andre ændringer i 3'eren. 3-kode
er ikke kompatibelt med 2-kode.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Admin (11-03-2011)

Kommentar
Fra : Admin

Dato : 11-03-11 19:46

Den 11-03-2011 08:48, Bertel Lund Hansen skrev:
> Admin skrev:
>
>> SÃ¥vidt jeg ved, sÃ¥ er Python iÃ¸vrigt et Ã¦gte objektoriennteret sprog.
>
> Ikke helt op til version 2. I version 3 er det lavet strengt
> objektorienteret. Der er flere andre Ã¦ndringer i 3'eren. 3-kode
> er ikke kompatibelt med 2-kode.

OK. Objekorienteret var et af mine krav til nyt sprog, da jeg kiggede pÃ¥
det, og faldt over Python.

Kravet om strict kodning, hvor Python sÃ¥ har krev om indrykning,
tiltalte mig meget. Mener ikke sÃ¥ mange andre sprog har det. Det tvinger
koderen imod en best practice, som f.eks. er det fuldstÃ¦ndigt modsatte i
..NET, hvor der opfordres til bloatkodning (ogsÃ¥ fordi .NET er visuelt,
krÃ¦ver en bestemt editor).

Jeg valgte iÃ¸vrigt styresystem udfra samme princip, at OSet fremmer best
practice. Linux er bortset fra at vÃ¦re pissehurtigt, ogsÃ¥ bygget pÃ¥ best
practice omkring skkerhed. Man kan aldrig vÃ¦re logget ind som root fra
start, som á¸¿an kan pÃ¥ Win med fuld admin-tilgang. Det var fÃ¸rst da jeg
kom pÃ¥ Linux, jeg rigtigt fandt ud af, hvad en admin-konto er.

SÃ¥ gÃ¸r det jo heller ikke dÃ¥rligere, at Python er "native" til Linux,
ogsÃ¥ en grund til at vÃ¦lge Python fremfor andre.

Ã†ndrer selvÃ¸lgelig ikke pÃ¥, at scriptsprog stadig er meget langsommere
end compiled sprog, det er der ikke noget underligt i.

MVH
Rune Jensen

Bertel Lund Hansen (10-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 10-03-11 22:45

Birger Sørensen skrev:

> PHP (som er det jeg kender), har også en masse indbyggede kommandoer og
> funktioner, så der skiller python sig heller ikke ud.

Python er konsekvent. PHP er noget spaghettinoget. Man er nødt
til at slå op i manualen ustandselig fordi halvdelen af gangene
er rækkefølgen (needle,haystack), og den anden halvdel er det
(haystack,needle). Det er smadderirriterende. Desuden roder det
rundt i typerne så det er nødvendigt med 3 forskellige slags
lighedstegn.

Men det er rigtigt at PHP har mange nyttige funktioner og
bibliotker.

> Så alt i alt, siger jeg ikke, at Python er hverken bedre eller
> dårligere end de andre -

I Python er alt det overflødige skrællet af. En linje slutter når
den slutter. Der skal ikke hægtes et sluttegn på. Og en rar ting
er at indrykningen har syntaktisk betydning. Desuden har det
automatisk gennemløb af mange forskellige slags. PHP har kun
foreach () foruden den almindelige for-løkke.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Stig Johansen (11-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 11-03-11 09:48

Bertel Lund Hansen wrote:

> (eller buildes eller linkes...)
>
> Builde og linke er noget lidt andet der har at gøre med at flere
> afsnit skal stykkes sammen til den færdige exefil.

Hov, i glemte at nogle bruger bind Glad

> En kompilering
> kan gøres mest effektivt fordi compileren kan danne sig et
> overblik over hele koden.

For ikke at glemme optimizeren, som er vigtig i større systemer.

> Spørgsmålet er om det sker i ét hug (eller flere - moderne
> compilere tager flere ture)

Det er heller ikke helt rigtigt.
Spørgsmålet om singlepass eller multipass handler lidt om hvor stringent
sproget er.

Delphi (pascal) har en meget stram opbygning, der gør at man kan bruge
singlepass kompilering.

c, f.eks. hvor man kan pladre definitioner rundt omkring kræver multipass,
og det er derfor det er så p*sse langsomt.

Man kan betragte det som en fordel, men i min optik svarer det til ikke at
kunne stave rigtigt.

> Java laver en mellemting melem de to principper fordi den
> prækompilerer til et system som de kalder bytekode. Det er ikke
> maskinkode, men er en effektivisering og en form for komprimering
> så den egentlige afvikling kan gå meget hurtigere.

Njaah, Java er en kompilering til bytecode, i stedet for maskinkode.
Problemet med java og andre pcode 'ting' er det mellemliggende
abstraktionslag, der nedsætter performance drastisk (bortset fra simple
ting).

>> Og i mit hoved, er det kompileren der oversætter. Det har Python så til
>> fælles med PHP og ASP - og en masse andre, og for den sags skyld også
>> clientside scritsprog. Så hvorfor fremhæve det for Python?

ALT bliver kompileret, det er kun et spørgsmål om hvornår - og til hvad.

Problemet med scriptsprog er, at de skal kompileres hver gang man skal køre
dem.

For at optimere findes der nogle mekanismer i f.eks ASP og PHP, hvor nogle
ting gemmes som prekompilerede enheder.

--
Med venlig hilsen
Stig Johansen

Andreas Andersen (12-03-2011)

Kommentar
Fra : Andreas Andersen

Dato : 12-03-11 12:43

Den 11-03-2011 09:47, Stig Johansen skrev:
> ALT bliver kompileret, det er kun et spørgsmål om hvornår - og til hvad.

Hvis man ikke vil skelne imellem den eksplicitte kompilering imellem to
sprog og den implicitte kompilering en fortolker foretager, leger man
vist bare trodsig.

--
Andreas

Admin (12-03-2011)

Kommentar
Fra : Admin

Dato : 12-03-11 13:37

Den 12-03-2011 12:42, Andreas Andersen skrev:
> Den 11-03-2011 09:47, Stig Johansen skrev:
>> ALT bliver kompileret, det er kun et spørgsmål om hvornår - og til hvad.
>
> Hvis man ikke vil skelne imellem den eksplicitte kompilering imellem to
> sprog og den implicitte kompilering en fortolker foretager, leger man
> vist bare trodsig.

At sammenligne fortolkede sprog med compiled sprog, er vel lidt som at
sammenligne Commodore 64 Basic med 6502 maskinkode.

Man bruger de compiled sprog til at lave de fortolkede sprog, så er det
klart, der kommer et ekstra lag på de fortplkede hver gang.

MVH
Rune Jensen

Bertel Lund Hansen (12-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 12-03-11 15:40

Admin skrev:

> Man bruger de compiled sprog til at lave de fortolkede sprog, så er det
> klart, der kommer et ekstra lag på de fortplkede hver gang.

Hvordan fortolkeren er opbygget og fungerer, er bestemt af dens
kildekode og ikke af hvordan den tilsvarende compier er opbygget.

Problemet ved et fortolket sprog er at der skal laves et
kompromis mellem oversættelseshastighed og afviklingshastighed -
hvor jeg med oversættelseshastighed mener den tid det tager at
præparere et stykke maskinkode i hukommelsen, og med
afviklingshastighed mener den tid det tager at afvikle en
præpareret maskinkodeblok. Jo kortere det ene tidsrum skal være,
jo længere bliver det andet. Derfor vil et kompileret sprog kunne
laves hurtigere end et fortolket.

Men der er ikke noget med nogen ekstra lag. Både compileren og
fortolkeren griber ned i en værktøjspose med færdige rutiner.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Bertel Lund Hansen (11-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 11-03-11 11:09

Stig Johansen skrev:

> ALT bliver kompileret, det er kun et spørgsmål om hvornår - og til hvad.

Jeg siger bare ikke "kompilere" om den proces der foregår under
kørslen.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Birger Sørensen (11-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 11-03-11 12:16

Bertel Lund Hansen skrev den 11-03-2011:
> Stig Johansen skrev:
>
>> ALT bliver kompileret, det er kun et spørgsmål om hvornår - og til hvad.
>
> Jeg siger bare ikke "kompilere" om den proces der foregår under
> kørslen.

Som sagt, er det et spørgsmål om ord. Flov

Hvis koden ikke "kompileres" mindst een gang, kan den ikke bruges til
noget.
http://da.wikipedia.org/wiki/Compiler

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Bertel Lund Hansen (11-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 11-03-11 13:36

Birger Sørensen skrev:

> Som sagt, er det et spørgsmål om ord. Flov

Hvis ord er ligegyldige, hvorfor hedder altiong så ikke bare det
samme. Så ville det være nemmere at lære at stave.

> Hvis koden ikke "kompileres" mindst een gang, kan den ikke bruges til
> noget.
> http://da.wikipedia.org/wiki/Compiler

Der står det samme som jeg siger.

Bemærk f.eks. første linje og der hvor der står at Java
kompilerer til bytekode som *fortolkes* (ikke kompileres) af JVM.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Birger Sørensen (11-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 11-03-11 14:38

Bertel Lund Hansen tastede følgende:
> Birger Sørensen skrev:
>
>> Som sagt, er det et spørgsmål om ord. Flov

>
> Hvis ord er ligegyldige, hvorfor hedder altiong så ikke bare det
> samme. Så ville det være nemmere at lære at stave.

Det er vist mere et spørgsmål om, at forskellige mennesker bruge samme
ord om forkellige ting.

>> Hvis koden ikke "kompileres" mindst een gang, kan den ikke bruges til
>> noget.
>> http://da.wikipedia.org/wiki/Compiler
>
> Der står det samme som jeg siger.
>
> Bemærk f.eks. første linje og der hvor der står at Java
> kompilerer til bytekode som *fortolkes* (ikke kompileres) af JVM.

Gør der? Java - kildekoden - *kompileres* til bytekode...
Men det var ikke pointen.
Du påstår Python ikke skal kompileres - det er der ingen scripting der
skal, med den betydning af ordene - de bliver alle sammen fortolket.
Hvorfor så fremhæve det som noget særligt for Python?

Iflg. linket er en compiler et program der oversætter din kildekode til
noget der kan anvendes enten af andet software eller direkte til kode
CPU'en forstår (maskinkode).
Med den betydning skal de alle sammen kompileres - også Python.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Bertel Lund Hansen (11-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 11-03-11 15:59

Birger Sørensen skrev:

> Gør der? Java - kildekoden - *kompileres* til bytekode...

Ja. Derefter fortolkes bytekoden under kørslen. Det var derfor
jeg skrev at Java er en mellemting. Det er både et kompileret og
et fortolket sprog.

> Du påstår Python ikke skal kompileres - det er der ingen scripting der
> skal, med den betydning af ordene - de bliver alle sammen fortolket.

Det er korrekt.

> Hvorfor så fremhæve det som noget særligt for Python?

Har jeg fremhævet det? Jeg fortæller det blot.

> Iflg. linket er en compiler et program der oversætter din kildekode til
> noget der kan anvendes enten af andet software eller direkte til kode
> CPU'en forstår (maskinkode).

Nej. En compiler er et program der oversætter kildekoden til en
*fil* der består af maskinkode:

   En compiler (også kaldet kompiler eller oversætter) er et
   program, der oversætter et andet program (kaldet kildekoden)
   til et tredje program.

> Med den betydning skal de alle sammen kompileres - også Python.

Niks.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

Birger Sørensen (11-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 11-03-11 16:09

Følgende er skrevet af Bertel Lund Hansen:
>> Iflg. linket er en compiler et program der oversætter din kildekode til
>> noget der kan anvendes enten af andet software eller direkte til kode
>> CPU'en forstår (maskinkode).
>
> Nej. En compiler er et program der oversætter kildekoden til en
> *fil* der består af maskinkode:
>
>    En compiler (også kaldet kompiler eller oversætter) er et
>    program, der oversætter et andet program (kaldet kildekoden)
>    til et tredje program.
>

Der står ikke noget om at det skal være en i en fil.
Hvad bliver et program i en fil til, når det hentes ind i hukommelsen?

>> Med den betydning skal de alle sammen kompileres - også Python.
>
> Niks.

Jo.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Bertel Lund Hansen (11-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 11-03-11 16:49

Birger Sørensen skrev:

> Hvad bliver et program i en fil til, når det hentes ind i hukommelsen?

Elektriske signaler.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Birger Sørensen (11-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 11-03-11 19:52

Bertel Lund Hansen formulerede spørgsmålet:
> Birger Sørensen skrev:
>
>> Hvad bliver et program i en fil til, når det hentes ind i hukommelsen?
>
> Elektriske signaler.

lol
Så er en fil blot en samling små magneter - hvis den er på HD, altså...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Bertel Lund Hansen (12-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 12-03-11 09:46

Birger Sørensen skrev:

> Så er en fil blot en samling små magneter - hvis den er på HD, altså...

Jeg kan godt skrive en detaljeret forklaring på forskellen på
fortolkede sprog og på kompilerede sprog, men det fører næppe
videre. Hvis du ikke kan se forskel, er det værst for dig selv,
men det kan være praktisk for dig at vide at andre betragter det
som to forskellige ting.

En tydelig forskel er dog at en kompileret fil kan stå alene,
mens en scriptfil ikke virker hvis ikke fortolkertsystemet er
installeret.

EOD.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Birger Sørensen (12-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 12-03-11 11:57

Følgende er skrevet af Bertel Lund Hansen:
> Birger Sørensen skrev:
>
>> Så er en fil blot en samling små magneter - hvis den er på HD, altså...
>
> Jeg kan godt skrive en detaljeret forklaring på forskellen på
> fortolkede sprog og på kompilerede sprog, men det fører næppe
> videre. Hvis du ikke kan se forskel, er det værst for dig selv,
> men det kan være praktisk for dig at vide at andre betragter det
> som to forskellige ting.
>
> En tydelig forskel er dog at en kompileret fil kan stå alene,
> mens en scriptfil ikke virker hvis ikke fortolkertsystemet er
> installeret.
>
> EOD.

Det er vist ikke nødvendigt, men tak for tilbuddet.

Den væsentligste forskel emm, er at kompilerede sprog bliver
fejlchecket og optimeret.

Man kan trække hesten til truget, men man kan ikke tvinge den til at
drikke.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Birger Sørensen (10-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 10-03-11 19:47

Admin har bragt dette til verden:
> Jeg har brugt det (lidt), dog ikke til hjemmesider endnu, da det ikke
> har været muligt at finde hoster i DK.

MLhosting understøtter Python på linux servere.
Servage har også Python - men de ligger fysyik i UK svjh.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Bertel Lund Hansen (10-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 10-03-11 22:47

Bertel Lund Hansen skrev:

> Jeg vil da lige for sjovs skyld høre hvad Gigahost ville sige til
> at installere Python på deres servere.

Og de siger at det ikke er installeret, og at de ikke har planer
om at gøre det.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

Leif Neland (10-03-2011)

Kommentar
Fra : Leif Neland

Dato : 10-03-11 07:43

Den 10-03-2011 03:22, Bertel Lund Hansen skrev:
> Birger Sørensen skrev:
>
>> Så hvis man gemmer i utf8 og vil arbejde med ISO, får man et problem.
>
> Du har ikke helt forstået problemet. I PHP kan man slet ikke
> arbejde i UTF-8. Alle funktioner er enkeltbyte-funktioner. Man
> ville være nødt til at designe sin egen wrapper til dem alle for
> at de kan håndtere UTF-8. Så kan man lige så godt begybde at
> designe sit eget sprog [1].
>

Der er da en hel side mb_ funktioner til håndtering af multibyte-strenge.

Leif
--

Bevar P2, luk P3, der er nok P3'er i forvejen.

Frank Damgaard (10-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 10-03-11 08:55

On 2011-03-10 03:22, Bertel Lund Hansen wrote:
> Birger Sørensen skrev:
>
>> Så hvis man gemmer i utf8 og vil arbejde med ISO, får man et problem.
>
> Du har ikke helt forstået problemet. I PHP kan man slet ikke
> arbejde i UTF-8. Alle funktioner er enkeltbyte-funktioner. Man
> ville være nødt til at designe sin egen wrapper til dem alle for
> at de kan håndtere UTF-8. Så kan man lige så godt begybde at
> designe sit eget sprog [1].

men det går da fint at have PHP kode der leveret html med utf8;
og hente data fra mysql der er utf8.

Dog skal man ikke bruge de alm. textstreng-funktioner når man
håndterer multibyte text som utf8....

scootergrisen (10-03-2011)

Kommentar
Fra : scootergrisen

Dato : 10-03-11 09:14

> Dog skal man ikke bruge de alm. textstreng-funktioner når man
> håndterer multibyte text som utf8....

Nej netop det er der det bliver besværligt.
En del funktioner kan erstattes af de funktioner som har samme navn bare
med mb_ foran men det kræver så at multibyte modulet er installeret og
det er ikke alle funktioner der er lavet en mb_ funktion af så det
kræver noget ekstra arbejde.

Det lykkedes mig da aldrig af finde ud af hvordan man sorter et
associativt array så æøåÆØÅ sorteres rigtigt.

Stig Johansen (10-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 10-03-11 10:03

Birger Sørensen wrote:

> Jeg har valgt fra starten, at bruge latin-1 (før latin-9 fandtes), og
> jeg har aldrig (knock on wood) haft problemer, ud over dem AJAX giver,
> fordi AJAX, kun kan utf8.

Kun kan (forstå)..?

Jeg har 'for lang tid siden' lavet en UTF8toAnsi, som sender 'AJAX' med ansi
ned over wiren, så man udelukkende behøver at køre ansi på serveren.

I min optik er det bedre at udnytte client til konverteringen end
serverside Blink

--
Med venlig hilsen
Stig Johansen

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 17:26

Stig Johansen (09-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 09-03-11 11:21

Jørgen Farum Jensen wrote:

> Jeg er begyndt at bruge en HTML5 dokumenttypeerklæring.
>
> Min tegnsæt-markør er flg.
> <meta http-equiv="Content-Type" content="text/html;
> charset=iso-8859-1">
>
> Når jeg ikke bruger utf-tegnsæt får jeg følgende
> advarsel fra W3C's validator:
> Using windows-1252 instead of the declared encoding iso-8859-1
>
> Er det noget jeg skal tage mig af?

Nej

Historie kort:
Hvis din server ikke sender charset, er det/har været pr. definition
iso-8859-1 (aka western latin, eller hvad det nu hedder).

Da 'vi' indførte euro, hed tegnsættet iso-8859-15, hvor det vidt kun var
eurotegnet, der blev indført.

Default bliver nok ændret til win1252, men i bund og grund er det fløjtende
ligegyldigt.

Jeg lavede engang en testside (i asp), hvor man kunne se værdier og glyphs
for de forskellige tegnsæt, og alle (mine) browsere viste nøjagtig det
samme.

IE,FF og Konqueror.

Herunder også euro tegnet for iso-8859-1.

Da du tilsyneladende kører 'standard', er der overhovedet ingen grund til at
have et meta tag, da det ligger implicit fra serveren.

Meta tagget er kun til at anføre 'codepage' for single byte charsets.

--
Med venlig hilsen
Stig Johansen

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 14:04

> Da du tilsyneladende kører 'standard', er der overhovedet ingen grund til at
> have et meta tag, da det ligger implicit fra serveren.
>
> Meta tagget er kun til at anføre 'codepage' for single byte charsets.

Det bruges da til at fortælle browseren hvilket encoding filen er gemt i.
Og hvorfor skulle det kun være til single byte charsets ?

Hvis du gemmer en HTML fil som UTF8 hvordan skal browseren så vide det
uden at man fortæller det med <meta...> ?

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 15:18

Den 09-03-2011 14:04, scootergrisen skrev:
>> Da du tilsyneladende kører 'standard', er der overhovedet ingen grund
>> til at
>> have et meta tag, da det ligger implicit fra serveren.
>>
>> Meta tagget er kun til at anføre 'codepage' for single byte charsets.
>
> Det bruges da til at fortælle browseren hvilket encoding filen er gemt i.

Ja, men HTTP Header har præcedens. Hvis den siger noget andet kan du
ikke bruge meta til en dyt.

Fallback i HTML5 er UTF-8. Måske det, som Stig mener.

MVH
Rune Jensen

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 15:55

> Ja, men HTTP Header har præcedens. Hvis den siger noget andet kan du
> ikke bruge meta til en dyt.
>
> Fallback i HTML5 er UTF-8. Måske det, som Stig mener.

Hvorfor skulle HTTP headeren også sige hvilken encoding der bruges ?

Det da bedre at skrive encodingen med <meta...> i stedet for at regne
med at progammerne nok selv fidner ud af det.

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 16:02

Den 09-03-2011 15:55, scootergrisen skrev:
>> Ja, men HTTP Header har præcedens. Hvis den siger noget andet kan du
>> ikke bruge meta til en dyt.
>>
>> Fallback i HTML5 er UTF-8. Måske det, som Stig mener.
>
> Hvorfor skulle HTTP headeren også sige hvilken encoding der bruges ?

Godt spørgsmål, da jeg også opfatter HTTP headeren som data om
overførslen - men sådan er det altså. HTTP header er vigtigere end HTML
meta.

> Det da bedre at skrive encodingen med <meta...> i stedet for at regne
> med at progammerne nok selv fidner ud af det.

Prøv at lave en HTTP header, som sætter charset til ISO 8859, og prøv
derefter at sætte meta til UTF-8. Det vil tage præcedens fra
HTTP-hheaderen, dvs. 8859, og du kan ikke bruge din meta til særligt
meget. Derudover, så er der faktisk proxy-servere, som slet ikke læser
Meta. De vil have problemer, hvis du ikke sætter en HTTP-header - eller
hvis serveren selv ikke sender en charset.

Meta er ikke nødvendigt, hvis der fra serveren eller via HTTP header
sendes en charset. Dette gælder HTML4 - ved ikke med HTML5. Men jeg kan
ikke se, hvorfor de skulle lave om på det. Der er stadig det med
proxy-servere.

MVH
Rune Jensen

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 16:11

> Prøv at lave en HTTP header, som sætter charset til ISO 8859, og prøv
> derefter at sætte meta til UTF-8. Det vil tage præcedens fra
> HTTP-hheaderen, dvs. 8859, og du kan ikke bruge din meta til særligt
> meget. Derudover, så er der faktisk proxy-servere, som slet ikke læser
> Meta. De vil have problemer, hvis du ikke sætter en HTTP-header - eller
> hvis serveren selv ikke sender en charset.

Du har ret men folk der skriver rå HTML sider har jo ikke adgang til at
sætte HTTP headeren.

Kan du nævne nogen som bruge HTTP header til at fortælle hvilken
encoding deres HTML filer er skrevet i ?

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 16:35

Den 09-03-2011 16:10, scootergrisen skrev:
>> Prøv at lave en HTTP header, som sætter charset til ISO 8859, og prøv
>> derefter at sætte meta til UTF-8. Det vil tage præcedens fra
>> HTTP-hheaderen, dvs. 8859, og du kan ikke bruge din meta til særligt
>> meget. Derudover, så er der faktisk proxy-servere, som slet ikke læser
>> Meta. De vil have problemer, hvis du ikke sætter en HTTP-header - eller
>> hvis serveren selv ikke sender en charset.
>
> Du har ret men folk der skriver rå HTML sider har jo ikke adgang til at
> sætte HTTP headeren.
>
> Kan du nævne nogen som bruge HTTP header til at fortælle hvilken
> encoding deres HTML filer er skrevet i ?

Jeg vil tro Yahoo gør det, da de selv anbefaler, man gør det. Men ellers
er der rigtigt mange servere, som fortæller det den vej. En server kan
jo godt være sat op efter en bestemt encoding. Det er det problem som
jeg også har oplevet, at serveren VILLE have UTF-8, og lige meget hvad
hulen jeg gjorde med meta, så opfattede browseren det som UTF-8, fordi
det sagde serveren.

Den HTTP-header kan man så selv ændre, men om den har præcedens over
selve serveren, ved jeg ikke. Hvis nogen har en server, som er sat op
til en bestemt encoding kan de jo afprøve om en ændring virker via
HTTP-header med et script.

Jeg har kun haft problemet én gang, hvor løsningen (dengang) var lave
hele dokumentet i UTF-8. Jeg havde ikke dengang overvejet HTTP headeren.

MVH
Rune Jensen

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 17:10

> En server kan
> jo godt være sat op efter en bestemt encoding. Det er det problem som
> jeg også har oplevet, at serveren VILLE have UTF-8, og lige meget hvad
> hulen jeg gjorde med meta, så opfattede browseren det som UTF-8, fordi
> det sagde serveren.

Så var din server jo bare opsat dårligt for dig.

> Den HTTP-header kan man så selv ændre, men om den har præcedens over
> selve serveren, ved jeg ikke.

Folk der skriver rå HTML kan da ikke sætter headeren.

> Hvis nogen har en server, som er sat op
> til en bestemt encoding kan de jo afprøve om en ændring virker via
> HTTP-header med et script.
>
> Jeg har kun haft problemet én gang, hvor løsningen (dengang) var lave
> hele dokumentet i UTF-8. Jeg havde ikke dengang overvejet HTTP headeren.

Hvis det er en wenhotel udbyder der har sat serveren op til at HTML
filer skal leveres som UTF-8 i headeren så er det da bare dårligt opsat
af udbyderen.

Svare til at opsætte serveren til at sige at alle billedformater det er
bare JPEG lige meget hvad.

Så er det da også åndsvagt hvis en webhotel udbyder siger at alle filer
som slutter på .html de er gemt i UTF-8 lige meget hvad.

Stig Johansen (14-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 14-03-11 19:05

scootergrisen wrote:

> Du har ret men folk der skriver rå HTML sider har jo ikke adgang til at
> sætte HTTP headeren.

Du bliver nødt til at sætte dig ind i tingene og skelne mellem HTTP og HTML!

ALLE der laver websider har adgangt til at sætte den korrekte HTTP-headere -
direkte, eller indirekte.

Har man sin egen server bestemmer man selv.
Er man en del af et 'kollektiv', følger man flertallet, eller finder et
andet.

Hvis udbyderen kun tilbyder utf-8, så er det det, og så man forholde sig til
det, eller finde en anden udbyder.

> Kan du nævne nogen som bruge HTTP header til at fortælle hvilken
> encoding deres HTML filer er skrevet i ?

ALLE BRUGER http headers, ellers fungerede 'webbet' overhovedet ikke.

Hvis du ikke er tilfreds med din udbyderes opsætning, så må du finde en
anden, eller finde din egen server.

--
Med venlig hilsen
Stig Johansen

Frank Damgaard (09-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 09-03-11 17:15

On 2011-03-09 14:04, scootergrisen wrote:
>> Da du tilsyneladende kører 'standard', er der overhovedet ingen grund til at
>> have et meta tag, da det ligger implicit fra serveren.
>>
>> Meta tagget er kun til at anføre 'codepage' for single byte charsets.
>
> Det bruges da til at fortælle browseren hvilket encoding filen er gemt i.
> Og hvorfor skulle det kun være til single byte charsets ?
>
> Hvis du gemmer en HTML fil som UTF8 hvordan skal browseren så vide det uden at man
> fortæller det med <meta...> ?

<meta....> kommer først senere i html dokumentet, men
da UTF8 for bytes < 127 er det samme som ASCI96 så bør
browseren kunne læse ned til <meta...>
Er det utf-16 så kan det måske blive besværligt for browseren
at læse dokumentet. (ASCII96 er ikke en delmængde af UTF16)

Charsewt kan angives i "http-header" i HTTP protokollen.

Det er sådan det helst skal ske, fordi så kan browser få at vide
hvilket tegnsæt det er inden den læser html/txt dokument.

f.eks.:
Content-Type: text/html; charset=utf-8
eller
Content-Type: text/html; charset=iso-8859-1

Opsætning på web-serveren kan også være helt uden charset information,
så må browseren se efter <meta>.

I scriptsprog som PHP skal man normalt selv huske at sende http-headere.

PS.
Hvis der både er en http-header og <meta...>
og disse angiver forskellige tegnsæt (hyppig fejl)
så opstår der problmer.... , fordi:

I Firefox mfl. har http-header 1. prioritet og
den vinder over meta.

I IE og Opera overtrumfer meta en http-header.

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 17:25

Det kan godt være det i teorien er smart at opsætte serveren til en
bestemet encoding som sendes i headeren men hvad så når du vil bruge
andre encoding ?
Eventuel bare for at teste.

> I IE og Opera overtrumfer meta en http-header.

Jeg har lige teste i ie og oprera og de viser efter hvad der står i
headeren så det passer vist ikke.

Frank Damgaard (09-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 09-03-11 18:56

On 2011-03-09 17:25, scootergrisen wrote:
> Det kan godt være det i teorien er smart at opsætte serveren til en bestemet encoding som
> sendes i headeren men hvad så når du vil bruge andre encoding ?
> Eventuel bare for at teste.
>
>> I IE og Opera overtrumfer meta en http-header.
>
> Jeg har lige teste i ie og oprera og de viser efter hvad der står i headeren så det passer
> vist ikke

ja, det er godt nok et par år siden jeg sidst prøvede.

hmm , ja så jeg har også lige prøvet med IE8 og Opera, nu virker det
som med FF, dvs. http-header vinder over <meta...>.

Det er jo godt det nu virker ens i browserne Glad

Jørgen Farum Jensen (09-03-2011)

Kommentar
Fra : Jørgen Farum Jensen

Dato : 09-03-11 14:26

Den 08-03-2011 14:52, Jørgen Farum Jensen skrev:
> Jeg er begyndt at bruge en HTML5 dokumenttypeerklæring.
>
> Min tegnsæt-markør er flg.
> <meta http-equiv="Content-Type" content="text/html;
> charset=iso-8859-1">
>
> Når jeg ikke bruger utf-tegnsæt får jeg følgende
> advarsel fra W3C's validator:
> Using windows-1252 instead of the declared encoding iso-8859-1
>
> Er det noget jeg skal tage mig af?
>
> Jeg gider ikke utf-8 og det medfølgende besvær
> med HTML tegnækvivalenter.
>

Tak for alle input!

Jeg er nu forvirret på et højere plan Glad

1. Den HTML-editor jeg nu har brugt i 13 år
(dog forskellige versioner!) kan ikke gemme
en ANSI-fil som en UTF-fil.

2. Jeg kan indlæse en ANSI fil i en anden
editor og gemme den som UTF-8.

3. Så vises det udvidede tegnsæt korrekt
i browseren.

4. I min normale editor se jeg så, hvad der
er sket, for eksempel
" ... vÃ¦lger at prÃ¦sentere byens
historie og sevÃ¦rdigheder."

5. Det afskærer mig fra at redigere i filen
i den editor jeg foretrækker.

6. Udelader jeg meta charset markøren, vil
W3C's HTML5 validator ikke validere siden.

7. Summa Summarum:
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-15">
virker som den skal, og siden validerer.

Og hele balladen skyldes i virkeligheden at
jeg havde glemt, at det /ikke/ er nok bare
at sætte charset=utf-8, men at filen også
skal gemmes i utf-8 format.

--
Jørgen Farum Jensen
http://webdesign101.dk
..

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 14:40

> 1. Den HTML-editor jeg nu har brugt i 13 år
> (dog forskellige versioner!) kan ikke gemme
> en ANSI-fil som en UTF-fil.

I Notepad++ kan jeg vælge "ANSI as UTF-8".
Den bruger jeg.
Der er også en encoding som hedder UTF-8.
Forskellen er at UTF-8 gemmer såkaldte BOM (Byte Ordre Mark) før det du
skriver i filen. "ANSI as UTF-8" gemmer ikke BOM.

BOM er 3 byte som tilføjes først i din fil.
Du kan ikke se de 3 tegn med mindre du åbner det i en HEX editor eller
et program som ikke forstår BOM.

Se her : http://scootergrisen.dk/phpgrisen/billeder/billed0032.png

> 2. Jeg kan indlæse en ANSI fil i en anden
> editor og gemme den som UTF-8.

Hvad er det for et program du bruger ?
Og har du prøvet i den senereste version ?

> 3. Så vises det udvidede tegnsæt korrekt
> i browseren.
>
> 4. I min normale editor se jeg så, hvad der
> er sket, for eksempel
> " ... vÃ¦lger at prÃ¦sentere byens
> historie og sevÃ¦rdigheder."

Det er fordi æ er gemt som multibyte (UTF8) men vises som singlebyte Ã¦

> 5. Det afskærer mig fra at redigere i filen
> i den editor jeg foretrækker.

Med mindre du bruger en gammel version tror jeg godt du kan bruge UTF8 i
dit program.

> 6. Udelader jeg meta charset markøren, vil
> W3C's HTML5 validator ikke validere siden.

Jo det vil den gerne.
Du kan hos W3C manuelt vælge hvilke encoding du vil bruge.

> Og hele balladen skyldes i virkeligheden at
> jeg havde glemt, at det /ikke/ er nok bare
> at sætte charset=utf-8, men at filen også
> skal gemmes i utf-8 format.

Øh ja selvfølgelig skal filen være gemt som UTF-8 hvorfor skulle du
ellers sætte charset=utf-8 ?

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 15:21

Den 09-03-2011 14:25, Jørgen Farum Jensen skrev:

> 6. Udelader jeg meta charset markøren, vil
> W3C's HTML5 validator ikke validere siden.

Det bør den ikke have problemer med, hvis du i stedet sætter en HTTP
header charset.

Ellers har de lavet noget om i HTML5.

MVH
Rune Jensen

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 16:03

>> 6. Udelader jeg meta charset markøren, vil
>> W3C's HTML5 validator ikke validere siden.
>
> Det bør den ikke have problemer med, hvis du i stedet sætter en HTTP
> header charset.

Bruger du da HTTP headers til at fortælle hvad encoding dine filer er
gemt i ?

Admin (09-03-2011)

Kommentar
Fra : Admin

Dato : 09-03-11 16:22

Den 09-03-2011 16:02, scootergrisen skrev:
>>> 6. Udelader jeg meta charset markøren, vil
>>> W3C's HTML5 validator ikke validere siden.
>>
>> Det bør den ikke have problemer med, hvis du i stedet sætter en HTTP
>> header charset.
>
> Bruger du da HTTP headers til at fortælle hvad encoding dine filer er
> gemt i ?

Ja, i nyere projekter gør jeg. Anbefalingen kommer fra Google og Yahoo,
og begrundelsen er bl.a. det med proxier, men også at man ikke behøver
bekymre sig om, at meta charset skal være indenfor de første 512 bytes.

I teorien bør det give en hurtigere side, i prakssis måske ikke.

Jeg bruger både HTTP header og meta, men de er ens.

MVH
Rune Jensen

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 17:11

>> Bruger du da HTTP headers til at fortælle hvad encoding dine filer er
>> gemt i ?
>
> Ja, i nyere projekter gør jeg. Anbefalingen kommer fra Google og Yahoo,
> og begrundelsen er bl.a. det med proxier, men også at man ikke behøver
> bekymre sig om, at meta charset skal være indenfor de første 512 bytes.
>
> I teorien bør det give en hurtigere side, i prakssis måske ikke.
>
> Jeg bruger både HTTP header og meta, men de er ens.

Jo men hvis folk ikke har adgang til at sætte headeren så kan de jo ikke
bruge det til noget.

Admin (10-03-2011)

Kommentar
Fra : Admin

Dato : 10-03-11 04:16

Den 09-03-2011 17:11, scootergrisen skrev:
>>> Bruger du da HTTP headers til at fortælle hvad encoding dine filer er
>>> gemt i ?
>>
>> Ja, i nyere projekter gør jeg. Anbefalingen kommer fra Google og Yahoo,
>> og begrundelsen er bl.a. det med proxier, men også at man ikke behøver
>> bekymre sig om, at meta charset skal være indenfor de første 512 bytes.
>>
>> I teorien bør det give en hurtigere side, i prakssis måske ikke.
>>
>> Jeg bruger både HTTP header og meta, men de er ens.
>
> Jo men hvis folk ikke har adgang til at sætte headeren så kan de jo ikke
> bruge det til noget.

Egentlig lettere end at skrive en hel masse, er vel at henvise til:

http://code.google.com/intl/da-DK/speed/page-speed/docs/rendering.html#SpecifyCharsetEarly

Jeg vil tro, hvis din hoster ikke tilbyder et programmeringssprog, at så
de sætter charset for dig på serveren. Det ville jeg i hvert fald finde
naturligt, da proxier ellers SVJV vil kunne få problemmer. Ligeså
naturlgt ville jeg også finde det, at den blev sat til UTF-8, da det er
fremtiden.

MVH
Rune Jensen

scootergrisen (10-03-2011)

Kommentar
Fra : scootergrisen

Dato : 10-03-11 08:33

> Jeg vil tro, hvis din hoster ikke tilbyder et programmeringssprog, at så
> de sætter charset for dig på serveren. Det ville jeg i hvert fald finde
> naturligt

Det ville da være åndsvagt for så skulle alle deres kunder jo bruge den
samme encoding.

Frank Damgaard (10-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 10-03-11 08:51

On 2011-03-10 08:32, scootergrisen wrote:
>> Jeg vil tro, hvis din hoster ikke tilbyder et programmeringssprog, at så
>> de sætter charset for dig på serveren. Det ville jeg i hvert fald finde
>> naturligt
>
> Det ville da være åndsvagt for så skulle alle deres kunder jo bruge den samme encoding.

Eller checke hvor i kontrolpanel på webhotel man kan ændre det.
Er det apache webserver kan man ofte også via .htaccess
sætte det.
Og for PHP,perl,mfl. skal man selv sætte http headere.

scootergrisen (10-03-2011)

Kommentar
Fra : scootergrisen

Dato : 10-03-11 09:10

Den 10-03-2011 08:50, Frank Damgaard skrev:
> On 2011-03-10 08:32, scootergrisen wrote:
>>> Jeg vil tro, hvis din hoster ikke tilbyder et programmeringssprog, at så
>>> de sætter charset for dig på serveren. Det ville jeg i hvert fald finde
>>> naturligt
>>
>> Det ville da være åndsvagt for så skulle alle deres kunder jo bruge den samme encoding.
>
> Eller checke hvor i kontrolpanel på webhotel man kan ændre det.
> Er det apache webserver kan man ofte også via .htaccess
> sætte det.
> Og for PHP,perl,mfl. skal man selv sætte http headere.
>
>

Hvad så hvis du vil lave nogen side med andet encoding ?

Frank Damgaard (10-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 10-03-11 10:01

On 2011-03-10 09:10, scootergrisen wrote:
> Den 10-03-2011 08:50, Frank Damgaard skrev:
>> On 2011-03-10 08:32, scootergrisen wrote:
>>>> Jeg vil tro, hvis din hoster ikke tilbyder et programmeringssprog, at så
>>>> de sætter charset for dig på serveren. Det ville jeg i hvert fald finde
>>>> naturligt
>>>
>>> Det ville da være åndsvagt for så skulle alle deres kunder jo bruge den samme encoding.
>>
>> Eller checke hvor i kontrolpanel på webhotel man kan ændre det.
>> Er det apache webserver kan man ofte også via .htaccess
>> sætte det.
>> Og for PHP,perl,mfl. skal man selv sætte http headere.
>>
>>
>
> Hvad så hvis du vil lave nogen side med andet encoding ?

så sætter du det som du vil i kontrolpanel eller i passende .htaccess fil
(skal ikke kunne sige hvordan det sker på IIS servere, men mon
ikke man også der kan indstille det)

Du kan jo også i roden sætte .htaccess så text/html ikke har en charset.

Stig Johansen (10-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 10-03-11 10:10

Frank Damgaard wrote:

>> Hvad så hvis du vil lave nogen side med andet encoding ?
>
> så sætter du det som du vil i kontrolpanel eller i passende .htaccess fil
> (skal ikke kunne sige hvordan det sker på IIS servere, men mon
> ikke man også der kan indstille det)

Kort og godt:
Der er intet man kan under Apache, som man ikke kan i IIS.
Det handler udelukkende om tilgængelighed fra udbyderens side.

Man kan jo sige sig selv, at hvis IIS er ringere end Apache, så eksisterede
den ikke.

Det er blot forskellige målgrupper (og økonomiske modeller), der skiller dem
ad.

--
Med venlig hilsen
Stig Johansen

Admin (10-03-2011)

Kommentar
Fra : Admin

Dato : 10-03-11 09:23

Den 10-03-2011 08:32, scootergrisen skrev:
>> Jeg vil tro, hvis din hoster ikke tilbyder et programmeringssprog, at så
>> de sætter charset for dig på serveren. Det ville jeg i hvert fald finde
>> naturligt
>
> Det ville da være åndsvagt for så skulle alle deres kunder jo bruge den
> samme encoding.

Ikke desto mindre, så er der hostere, som sætter encoding for deres
brugere på serveren.

Hostere sætter ikke bare ting "ud i det blå". Det tror jeg altså ikke
rigtigt på. Så de må have en begrundelse, men hvilken ved jeg ikke.

MVH
Rune Jensen

Bertel Lund Hansen (10-03-2011)

Kommentar
Fra : Bertel Lund Hansen

Dato : 10-03-11 10:07

Admin skrev:

> Ikke desto mindre, så er der hostere, som sætter encoding for deres
> brugere på serveren.

Gigahost sætter UTF-8 som default. Så kan man selv ændre det i
opsætningen hvis man vil.

--
Bertel
http://bertel.lundhansen.dk/ http://fiduso.dk/

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 16:02

Okay nu har jeg lige prøvet at gemme en fil med ISO-8859-1 encoding og
sætte <meta...> til ISO-8859-1 og hvad tror i så W3C validatoren siger ?

Den siger da selvfølgelig :

Using windows-1252 instead of the declared encoding iso-8859-1

Haha. Der er altså ikke noget i vejen med koden det er bare W3C
validatoren der syns den skal være sjov.

Og det er ikke fordi filen er gemt som windows-1252 som jeg troede
tidligere næ det bare W3C der er sådan.

Man kan godt vælge iso-8859-1 manuelt i validatoren så siger den ikke
noget men når den er sat til automatisk vil den ikke bruge iso-8859-1 af
en eller anden grund.

Frank Damgaard (09-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 09-03-11 19:05

On 2011-03-09 16:01, scootergrisen wrote:
> Okay nu har jeg lige prøvet at gemme en fil med ISO-8859-1 encoding og sætte <meta...> til
> ISO-8859-1 og hvad tror i så W3C validatoren siger ?
>
> Den siger da selvfølgelig :
>
> Using windows-1252 instead of the declared encoding iso-8859-1
>
> Haha. Der er altså ikke noget i vejen med koden det er bare W3C validatoren der syns den
> skal være sjov.

bruger du tegn i området ascii 127-159 ?

sammenlign:
http://en.wikipedia.org/wiki/Windows-1252
http://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout

> Og det er ikke fordi filen er gemt som windows-1252 som jeg troede tidligere næ det bare
> W3C der er sådan.

hos mig siger den ikke 1252 hvis det er iso8859-1

>
> Man kan godt vælge iso-8859-1 manuelt i validatoren så siger den ikke noget men når den er
> sat til automatisk vil den ikke bruge iso-8859-1 af en eller anden grund.

Er du helt sikker på filen er iso-8859-1 ?

Ellers brug html entities, de vises korrekt i alle tegnsæt.
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references
dvs.
æ ø å ....

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 19:57

Nu har jeg lavet nogle tests og jeg er ret sikker på at filen gemmes med
iso-8859-1 encoding.

Det mærkelige er så at lige meget om jeg vælger iso-8859-1 eller
windows-1252 i browserens visning så ændre det ikke på noget.

€ tegnet er med i windows-1252 men ikke i iso-8859-1 så derfor burde jeg
vil kunne se € tegnet hvis jeg vælger windows-1252 i browseren ik ?
Men det kan jeg ikke.

Med  kan jeg se € tegnet lige meget hvad men det burde jeg vel
ikke kunne når det vises som iso-8859-1 ?

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 20:08

Den 09-03-2011, skrev scootergrisen:
> Nu har jeg lavet nogle tests og jeg er ret sikker på at filen gemmes med
> iso-8859-1 encoding.
>
> Det mærkelige er så at lige meget om jeg vælger iso-8859-1 eller windows-1252
> i browserens visning så ændre det ikke på noget.
>
> ¤ tegnet er med i windows-1252 men ikke i iso-8859-1 så derfor burde jeg vil
> kunne se ¤ tegnet hvis jeg vælger windows-1252 i browseren ik ?
> Men det kan jeg ikke.
>
> Med  kan jeg se ¤ tegnet lige meget hvad men det burde jeg vel ikke
> kunne når det vises som iso-8859-1 ?

&#128 er en HTML enity. Den skulle gerne kunne vises altid - uanset
charset.
ISO-8859-15 har ¤ tegnet.
Det der svarer til ¤ i ISO-8859-1 er vist svjh en cirkel med et x over,
så det burde være det du ser i windows 1252, hvis det konverteres fra
ISO-8859-1, ifølge mine begreber...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 20:10

Birger Sørensen:
> Den 09-03-2011, skrev scootergrisen:
>> Nu har jeg lavet nogle tests og jeg er ret sikker på at filen gemmes med
>> iso-8859-1 encoding.
>>
>> Det mærkelige er så at lige meget om jeg vælger iso-8859-1 eller
>> windows-1252 i browserens visning så ændre det ikke på noget.
>>
>> ¤ tegnet er med i windows-1252 men ikke i iso-8859-1 så derfor burde jeg
>> vil kunne se ¤ tegnet hvis jeg vælger windows-1252 i browseren ik ?
>> Men det kan jeg ikke.
>>
>> Med  kan jeg se ¤ tegnet lige meget hvad men det burde jeg vel ikke
>> kunne når det vises som iso-8859-1 ?
>
> &#128 er en HTML enity. Den skulle gerne kunne vises altid - uanset charset.
> ISO-8859-15 har ¤ tegnet.
> Det der svarer til ¤ i ISO-8859-1 er vist svjh en cirkel med et x over, så
> det burde være det du ser i windows 1252, hvis det konverteres fra
> ISO-8859-1, ifølge mine begreber...
>
> Birger

Der skal selvfølgelig stå 
Man kan se det er en entity, ved at det begynder med & og ender med ;

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

Frank Damgaard (09-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 09-03-11 21:05

On 2011-03-09 20:08, Birger Sørensen wrote:
> Den 09-03-2011, skrev scootergrisen:
>> Nu har jeg lavet nogle tests og jeg er ret sikker på at filen gemmes med iso-8859-1
>> encoding.
>>
>> Det mærkelige er så at lige meget om jeg vælger iso-8859-1 eller windows-1252 i
>> browserens visning så ændre det ikke på noget.
>>
>> ¤ tegnet er med i windows-1252 men ikke i iso-8859-1 så derfor burde jeg vil kunne se ¤
>> tegnet hvis jeg vælger windows-1252 i browseren ik ?
>> Men det kan jeg ikke.
>>
>> Med  kan jeg se ¤ tegnet lige meget hvad men det burde jeg vel ikke kunne når det
>> vises som iso-8859-1 ?
>
> &#128 er en HTML enity. Den skulle gerne kunne vises altid - uanset charset.
> ISO-8859-15 har ¤ tegnet.
> Det der svarer til ¤ i ISO-8859-1 er vist svjh en cirkel med et x over, så det burde være
> det du ser i windows 1252, hvis det konverteres fra ISO-8859-1, ifølge mine begreber...

hvis du skriver  så er det en html entity, og de 6 tegn:  er US ASCII
bruger man kun html entities for alle tegn der ikke er US-ASCII så
kan man bruge charset=us-ascii på dokumentet.

Skriver jeg asci tegn 128 (0x80) i et dokument med iso8859.1, så brokker
validator sig. Se tegntabellen på
http://en.wikipedia.org/wiki/ISO/IEC_8859-1#Codepage_layout

Og http://htmlhelp.com/reference/charset/ :
"ISO-8859-1 explicitly does not define displayable characters for positions 0-31 and
127-159, and the HTML standard does not allow those to be used for displayable characters"

Frank Damgaard (09-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 09-03-11 21:11

On 2011-03-09 19:56, scootergrisen wrote:
> Nu har jeg lavet nogle tests og jeg er ret sikker på at filen gemmes med iso-8859-1 encoding.
>
> Det mærkelige er så at lige meget om jeg vælger iso-8859-1 eller windows-1252 i browserens
> visning så ændre det ikke på noget.

tjah, men har du f.eks. tegn i dokumentet der er i området 128-159 ?

>
> € tegnet er med i windows-1252 men ikke i iso-8859-1 så derfor burde jeg vil kunne se €
> tegnet hvis jeg vælger windows-1252 i browseren ik ?
> Men det kan jeg ikke.

det er ikke i browseren du skal vælge tegnsæt, men http-header fra serveren
eller i <meta..> .

>
> Med  kan jeg se € tegnet lige meget hvad men det burde jeg vel ikke kunne når det
> vises som iso-8859-1 ?

nej, iso-8859-1 tegnsæt har ikke noget for 
tegnsekvensen  (6 tegn) er i øvrigt US-ASCII.
men taster du € ind i en teksteditor og gemmer (som win1252) så gemmes
bytevørdien 0x80 (128) for tegnet. Prøv at se en hexdump af html dokumentet.

Euro hedder i øvrigt: €
så får du € i alle browsere der kan vise tegnet.

Det er dårlig ide at bruge &#N; hvor N er et tal, hvis man vil bruge et speciel tegn,
se listen af html entities med navn :
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

scootergrisen (09-03-2011)

Kommentar
Fra : scootergrisen

Dato : 09-03-11 21:21

Filen er gemt i ISO-8859-1 og det er W3C validatoren der giver en
advarsel selvom der ikke er nogen grund til det :

http://scootergrisen.dk/test/test0078.html

Kom gerne med et eksempel.

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 21:48

scootergrisen skrev:
> Filen er gemt i ISO-8859-1 og det er W3C validatoren der giver en advarsel
> selvom der ikke er nogen grund til det :
>
> http://scootergrisen.dk/test/test0078.html
>
> Kom gerne med et eksempel.

HTML5 validatoren er stadig eksperimentel.
Prøv at bruge store bogstaver, som er det karaktersættet hedder :
ISO-8859-1
Så brokker validatoren sig ikke mere, jfr Jørgens tidligere post.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

scootergrisen (10-03-2011)

Kommentar
Fra : scootergrisen

Dato : 10-03-11 08:36

> HTML5 validatoren er stadig eksperimentel.

Ja du har ret det jo nok bare derfor den gør det så det skal man ikke
tage så tungt.

> Prøv at bruge store bogstaver, som er det karaktersættet hedder :
> ISO-8859-1
> Så brokker validatoren sig ikke mere, jfr Jørgens tidligere post.

Den siger det samme med stort :
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fscootergrisen.dk%2Ftest%2Ftest0078.html

Birger Sørensen (09-03-2011)

Kommentar
Fra : Birger Sørensen

Dato : 09-03-11 21:49

Frank Damgaard (10-03-2011)

Kommentar
Fra : Frank Damgaard

Dato : 10-03-11 01:46

On 2011-03-09 21:48, Birger Sørensen wrote:
> scootergrisen skrev:
>> Filen er gemt i ISO-8859-1 og det er W3C validatoren der giver en advarsel selvom der
>> ikke er nogen grund til det :
>>
>> http://scootergrisen.dk/test/test0078.html
>>
>> Kom gerne med et eksempel.
>
> HTML5 validatoren er stadig eksperimentel.
> Prøv at bruge store bogstaver, som er det karaktersættet hedder : ISO-8859-1
> Så brokker validatoren sig ikke mere, jfr Jørgens tidligere post.

Store bogstaver hjælper ikke, jeg har lige prøvet...
men iso-8859-15 hjælper, se nederst [*]

http://en.wikipedia.org/wiki/ISO/IEC_8859-1
...snip...
"ISO-8859-1 is (according to the standards at least) the default encoding of documents
delivered via HTTP with a MIME type beginning with "text/" (however the draft HTML 5
specification requires that documents advertised as ISO-8859-1 actually be parsed with the
Windows-1252 encoding.[2])"
..snip...

hmm, og der er nok ingen vej udenom at se standard-teksten:

http://dev.w3.org/html5/spec/Overview.html#charset
"The element containing the character encoding declaration must be serialized completely
within the first 1024 bytes of the document."
"Authors are encouraged to use UTF-8. Conformance checkers may advise authors against
using legacy encodings. [RFC3629]
Authoring tools should default to using UTF-8 for newly-created documents. [RFC3629]
"

ok, HTML5 bør helst være utf8 , det anbefales.

http://dev.w3.org/html5/spec/Overview.html#determining-the-character-encoding

http://dev.w3.org/html5/spec/Overview.html#character-encodings-0
"User agents must at a minimum support the UTF-8 and Windows-1252 encodings, but may
support more. [RFC3629] [WIN1252]
It is not unusual for Web browsers to support dozens if not upwards of a hundred distinct
character encodings."

og browseren skal bruge følgende konverteringstabel ved parsing af dokumentet:

Input encoding    Replacement encoding    References
EUC-KR     windows-949    [EUCKR] [WIN949]
EUC-JP    CP51932    [EUCJP] [CP51932]
GB2312     GBK    [RFC1345] [GBK]
GB_2312-80    GBK    [RFC1345] [GBK]
ISO-8859-1    windows-1252    [RFC1345] [WIN1252]
ISO-8859-9    windows-1254    [RFC1345] [WIN1254]
ISO-8859-11    windows-874    [ISO885911] [WIN874]
KS_C_5601-1987    windows-949    [RFC1345] [WIN949]
Shift_JIS    Windows-31J    [SHIFTJIS] [WIN31J]
TIS-620    windows-874    [TIS620] [WIN874]
US-ASCII    windows-1252    [RFC1345] [WIN1252]

Det er ikke en fejl at bruge ISO-8859-1, browseren skal dog
i det tilfælde parse dokument som om det var win-1252.

Forklaringen skal nok ses af at US ASCII er en ægte delmængde
af ISO-8859-1 som igen er en ægte delmængde af win-1252.

ISO-8859-15 er derimod ikke en delmængde af win1252 da ¤ er
placeret anderledes.

[*]
Så win1252 bør bruges hvis der er angivet iso-8859-1 eller US-ASCII.
At validator.w3.org giver en advarsel på iso-8859-1 og US-ASCII
kan så discuteres, for det er tilladt ifølge html5 draft,
men det er jo også kun en "warning/advarfse" ("velment råd"?).

Angives derimod ISO-8859-15 så bruges denne, og validator.w3.org
kommer så ikke med en advarsel.

Stig Johansen (10-03-2011)

Kommentar
Fra : Stig Johansen

Dato : 10-03-11 09:58

Frank Damgaard wrote:

> Forklaringen skal nok ses af at US ASCII er en ægte delmængde
> af ISO-8859-1 som igen er en ægte delmængde af win-1252.

Lidt historie.

Bemærk at der i starten kun var 6 bits, og dermed kun store bogstaver.
De små bogstaver (ASCII, 7 bits) ligger på præcis samme sted (bortset fra
den første bit).

Bemærk også at de første 32 'tegn' var kontrolkoder, og dam man kørte seriel
kommunikation med 7 bits + parity, eller 8 bits, none parity, var de 32
'tegn' fra 128 -> de samme (kontrolkoder), ellers virkede
kommunikastionsudstyret ikke.

Første step ud over ASCII var 7 bits substition, hvor []{}|\ tegn blev
substitueret med de danske tegn.

Da kommunikationsudstyret blev mere stabilt kunne man efterhånden undvære
parity checket, og gå over i 8 bits tegnsæt.

Jeg kørte selv HP Roman-8, men der var en 'krig' mellem producenterne.
IBM kørte EBCDIC, og senere PC-437 på deres XT'ere.

Danmark er jo et lille land, og nogle vil måske huske, at PC-437 eklsaterede
ved manglen på øØ.

Det blev vist som cent tegn og Yen tegn.

Så kom der en fandens masse codepages, PC8, PC8DN Windows-dillerdaller osv,
men med tiden blev det til 'western latin', hvor alle var 'glade'.

Men 256 tegn forslår jo som en skrædder i helvede, så ind kom unicode
(sidste årtusinde).

Til forskel for tidlige tegnsæt og codepages, hvor byteværdien, via en
'codepage' repræsenterede en glyph, så er unicode defineret ved _codepoint_
og en tilhørende glyph.

Unicode kan repræsenteres på mange måder, dvs. repræsentationen af en
_talværdi_ aka codepoint.

Når man snakker intern databehandling, er det optimalt at hvert 'tegn' har
samme 'bytestørrelse', så i virkeligheden er UCS-4 den optimale.

Fordelen er, at hvert tegn fylder det samme, og man kan beregne på
længderne, ulempen er, at hvert 'tegn' fylder 4 bytes.

Dvs. en faktor 4 i forbrug.

Windows lagde ud med UCS-2 (vistnok fra '95), men det er begrænset til 65536
codepoints.

De er derfor gået over til utf-16 (som internt format), og det er lidt en
mellemvej.

Den fylder mindst det dobbelte, men til gengæld er de første 255 codepoints
IDENTISKE men win-1252, og kræver derfor ingen (performancekrævende)
konvertering.

Når vi snakker XML og 'wire data', begrænset båndbredde, er det jo nærmest
tåbeligt at transmitere data med f.eks. utf-16, da langt størstedelenen af
tegnene består af en 'nul' byte.

Derfor 'enter utf-8'.

For at forstå utf-8, har man behov for at skelne om hver enkelt byte er en
enkelt byte (ASCII) eller multibyte.

Her har man så at sige 'stjålet' den første bit, som demed er roden til 'alt
ondt' uden for ASCII.

Derfor er codepoints>127 2 bytes eller mere.

Selve encodingen skal ses som bitmanipulation, nok mest analog til
klasseopdelingen af netværk, eller måske en slags run length encoding.

Så det vi ser som to 'mærkelige tegn' er udelukkende en encoding, og ikke de
'virkelige' tegn.

--
Med venlig hilsen
Stig Johansen

Søg

Reklame

Statistik

Spørgsmål :	177739
Tips :	31970
Nyheder :	719565
Indlæg :	6410320
Brugere :	218904

Månedens bedste

Årets bedste

Sidste års bedste