---

Denne side:

http://hjemmesideskolen.dk/html/elmnt/utf.php

er gemt som utf8 og uploaded som binær. Alligevel kommer den til browseren
som ISO-8859-1 og med nogle underlige tegn  flere steder, hvor der ikke
skal være noget. Og de specielle danske bogstaver har den sædvanlige
forvrængning.

Hvis jeg tvinger browseren til at vise siden som utf8, bliver siden gengivet
med de korrekte danske bogstaver og de underlige tegn forsvinder. Men der er
over og under menuen blevet indsat noget luft, som der ikke er kodebelæg
for.

Hvis jeg uploader som text, er problemet det samme. Siderne er skrevet
(gemt) i Notepad, da min sædvanlige webeditor ikke formår at gemme som utf8.

Er det noget, jeg kan ændre på eller er det noget min webhost skal ændre på
serveren?

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk

---

Den 30-08-2011 01:15, Erik Ginnerskov skrev:

> er gemt som utf8 og uploaded som binær. Alligevel kommer den
> til browseren som ISO-8859-1

Det er serveren, der serverer den som ISO-8859-1. Det
overtrumfer angivelsen i meta-tag'et.

Hvis du ændrer på serveren til UTF-8, vil du sikkert få et
problem, hvis du har andre sider med ISO-8859-1. Du kan
muligvis fjerne angivelsen fra serveren, så det er
angivelsen i filerne, der bestemmer tegnsættet.

> og med nogle underlige tegn 
....
> Hvis jeg uploader som text, er problemet det samme. Siderne
> er skrevet (gemt) i Notepad, da min sædvanlige webeditor
> ikke formår at gemme som utf8.

Hvis jeg ikke tager meget fejl, gemmer Notepad UTF-8 med BOM
- hvilket giver de underlige tegn.

Brug en editor, der kan gemme UTF-8 uden BOM, fx Notepad++
eller Geany.

--
Mvh. Kim Ludvigsen
Tips til hjemmesidesnedkeren:
http://kimludvigsen.dk/tips-internet-websnedker.php

---

Kim Ludvigsen wrote:

>> og med nogle underlige tegn 

> Hvis jeg ikke tager meget fejl, gemmer Notepad UTF-8 med BOM
> - hvilket giver de underlige tegn.
>
> Brug en editor, der kan gemme UTF-8 uden BOM, fx Notepad++
> eller Geany.

Prøvede at copy/paste til nye filer i Notepad++, det synes jeg bare gav
mange flere problemer.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk

---

Den 30-08-2011 14:55, Erik Ginnerskov skrev:
> Kim Ludvigsen wrote:
>
>> Brug en editor, der kan gemme UTF-8 uden BOM, fx Notepad++
>> eller Geany.
>
> Prøvede at copy/paste til nye filer i Notepad++, det synes
> jeg bare gav mange flere problemer.

Hvilke?

Du behøver ikke kopiere, du kan bare åbne filen i Notepad++,
ændre til UTF-8 uden BOM og så gemme igen. Du ændrer vist i
et menupunkt med navnet Funktioner eller Dokument (har ikke
lige en Windows ved hånden).

Du kan også opsætte Notepad++ til altid at gemme som UTF-8
uden BOM, det skal gøres i indstillingerne.

--
Mvh. Kim Ludvigsen
Hold dit livs drømmeferie i Thailand:
http://rejse-til-thailand.dk

---

Kim Ludvigsen wrote:

> Du behøver ikke kopiere, du kan bare åbne filen i Notepad++,
> ændre til UTF-8 uden BOM og så gemme igen.

Ved "save/save as" af en eksisterende fil får jeg ingen mulighed for at
vælge. Laver jeg en ny fil, får jeg mulighed for at definere tegnsæt - og
med eller uden BOM.

> Du kan også opsætte Notepad++ til altid at gemme som UTF-8
> uden BOM, det skal gøres i indstillingerne.

Sådan er den sat nu - og jeg slap af med BOM, så nu skal jeg bare have
serveren til at sende siden som utf8.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk

---

Den 30-08-2011 22:55, Erik Ginnerskov skrev:
> Kim Ludvigsen wrote:
>
>> Du behøver ikke kopiere, du kan bare åbne filen i Notepad++,
>> ændre til UTF-8 uden BOM og så gemme igen.
>
> Ved "save/save as" af en eksisterende fil får jeg ingen
> mulighed for at vælge. Laver jeg en ny fil, får jeg mulighed
> for at definere tegnsæt - og med eller uden BOM.

