11–
Via een artikel op de site opinieleiders.nl getiteld De Telefoongids Websites, dat verwijst naar De Telefoongids Websites op de site adverterenopinternet.info, en het vervolgartikel De Telefoongids bouwt ook websites: eenheidsworst, kwam ik te lezen op de site Hardcopy van de “freelance (SEO-)copywriter” David Brinks, en wel in dit artikel.
Maar daar gaat het me nu eigenlijk niet om.
(Waarom noem je het dan allemaal zo omstandig op?
Nou ja, laat maar.)
Het gaat me om twee
“gerelateerde artikelen posts”
die daaronder vermeld stonden en staan:
Waarom sommige websites niet werken (deel 1),
en
Waarom sommige websites niet werken (deel 2)
uit augustus 2005. Ze staan daar dus al dik 6 jaar.
De titels en de tekst maakten me nieuwsgierig. Ik dacht er nog wat van te kunnen leren. Ik maakte een notitie om de tips later nog eens grondig te bestuderen en er mijn voordeel mee te doen. Nooit te oud om te leren.
Bij vluchtige lezing zag ik in het eerste deel alvast staan:
“[...] Maar andere sites leiden
een zieltogend bestaan.
De reden: de bouwers van deze sites zondigen tegen de
elementaire wetten van internet.
In dit artikel vindt u de eerste drie veel gemaakte fouten.
1. Het is onduidelijk wat de bedoeling van de site
is
De tijd dat mensen nieuwsgierig en tamelijk willekeurig
over het web surften ligt achter ons. Het nieuwtje is
er allang vanaf. Mensen zoeken gericht naar nuttige
informatie.”
Daar zit wat in. Dat kon best wel eens ook bij mijn eigen site een probleem zijn. Op het eerste gezicht is het onderwerp niet duidelijk. Is ook lastig aan te geven, want ik schrijf over veel onderwerpen. Maar ik ga nog eens peinzen of en hoe ik dat kan verbeteren, hoe ik de bedoeling van de site meteen duidelijker kan maken.
Op de site Topsy.com, waarvan het onderdeel topsy.com/rudhar.com, dat ik weer vond via Sites Linking to Rudhar.com van Alexa.com (ja ja, ik surf wat af op dat wereldwijde web, vaak op zoek naar mezelf!) vond ik een tweet® van 27 september 2011, getwitterd door Vincent Tijms die vrijwel letterlijk dezelfde formulering gebruikte als David Brinks, en die luidde:
“Sites als deze leveren me een gevoel van faux nostalgie op. http://t.co/OWUVPBce Wat is de bedoeling ervan? En waarom in Frontpage?”
Deze twitteraar denkt dus dat ik mijn site gebouwd heb met Frontpage terwijl ik dat hulpmiddel in werkelijkheid nog nooit gebruikt heb, uit principe omdat Frontpage® van Microsoft® is en ik gemerkt heb dat Microsoft en html/css niet goed samengaan. Ik bouw nog altijd alles met de hand in een teksteditor met vrijwel alleen html en css.
Het zou dus zomaar kunnen dat Vincent Tijms minder van webbouwerij begrijpt en weet dan hij zelf denkt. Niettemin, zijn verzuchting “Wat is de bedoeling ervan?” is geldig en die hou ik in gedachten.
Nu kom ik op het onderwerp en bij de titel van dit artikel. (Nu pas? Ja, nu pas.)
In voornoemd artikel van David Brinks lees ik:
“4. Fouten
Zelfs de kleinste fouten worden door (sommige) bezoekers
opgemerkt. Het is slordig en maakt een onprofessionele
indruk. [...]
Het credo is: controleren, controleren en nog eens
controleren.”
Zeg dat wel! Een waar woord.
Wat dan weer zo jammer is, is dat de auteur van deze website dat zichtbaar zelf niet doet, dat controleren. Op deze en andere pagina staan namelijk veel opvallende en storende fouten: zwarte ruitvormige tekentjes met een vraagteken erin, gevolgd door nog twee vraagtekens.
Mochten de fouten later verbeterd worden – zo zag het eruit toen ik ze opmerkte en toen in mijn artikel schreef: fragment.
Voor de zorgvuldigheid mag ik natuurlijk niet zomaar aannemen dat de fout in de site zit. Het kan ook de browser zijn. Daarom heb ik het verschijnsel in een heleboel verschillende getest, allemaal onder Windows Vista:
Overal zie ik dezelfde foute weergave. Wel liet Opera in plaats van het vraagteken in een zwarte ruit zo’n vaag vierkant blokje zien. Maar ook dat duidt op een ongeldig teken.
Wacht even! Wacht even! Wat ook kan: het is een grap! Het is zelfspot!
Dan vind ik het wel leuk gedaan.
Maar waarom zie ik dan dezelfde fout ook op andere plekken, zoals in het artikel Jumbo maakt zichzelf belachelijk? Ook weer zelfspot? David Brinks stelt dat een ander bedrijf zichzelf belachelijk maakt en doet het dan ter relativering en passant zelf ook? Het kan. Maar dat lijkt me dan toch ietwat overdone.
Voor de zekerheid hieronder toch maar de technische uitleg.
Ik heb de pagina’s ook opgehaald met een offline browser ofwel een webgrabber. Ik gebruikte Teleport Pro™, versie 1.41. Een al weer wat ouder programma, maar het bevalt mij goed.
Zo kon ik de achterliggende codering bestuderen in een teksteditor en met Unix-hextool od.
Dat ruitvraagteken kwam mij bekend voor. Ik heb het vaker gezien en altijd op sites waar iets mis was met de tekencodering, in verband met UTF-8.
Je krijgt dat teken te zien als je een pagina
codeert in ISO-8859-1 of de bijna identieke
Windows-codepage 1252, maar je
beweert
in de header van de pagina dat de codering UTF-8 is.
Dit kan zo:
<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
Uitgebreide info is te krijgen bij w3.org.
Ik heb het even getest met een
pagina
die ik (met hulp) in het Portugees schreef,
een taal met veel letters met accenten erop,
zodat je meer nodig hebt dan alleen ASCII.
Als ik daarin het correcte
charset=iso-8859-1 verander in
utf-8 (of UTF8 of UTF-8, dat schijnt
allemaal niet uit te maken), dan veranderen bij
weergave op het scherm met een browser, alle
bijzondere tekens zoals ç, à, á, â, ó, ô, é, ê,
ã en õ inderdaad in van die vraagtekens
in een ruit.
Maar hier is dat niet de oorzaak, want die header geeft UTF-8 aan en het lijkt alsof de pagina ook zo gecodeerd is.
Uit de context lijkt het de bedoeling ronde aanhalingstekens te gebruiken, en bij codering in UTF-8 bestaan die inderdaad uit drie bytes waarvan de eerste hexadecimaal e2 is (als dit wordt bekeken alsof het ISO-8859-1 is, ziet dat eruit als â; op dezelfde manier herken je verkeerd geïnterpreteerde UTF-8 voor ‘gewone’ accentletters aan de beginbyte c3 (ziet eruit als Ã) met maar één volgbyte.
Dat het toch niet goed gaat, komt doordat de correcte volgbytes niet volgen: er staan steeds gewoon twee vraagtekens (hex 3f) na het teken hex e2!
Mijn vermoeden is dat de ronde aanhalingstekens er ooit correct stonden, waarna het bestand is opgeslagen als Unicode in de codering UTF-8. Vervolgens zijn de bestanden bewerkt met een stuk software dat de tekst niet als UTF-8 interpreteerde, maar zich strikt hield aan de tekenset ISO-8859-1.
In de UTF-8-codering van de ronde aanhalingstekens komen bytes voor met de waarden hexadecimaal 80, 98, 99, 9c en 9d. Deze zijn in ISO-8859-1 ongedefinieerd (hoewel ze in Windows codepage 1252 wel bestaan).
In een starre softwareopvatting zou het legitiem kunnen zijn om zulke ongeldige tekens te vervangen door vraagtekens. (Als ik zelf zulke software moest schrijven zou ik dat niet doen maar er liever gewoon afblijven, dus laten staan wat wordt aangeboden. Maar niet iedereen denkt er zo over.)
Door die vraagtekens staan er (nu weer geïnterpreteerd als UTF-8, zoals de paginaheader aangeeft) geen ronde aanhalingstekens meer. Sterker nog, er staat helemaal geen geldige UTF-8 meer, omdat die codering min of meer zelfcontrolerend is:
Na een inleidende UTF-8-byte (die altijd begint met een 1-bit) moet iets volgen dat begint met een 1-bit en een 0-bit. Een vraagteken is 3f in ASCII/ISO-8859/UTF-8, dat begint met twee 0-bits en dat is dus per definitie fout. Vandaar die rare ruit met een vraagteken erin. De header zei dat UTF-8 te verwachten was en dit is geen UTF-8, maar troep.
Het zou ook kunnen dat de pagina’s oorspronkelijk in Windows codepage 1252 waren. Daarin zijn ronde aanhalingstekens mogelijk op codeplaatsen die in ISO-8859-1 ongeldig zijn.
Vervolgens zijn de html-bestanden geconverteerd naar UTF-8 met een conversietool dat recht in de leer is en als broncodering ISO-8859-1 opkreeg of aannam. In die laatste tekenset ongedefinieerde tekens werden toen niet meegecodeerd, maar vervangen door een ongeldige UTF-8-bytereeks.
Niet erg slim of verstandig van die software, vind ik. Als het echt zo gebeurd is, want dat is dus maar een onbewezen theorie van mij.
Het veiligste is bij de codering van HTML alleen ASCII te gebruiken (7-bits tekens dus, ofwel het meestwaardige bit in een 8-bits byte is altijd nul), en al het andere te realiseren via zogeheten entities.
Zelf gebruik ik vrijwel consequent (dit is de enige uitzondering) ISO-8859-1. Alles wat daarbuiten valt (ook dat wat CP1252 wel heeft maar ISO-8859-1 niet) doe ik met entities. Het gaat dan om ronde aanhalingstekens, gedachtestreepjes (–), maar ook incidenteel om Arabische tekens en woorden, en als demonstratie ook wel tekens uit andere talen.
ISO-8859-1 biedt ruime ondersteuning voor veel veelgebruikte talen, van IJsland tot Albanië en van Finland tot Madeira. Alle talen waarin ik wel eens schrijf, Nederlands, Engels, Duits en Portugees (zeer incidenteel Frans en Spaans), zijn ermee mogelijk.
Alles rechtstreeks in Unicode, bijvoorbeeld gecodeerd als UTF-8, dat kan natuurlijk ook, mits goed aangeduid in de header, en mits de software die je voor het onderhoud gebruikt, daar goed mee om weet te gaan. Zelf ben ik daar liever niet afhankelijk van. ISO-8859-1 met entities (die zelf per definitie altijd uit alleen ASCII bestaan) is met vrijwel elke teksteditor goed te verwerken. Dat bevalt mij goed. Het werkt betrouwbaar.
Reacties en nuancering, 12/13 november.
Copyright © 2011 by R. Harmsen, alle rechten voorbehouden, all rights reserved.