Rare tekens in tekst

Status
Niet open voor verdere reacties.
L

lerrie

Gebruiker
Lid geworden
2 nov 2010
Berichten
300
Sinds kort kwam ik erachter dat op meerdere website die ik gemaakt heb op plekken waar een € teken, ® teken of bijv. ©teken moet staan een ander raar teken staat. Ik weet dat ik dit opkan lossen door ipv van een euro teken te typen in de html €
neer kan zetten. Maar is er een manier om websites dit automatisch te laten doen?

Groeten
 
Utf-8

Hoi lerrie,

Dit probleem wordt meestal veroorzaakt door het ontbreken van de juiste charset-toekenning in de HTML-code.

Door onderstaande code in de HEAD van de HTML te plaatsen zal de browser weten hoe om te gaan met speciale karakters:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

In de characterset UTF-8 zitten alle gangbare karakters die in diverse talen wordt gebruikt.

Ik zie dat in de site die u als link heeft neergezet deze code reeds aanwezig is en dan blijft alleen nog de optie open om het HTML-document
zelf als UTF-8 document op te slaan.

Zodra uw website door de browser als UTF-8 wordt weergegeven zijn de de "rare" karakters weg!

Mijn ervaring is dat veel HTML-editors pagina's als ANSI opslaan waardoor dit soort problemen kunnen ontstaan. Door specifiek het document
als UTF-8 op te slaan kan het haast niet mis gaan.

Groeten,
Ivar Snel
http://www.codeplaza.com
 
Laatst bewerkt:
Utf-8

Hoi lerrie,

Dan wordt mijn vermoeden toch bevestigd!

Sla het HTML-document in uw editor op als UTF-8 [zonder BOM]. Mocht dat niet lukken in de editor: gebruik dan Notepad++. Dit is een freeware tool die veel gebruikt wordt. Deze tool is met name sterk in het omzetten van documenten in andere charsets.

Dus houdt er rekening mee dat er op twee niveau's de charsets bepaald wordt. Op de eigenschap van het document en de inhoud er van.

Ivar Snel,
http://www.codeplaza.com
 
Utf-8

Gebruik anders Notepad++ [http://notepad-plus-plus.org] voor deze actie.

Open het HMTL-document in deze editor en kies vervolgens in menu voor Encoding en kies voor Convert to UTF-8 without BOM. Sla het document op en upload het naar uw webserver.

De W3C-test zou nu in ieder geval een charset moeten zien die gelijk aan de inhoud is [UTF-8 i.p.v. iso-8859-1]
 
ik gebruik zelf dreamweaver voor mijn html coding. Alleen snap nu niet goed wat het probleem is. Er mist een code voor de body? Want in de head staat die al?
 
Het rare is dat de pagina al Utf-8 is! Dus ik zie niet waarom hij als iso-8859-1 gelezen wordt want dat staat toch nergens?
 
Utf-8

Dat klopt! Die eigenschap van het document zelf kun je niet in broncode van de HTML afleiden. Je zult dit echt in de editor zelf moeten instellen/uitlezen.

Ik wil toch adviseren om de tool Notepad++ te gebruiken, omdat je daar direct kunt zien in de statusbalk van de tool welke charset er daadwerkelijk gebruikt wordt. Dat zal waarschijnlijk ANSI zijn [waar de iso-8859-1 set onder valt].

Sluit anders het document als bijlage bij. Dan zal ik er eens naar kijken.
 
Hoi lerrie,
Ik probeer even de stand van zaken op te maken.

Probleem 1 bestaat niet (meer).
Als ik de homepage van dit moment via FF of IE download en dan open met Notepad++, dan zegt deze dat de pagina als utf8-bestand gecodeerd is.
Dus Dreamweaver heeft 'm als utf-8 opgeslagen, terwijl de <meta> charset ook utf-8 is. Dat is dus in principe in orde.
Omdat deze twee synchroon lopen, zoals het hoort, kan je bij het aanmaken gewoon accenttekens en €'s via het toetsenbord intikken.
Zoals Mister Quick al zei, gaat het mis als niet opgeslagen wordt volgens de gehanteerde charset in de <meta>.
Dit gaat dan over rare tekens die in de tekst zelf komen te staan. - En die zouden er dus niet mogen zijn.

Probleem 2 bestaat nog wel.
Waarschijnlijk bedoel je deze tekens aan het begin, nog voordat er tekst staat:

ess-bom.png

Dat frutseltje  is te zien in Firefox, niet in andere browsers.
En dat betekent dat er inderdaad een "BOM" in het bestand zit.
Dat staat voor Byte Order Mark, en die kan de zaak verstieren ook al is de pagina met de correcte codering opgeslagen.
Zo'n BOM heeft te maken met de interne huishouding van de computer (Windows, I presume?), en hoort niet geexporteerd te worden bij het uploaden naar je server. Achtergrond van de BOM: zie hier ("Many Windows programs add BOMs to UTF-8 files by default.").
Het lastige is, vanwege het interne machinecode-karakter, dat zo'n BOM in de broncode van een bestand totaal niet te zien is.

Hoe kom je er af?
De raad van Mister Quick opvolgen: in Notepad++ (even gratis downloaden) de pagina converteren naar "utf-8 zonder BOM", en dan opslaan.
  • Voor alle veiligheid zet ik daarbij in het bestand ergens op een onschadelijke plaats een extra spatie, zodat het 100% zeker een nieuw bestand met dezelfde naam wordt.

Probleem 3 is geen probleem.
Blijft over het gemopper van de html-validator, die ondanks alle utf-8 settings de pagina toch als iso-8859-1 ziet binnenkomen.
Dit heeft echter met iets totaal anders dan het bovenstaande te maken!

De html-validator heeft het over de "HTTP-header", en dat is iets anders dan wat in de <head> van de pagina staat! De "HTTP-header" bestaat uit diverse informatie over het data-pakketje dat verzonden wordt: dat pakketje omvat deze header en de data van het bestand zelf (in ons geval: de html-paginacode).
  • Een "HTTP-header" met charset gegevens kan, los van alles, meegestuurd worden door de server van de site. Of dat gebeurt, en welke charset dan wordt aangegeven, is afhankelijk van de server/provider.
Mijn provider doet het bv. niet, en als je in de Developer Toolbar via "menu: Information > View Response Headers" van de pagina rare-tekens-1.htm de server-gegevens opvraagt zie je dit:
Code: 
Date: Mon, 07 Nov 2011 10:51:31 GMT
Server: Apache/2
Last-Modified: Mon, 07 Nov 2011 08:59:29 GMT
Etag: "88980cb-26d-4b12145be9e40"-gzip
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 427
[B]Content-Type: text/html[/B]

200 OK
Bij jouw elektrischeskateboardshop-pagina zie je echter:
Code: 
Date: Mon, 07 Nov 2011 09:17:46 GMT
Server: Apache
Last-Modified: Mon, 07 Nov 2011 05:40:39 GMT
Etag: "868b29-2f40-4b11e7ea943c0"
Accept-Ranges: bytes
Content-Length: 12096
[B]Content-Type: text/html; charset=iso-8859-1[/B]

200 OK
Daar is de iso! :)
Nu schrijven de reglementen voor, dat de charset in een HTTP-header (indien aanwezig) voorrang heeft boven een charset in een <meta> definitie; zie o.a. hier. Daarom houdt de html-validator ook de iso-codering aan, ondanks de <meta> met de utf-8.