Jeg har desværre stadig ikke en Windows ved hånden, men som
jeg husker det, er det ikke ved gemning, at du skal vælge
UTF i stedet, det er i menuen.

I henhold til denne side, har du et menupunkt der hedder
Format (i den engelske version):
http://npp-community.tuxfamily.org/documentation/notepad-user-manual/document-properties/encoding

--
Mvh. Kim Ludvigsen
Lav flotte fotoalbum på hjemmesiden:
http://kimludvigsen.dk/programmer-internet-jalbum.php

>> Du kan også opsætte Notepad++ til altid at gemme som UTF-8
>> uden BOM, det skal gøres i indstillingerne.
>
> Sådan er den sat nu - og jeg slap af med BOM, så nu skal jeg
> bare have serveren til at sende siden som utf8.
>

--
Mvh. Kim Ludvigsen

http://

---

Erik Ginnerskov wrote:

> Denne side:
>
> http://hjemmesideskolen.dk/html/elmnt/utf.php
>
> er gemt som utf8 og uploaded som binær. Alligevel kommer den til browseren
> som ISO-8859-1 og med nogle underlige tegn  flere steder, hvor der ikke
> skal være noget. Og de specielle danske bogstaver har den sædvanlige
> forvrængning.

Ja, og telnet er din ven:
<telnet session>
sj@lwork1> telnet hjemmesideskolen.dk 80
Trying 213.239.202.162...
Connected to hjemmesideskolen.dk.
Escape character is '^]'.
GET /html/elmnt/utf.php HTTP/1.1
Host: hjemmesideskolen.dk



HTTP/1.1 200 OK
Date: Tue, 30 Aug 2011 08:34:37 GMT
Server: Apache
X-Powered-By: PHP/5.3.3-7+squeeze3
Content-Length: 4938
Content-Type: text/html; charset=ISO-8859-1
</telnet session>

> Er det noget, jeg kan ændre på eller er det noget min webhost skal ændre
> på serveren?

Godt spørgsmål.

Hvis du ikke selv (i dit php) har sat charset, så er det sat op på serveren.
Om du har mulighed for at ændre det, ved kun din webhost.

Du kan dog prøve at sætte charset i din PHP og se om det 'overstyrer'
serveropsætningen.

PS til Kim.
Jeg _tror_ browserne efterhånden ignorerer BOM selvom det er et (MS skabt)
problem.

Nåh, men robtex:
http://www.robtex.com/dns/hjemmesideskolen.dk.html
siger du skal snakke med Wegge ;)

--
Med venlig hilsen
Stig Johansen

---

Den 30-08-2011 10:43, Stig Johansen skrev:

> Content-Type: text/html; charset=ISO-8859-1
>
> Du kan dog prøve at sætte charset i din PHP og se om det 'overstyrer'
> serveropsætningen.

Det må være webserverens indstilling, der overtrumfer; han
har det allerede i headeren:
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" />

> Jeg _tror_ browserne efterhånden ignorerer BOM selvom det er et (MS skabt)
> problem.

Vist ikke her. "" er netop de tegn, der vises, hvis der
er brugt BOM.

--
Mvh. Kim Ludvigsen
Undgå virus og andet snavs på computeren:
http://pc-sikkerhed.dk

---

Kim Ludvigsen wrote:

> Den 30-08-2011 10:43, Stig Johansen skrev:
>
>> Content-Type: text/html; charset=ISO-8859-1
>>
>> Du kan dog prøve at sætte charset i din PHP og se om det 'overstyrer'
>> serveropsætningen.
>
> Det må være webserverens indstilling, der overtrumfer; han
> har det allerede i headeren:
> <meta http-equiv="Content-Type" content="text/html;
> charset=utf-8" />

Ja, for serverens header er styrende, og man kan næsten læse ud af
definitionen (meta http-equiv(alent)), at det er en 'nødløsning' for de
servere, der ikke 'evner' at sende korrekte headere.

>> Jeg _tror_ browserne efterhånden ignorerer BOM selvom det er et (MS
>> skabt) problem.
>
> Vist ikke her. "" er netop de tegn, der vises, hvis der
> er brugt BOM.

Ja, men denne side er jo netop en 'rodebunke' mht charset.

Det jeg refererer til er en korrekt opsat server, der leverer charset=utf-8
og har BOM.

Jeg _ved_ min gamle Konqueror (på denne VM) viser BOM, men jeg mener nyerer
browsere ignorerer dem (forudsat charset=utf-8).

Men da det er Wegge's server, er det _ham_, der bestemmer opsætning og
muligheder, så det må være en sag mellem Erik og Wegge.

Wegge kan godt lide performance (tror jeg), så det er ikke umuligt, at
individuelle konfigurationer er disablet, da det er en absolut
performance-sluger.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Ja, men denne side er jo netop en 'rodebunke' mht charset.

Og dermed mener du ???

Alle sider undtagen denne er skrevet med ISO-8859-1 og denne er kun i utf8
for at vise problematikken hvis browseren viser forkert tegnsæt.

> Men da det er Wegge's server, er det _ham_, der bestemmer opsætning og
> muligheder, så det må være en sag mellem Erik og Wegge.

Jeg prøver at snakke med Wegge.

> Wegge kan godt lide performance (tror jeg), så det er ikke umuligt, at
> individuelle konfigurationer er disablet, da det er en absolut
> performance-sluger.

Er det mon noget, der for den ene side kan defineres i .htaccess ?

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk

---

Mig bekendt er det ikke Microsoft der opfandt Unicode så hvorfor du
mener at det er dem der har skabt problemet ved jeg ikke, bortset fra
at notepad som default gemmer UTF med BOM, men det er der mange andre
editorer der gør.
FAQ om Unicode.
http://www.unicode.org/faq/utf_bom.html#BOM

FAQ om brug i hjemmesider
http://www.w3.org/International/questions/qa-utf8-bom

De fleste nyere Browsere har ikke problemer med BOM men PHP har (i
hvertfald til version 5.3)

Regards Jens Peter Karlsen.

On Tue, 30 Aug 2011 10:43:52 +0200, Stig Johansen <wopr.dk@gmail.com>
wrote:

>Jeg _tror_ browserne efterhånden ignorerer BOM selvom det er et (MS skabt)
>problem.

---

Jens Peter Karlsen wrote:

> Mig bekendt er det ikke Microsoft der opfandt Unicode så hvorfor du
> mener at det er dem der har skabt problemet ved jeg ikke

Jeg snakker _ikke_ Unicode, men BOM i forhold til utf-8.
Oprindeligt var utf-8 defineret som standard til xml, og UDEN BOM.
MS valgte altid at sende BOM, hvilket fik alle andre (standardoverholdende)
parseren til at 'brække' sig.

Been there, done that, og du drømmer ikke om hvor meget tid 'vi' har brugt
på den konto.

Men det var jo i 'first mover' tiden (sidste årtusinde), så man skal
forvente den slags fra visse fronter.

--
Med venlig hilsen
Stig Johansen

---

On 30 Aug., 03:24, Stig Johansen <wopr...@gmail.com> wrote:
> Kim Ludvigsen wrote:
> > Den 30-08-2011 10:43, Stig Johansen skrev:
>
> >> Content-Type: text/html; charset=ISO-8859-1
>
> >> Du kan dog prøve at sætte charset i din PHP og se om det 'overstyrer'
> >> serveropsætningen.
>
> > Det må være webserverens indstilling, der overtrumfer; han
> > har det allerede i headeren:
> > <meta http-equiv="Content-Type" content="text/html;
> > charset=utf-8" />
>
> Ja, for serverens header er styrende, og man kan næsten læse ud af
> definitionen (meta http-equiv(alent)), at det er en 'nødløsning' for de
> servere, der ikke 'evner' at sende korrekte headere.

Man bør nu altid sætte sit tegnsæt ved serveren uanset. Dels er det et
performance-sprøgsmål, dels et sikkerhedsspørgsmål og dels et
stabilitetsspørgsmål. Ad. det sidste, så vil visse proxy-servere nægte
at læse meta-er[1], derfor vil de gå i kage, hvis tegnsæt ikke er sat
på serverniveau - hvadenten det så er selve serveren eller serverside
kode som definerer tegnsættet - sålænge det bare er HTTP som minimum.
Hvad der er særligt slemt ved proxier er, man kan ikke nødvendigvis
selv tjekke dem, so "better safe than sorry".

Ad. hastighed/stabilitet, læs evt.:
Google Page-speed Best practice
http://code.google.com/intl/da/speed/page-speed/docs/rendering.html#SpecifyCharsetEarly

(og: "Prefer HTTP over meta tag parameters")
http://gtmetrix.com/specify-a-character-set-early.html



[1] Af samme grund (proxier), anbefales det (fra Google) også at
afholde fra at bruge search string til samling af CSS- og JS-filer, da
visse proxier åbenbart heller ikke accepterer search string.



MVH
Rune Jensen

---

Den 30-08-2011 17:11, Rune Jensen skrev:
> On 30 Aug., 03:24, Stig Johansen<wopr...@gmail.com> wrote:
>> Kim Ludvigsen wrote:
>>
>>> Det må være webserverens indstilling, der overtrumfer; han
>>> har det allerede i headeren:
>>> <meta http-equiv="Content-Type" content="text/html;
>>> charset=utf-8" />
>>
>> Ja, for serverens header er styrende, og man kan næsten læse ud af
>> definitionen (meta http-equiv(alent)), at det er en 'nødløsning' for de
>> servere, der ikke 'evner' at sende korrekte headere.
>
> Man bør nu altid sætte sit tegnsæt ved serveren uanset.

Det er så et problem, når man benytter flere forskellige
tegnsæt som i detet tilfælde. Medmindre man kan lave noget
smart i .htaccess, men uanset hvor smart det er, vil det
sikkert blive noget rod.

--
Mvh. Kim Ludvigsen
Det nemmeste komma:
http://ordforklaring.dk/ordforklaring.php?forklaring=decimalkomma

---

Kim Ludvigsen wrote:

> Medmindre man kan lave noget
> smart i .htaccess,

Det var mit hint om at kontakte 'udbyderen'.
Det er ingen naturlov at 'lokale' .htaccess er tilladt (hint: performance).

--
Med venlig hilsen
Stig Johansen

---

Som de andre skriver så serveres din side som ISO-8859-1.
Så der er altså et eller andet i din PHP eller HTTP server opsætning
der gør at filen sendes med ISO-8859-1. Måske det bare er
standardopsætning.

I PHP kan du skriver :

header('Content-Type: text/html; charset=utf-8');

Så serveres filen med det i headeren.
Du skal skrive header() før du laver noget output i PHP. Det vil sige
for eksempel øverst i din kode.

---

Angående tegnene "" så er det som de andre skriver BOM tegn.
BOM står for Byte Order Mark og bruges af programmerne til at fortælle
hvad vej dataen skal læses i hver tegn så vidt jeg forstår men det er
ikke nødvendigt i UTf-8 har jeg læst fordi dataen vist kun kan læses
på en måde. Men kan vist også bruges så programmerne kan se hvilken
encoding filen er gemt i.

For at slippe af med BOM tegnene så skal du bare gemme dine filer som
"UTF-8 without BOM".
Det kan du som andre skriver i Notepad++ og andre programmer.

PHP 5 forstår ikke de her BOM tegn så de kommer derfor med i outputtet
på din hjemmeside før <!DOCTYPE og hver gang du include() en fil.

Læs eventuelt mere om det her :
http://scootergrisen.dk/phpgrisen/programmer_tekstredigering.php

---

scootergrisen wrote:

> Læs eventuelt mere om det her :
> http://scootergrisen.dk/phpgrisen/programmer_tekstredigering.php

Jeg kan se af din side, at min NP++ trænger til opdatering. Din har nogle
valgmuligheder, jeg ikke har til rådighed.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk

---

"Erik Ginnerskov" <erik.ginnerskov@live.dk> writes:

> Er det noget, jeg kan ændre på eller er det noget min webhost skal
> ændre på serveren?

Headeren der kommer med siden siger:

Connection:Keep-Alive
Content-Length:4937
Content-Type:text/html; charset=ISO-8859-1
Date:Tue, 30 Aug 2011 15:51:05 GMT
Keep-Alive:timeout=15, max=97
Server:Apache
X-Powered-By:PHP/5.3.3-7+squeeze3

Apache kan ikke gætte et tegnsæt, så du skal selv sørge for at
tilføje en header i din PHP-fil, inden det første output bliver skrevet.

Tilføj eksempelvis

header('Content-Type: text/html; charset=UTF-8');

i starten af filen, eller måske endnu bedre i headutf.inc.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

---

Anders Wegge Keller wrote:

> Apache kan ikke gætte et tegnsæt, så du skal selv sørge for at
> tilføje en header i din PHP-fil, inden det første output bliver
> skrevet.

Javel.

> Tilføj eksempelvis
>
> header('Content-Type: text/html; charset=UTF-8');
>
> i starten af filen, eller måske endnu bedre i headutf.inc.

Det blev øverst på siden inden include af header. Så kører det, tak til
alle.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk

---

Erik Ginnerskov skrev:

> Så kører det, tak til alle.

Det har ellers kørt fint i alle mine browsere, uden
problemer hele tiden, jeg har slet ikke set de
BOM'erter der har været

--
Allan Vebel
http://vebel.dk/wdg

---

Allan Vebel wrote:

> Det har ellers kørt fint i alle mine browsere, uden
> problemer hele tiden, jeg har slet ikke set de
> BOM'erter der har været

Hvor tit har du kigget på /html/elmnt/utf.php ? Det var kun den ene side,
som voldte problemer.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk

---

Anders Wegge Keller wrote:

> Tilføj eksempelvis
>
> header('Content-Type: text/html; charset=UTF-8');

Har der ikke (eller er der) ikke et problem hvis denne php fil er med BOM,
da BOM'en sendes før header?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmail.com> writes:

> Anders Wegge Keller wrote:
>
> > Tilføj eksempelvis
> >
> > header('Content-Type: text/html; charset=UTF-8');
>
> Har der ikke (eller er der) ikke et problem hvis denne php fil er med BOM,
> da BOM'en sendes før header?

Jo, det vil givetvis føre til en fejlmeddelelse fra header(),
medmindre php har en specialhåndtering af BOM. Og det tvivler jeg på
skulle være tilfældet.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

---

Anders Wegge Keller wrote:

> Stig Johansen <wopr.dk@gmail.com> writes:
>>
>> Har der ikke (eller er der) ikke et problem hvis denne php fil er med
>> BOM, da BOM'en sendes før header?
>
> Jo, det vil givetvis føre til en fejlmeddelelse fra header(),
> medmindre php har en specialhåndtering af BOM. Og det tvivler jeg på
> skulle være tilfældet.

Jeg er ikke så velbevandret udi Apache, men jeg tænkte på om Apache
ignorerer BOM for php-filer?

Det ville (lappe)løse mange af de problemer, der har været gennem tiderne.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmail.com> writes:

> Anders Wegge Keller wrote:
>
> > Stig Johansen <wopr.dk@gmail.com> writes:
> >>
> >> Har der ikke (eller er der) ikke et problem hvis denne php fil er med
> >> BOM, da BOM'en sendes før header?
> >
> > Jo, det vil givetvis føre til en fejlmeddelelse fra header(),
> > medmindre php har en specialhåndtering af BOM. Og det tvivler jeg på
> > skulle være tilfældet.
>
> Jeg er ikke så velbevandret udi Apache, men jeg tænkte på om Apache
> ignorerer BOM for php-filer?

Ikke som udgangspunkt, ihvertfald:

http://v2.test.wegge.dk/BOM.php

> Det ville (lappe)løse mange af de problemer, der har været gennem
> tiderne.

Ja, men det skal så ligge i mod_php.so, og ikke i apache selv.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

---

Anders Wegge Keller wrote:

> Ikke som udgangspunkt, ihvertfald:
>
> http://v2.test.wegge.dk/BOM.php

Ok, så er det som det 'plejer'.

>> Det ville (lappe)løse mange af de problemer, der har været gennem
>> tiderne.
>
> Ja, men det skal så ligge i mod_php.so, og ikke i apache selv.

Ja, jeg mente også php-module'et, og ikke selve Apache.

Men det burde vel være oplagt at lave en entry i f.eks. php.ini, der sagde
'ignore BOM'.

Og på den anden side - hvis man har en editor, der kan tvinges til at
undlade BOM i filen, så er 'problemet' vel løst.

Jeg synes bare jeg har set den fejl en del gange i grupperne, hvor man har
forslået den (forkerte) løsning at buffere output.

Nåh - never mind, dem der bufferer output har vel ressourcer 'nok'

--
Med venlig hilsen
Stig Johansen