[HTML] Speciale tekens worden niet goed weergegeven

[Matthijs1982]

Ik had een website gemaakt waarbij speciale tekens zoals het euro teken en trema's goed werden weergegeven. Doordat de website van hoster is gewisseld, heb ik een backup gemaakt met het cpanel systeem van de oude hoster en die bestanden bij de nieuwe hoster ge-upload. Nu blijkt dat de speciale tekens worden weergegeven als hokjes of in Firefox als vraagtekens.

Nu is mijn vraag eigenlijk, hoe is dit mogelijk, dat het bij de ene hoster wel werkt en bij de andere hoster niet. Komt dit omdat er door cpanel een backup van is gemaakt? De backup kan je namelijk vanuit cpanel downloaden als een .tar.gz bestand.

[CodeCaster]

Kijk even naar de Character Encoding van je hoster.

[Matthijs1982]

Waar kan ik die Character Encoding precies vinden?

[frickY]

Gaat het puur om HTML-bestanden, of hangt er ook een database achter?

Het kan zijn dat de hoster geforceert een karakter-set meestuurt. Kijk in de menubalk van je borwser eens bij Beeld / Codering/tekenset.
Indien dee op UTF8 staat, zet hem dan eens op iso-8859-1, of vice-versa.

[Matthijs1982]

Het gaat om php bestanden, waarvan het euro teken als HTML erin staat. In de tekst staan woorden met een trema en die komen uit de database. Die worden ook verkeerd weergegeven.

Ik heb de browser op Western Latin gezet en dan werkt het wel. Ik werk met Safari.

In elke pagina heb ik het volgende in de head staan:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

[ Voor 19% gewijzigd door Matthijs1982 op 23-12-2007 20:53 ]

[Sebazzz]

HTML encodeer je de tekens wel? Hiermee bedoel ik dat als je ' wilt weergeven dat je dat in je code zet als &#39;. Ik geloof dat Firefox daar problemen mee heeft (kijkende naar de PHP manual).

[ Voor 12% gewijzigd door Sebazzz op 23-12-2007 21:07 ]

[Matthijs1982]

Ik heb het euroteken nu vervangen door de html code voor het eruoteken en de database ingesteld op western latin.

Nu werkt het weer.

[ Voor 26% gewijzigd door Matthijs1982 op 23-12-2007 21:16 ]

[Cartman!]

Je hebt het probleem dus niet opgelost maar slechts een vieze workaround gevonden? Zorg dat je database + alle bestanden UTF8 encoding hebben en dan is er niets aan de hand.

[Geert.H]

Cartman! schreef op zondag 23 december 2007 @ 21:49:
Je hebt het probleem dus niet opgelost maar slechts een vieze workaround gevonden? Zorg dat je database + alle bestanden UTF8 encoding hebben en dan is er niets aan de hand.

kuch.. hoezo vieze workaround? Als hij toch gewoon netjes de html code voor een euro gebruikt is dat netter dan een euro teken gebruiken. Volgens mij is het nu goed opgelost en is dit niet een 'vieze' workaround

[RobIII]

Geert.H schreef op maandag 24 december 2007 @ 15:05:
[...]

kuch.. hoezo vieze workaround? Als hij toch gewoon netjes de html code voor een euro gebruikt is dat netter dan een euro teken gebruiken. Volgens mij is het nu goed opgelost en is dit niet een 'vieze' workaround

Er wordt gedoeld op het feit dat de verschillende encodings nu nog steeds bestaan in zijn oplossing, terwijl als je het 'goed' doet alles dezelfde encoding gebruikt (en dus is het toepassen van de HTML entities een workaround om het originele probleem te omzeilen, namelijk het verschil in encoding).

Ook al gebruik je netjes overal dezelfde encoding, het kan geen kwaad om dan alsnog HTML entities als &eacute; en &euro; te gebruiken (die ik dan weer leesbaarder vind dan &#233; en &#128; respectievelijk).

[ Voor 16% gewijzigd door RobIII op 24-12-2007 16:42 ]

[Borizz]

RobIII schreef op maandag 24 december 2007 @ 16:38:
[...]

Ook al gebruik je netjes overal dezelfde encoding, het kan geen kwaad om dan alsnog HTML entities als &eacute; en &euro; te gebruiken.

Dat kan inderdaad geen kwaad, maar indien de tekst uit de database komt, lijkt het me handiger om deze tekens als karakter op te slaan i.p.v. een entity. Zo kan je de tekst in de database ook nog makkelijk voor andere doeleinden gebruiken dan enkel weergave in HTML. Een export naar XML is al een goed voorbeeld, omdat XML standaard enkel de volgende entities kent:

code:

& > < " en '

[ Voor 1% gewijzigd door Borizz op 24-12-2007 16:48 . Reden: entities werden niet goed weergegeven ]

[RobIII]

Borizz schreef op maandag 24 december 2007 @ 16:47:
Dat kan inderdaad geen kwaad, maar indien de tekst uit de database komt, lijkt het me handiger om deze tekens als karakter op te slaan i.p.v. een entity.

Wie zegt dat ze als HTML entitiy in de database moeten komen staan? Je kunt net zo goed bij het outputten nog de de 'speciale tekens' encoden naar HTML entities en dan heb je best-of-both-worlds

Borizz schreef op maandag 24 december 2007 @ 16:47:
Een export naar XML is al een goed voorbeeld, omdat XML standaard enkel de volgende entities kent

Je kunt uiteraard ook verwijzen naar een DTD met daarin aanvullende entities

[ Voor 45% gewijzigd door RobIII op 24-12-2007 16:54 ]

[Borizz]

RobIII schreef op maandag 24 december 2007 @ 16:52:
[...]

Wie zegt dat ze als HTML entitiy in de database moeten komen staan? Je kunt net zo goed bij het outputten nog de de 'speciale tekens' encoden naar HTML entities en dan heb je best-of-both-worlds

Daarom gebruikte ik ook het woord 'indien' en verder ben ik het ook helemaal met je eens.

Je kunt uiteraard ook verwijzen naar een DTD met daarin aanvullende entities

Daar heb je ook helemaal gelijk in. Het was maar een voorbeeld.. Een export naar bijvoorbeeld CSV kent geen DTD namelijk . Wat ik dus bedoel is dat de gegevens zo opgeslagen zijn, zodat je er nog alle kanten mee op kan.

[ Voor 7% gewijzigd door Borizz op 24-12-2007 17:00 ]

[crisp]

RobIII schreef op maandag 24 december 2007 @ 16:52:
[...]

Je kunt uiteraard ook verwijzen naar een DTD met daarin aanvullende entities

Dat werkt enkel voor validating parsers

Sowieso is UTF-8 voor XML eigenlijk een 'should' (en ook de default indien er helemaal geen encoding opgegeven is).