Wat betekent dit nu in de praktijk?
Meestal gebeuren er met de West-Europese iso-8859-1 charset geen ongelukken als je in utf-8 werkt en gewoon Nederlands in de site gebruikt, zonder buitenissige lettertekens die niet in de iso-charset (zie hier en hier) werken.
  • Eventueel zou je ook de iso-charset kunnen overrulen met een eigen HTTP-header. Die kan je opgeven als je er een php-site van maakt, waarin je op elke pagina als eerste regel zet (dus nog boven de Doctype declaratie):
PHP: 
<?php header("Content-type: text/html; charset=utf-8"); ?>
Voor de validatie zelf maakt het meestal weinig uit (zie ook m'n reactie op deze), anders wordt alleen alarm geslagen bij zo'n buitenissig letterteken. En zolang je op de pagina's zelf geen zwarte blokjes, lege mini-rechthoekjes of vraagteken-wybertjes tegenkomt in de tekst, kan je rustig slapen.

Resteert dus eigenlijk alleen maar het BOM-vrij maken.
En de echte html-errors. ;)

Met vriendelijke groet,
CSShunter
 
Laatst bewerkt:
De BOM is eruit! Hoe kan ik er voor zorgen dat die ISO uit mijn header gaat? En dat dit in het vervolg niet meer gebeurd?
 
Hoi lerrie,
Mooi, ik zie de BOM ook niet meer in FF! :thumb:

Zoals ik zei, wordt de iso er in geblazen door de server. Ik zou me er niet zo geweldig druk over maken. Maar als je dat er uit wilt halen, lukt het waarschijnlijk door het genoemde regeltje bovenaan in je pagina's (allemaal afzonderlijk) te zetten:
HTML: 
<?php header("Content-type: text/html; charset=utf-8"); ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
... enz.
BOM-loos opslaan, en vervolgens de pagina's hernoemen van .htm of .html tot .php en weer uploaden.
Je kan het eens met één pagina uitproberen: dat zou de server-instelling moeten overrulen.

Met vriendelijke groet,
CSShunter
_____________
PS: IE7 doet het inmiddels goed met de footer, en ook de slideshow draait nu ook prima in IE7. :)
Ondanks de nu 43 html-errors: toch wonderbaarlijk, die verstandhouding tussen html en IE. ;)
 
Bedankt! Ga die regel dan vanaf nu wel boven de paginas zetten. Weet dat het niet heel belangrijk is maar wil er voor
zorgen dat ik weet waarom W3C bepaalde errors geeft. Ik gooi er een slotje op.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan