[sql/html] Special chars krijgen ? na updaten blog - Softwareontwikkeling

zondag 15 juni 2008 00:46

Acties:

Compositionista!

Alpenmeisje

Topicstarter

Hallo,
vanavond heb ik mijn weblog in mijn website omgegooid naar een nieuw systeem. Dat heb ik gedaan door de tabel in de database te kopiëren en de velden aan te passen naar wat wenselijk was voor het nieuwe blogsysteem.

Alleen, sinds ik dat gedaan heb heb ik op de plekken waar special chars in mijn teksten staan opeens <?> van die mooie ikweethetniet tekentjes. Dat was voordien nog niet zo.

Ik heb gekeken naar 2 dingen: hoe het in de database staat en hoe de pagina ingeladen wordt.
Aan de database is eigenlijk niets veranderd. Vaag maar waar, maar het veld was en is een longtext en de collation is latin1_swedish_ci. Ik kan in phpmyadmin voor een aantal waarden kiezen. Ik heb 'm ook al op latin1_general_ci gezet en op utf8_general_ci. Helpt niks.
Wanneer ik in de phpmyadmin ook de inhoud van die velden bekijk dan geeft hij de special chars gewoon weer.

Het gaat mis zodra ik via mijn website het blog bekijk. Ook daar heb ik even gecheckt wat-ie nu doet.
De charset van de website was dit:

HTML:

<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-EU" lang="en-EU">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
enz.

En is nu dit:

HTML:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
enz.

Ja, ik zie wel duidelijk dat er in die beide tags een verschil zit. Nu heb ik die meta-tag al aangepast naar iso-8859-1 zodat hij gelijkend was aan de vorige. Hij staat dan genoemd ná die utf-8 aanduiding, dus ik denk dat hij hem overruled daarmee.

Over die html-tag ben ik niet zeker. Ik werk via een cms en kan niet vinden waar ik die kan aanpassen (ik kan altijd nog de code van de cms induiken, maar dat is de laatste optie).

Kan iemand me dmv. een link of een preek uitleggen wat ik fout doe en waarom ik nu opeens die <?> 's zie en in mijn vorige versie van m'n blog nog niet?

Edit: inmiddels heb ik gevonden waar ik de html tag aan kan passen (in mn template, ... zucht) en ook de metatag heb ik dus overruled. Zelfs de doctype heb ik gecheckt. En nog geeft hij nu, terwijl die drie dingen gelijkend zijn aan die van de vorige pagina met het blog erop, gewoon allemaal special chars niet goed weer. Zelfs niet met harde refresh. Help?

[ Voor 8% gewijzigd door Dark Blue op 15-06-2008 00:53 ]

heidiulrich.nl | adventura.nl : rugzakavonturen | pathwise.nl : prepping geeks to get jobs

zondag 15 juni 2008 00:52

Acties:

crisp

Devver

Pixelated

HTTP headers gaan boven <meta>, dus bekijk eerst eens je headers...

Intentionally left blank

zondag 15 juni 2008 00:53

Acties:

Dark Blue

Compositionista!

Alpenmeisje

Topicstarter

Mag ik vragen waar ik die kan bekijken...?
Bedoel je de <doctype> bovenaan het document? want die is gelijk...

code:

1	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

[ Voor 83% gewijzigd door Dark Blue op 15-06-2008 00:54 ]

heidiulrich.nl | adventura.nl : rugzakavonturen | pathwise.nl : prepping geeks to get jobs

zondag 15 juni 2008 01:07

Acties:

crisp

Devver

Pixelated

Installeer bijvoorbeeld eens liveHTTPHeaders in Firefox

Intentionally left blank

zondag 15 juni 2008 01:16

Acties:

Johnny

ondergewaardeerde internetguru

Dark Blue schreef op zondag 15 juni 2008 @ 00:53:
Mag ik vragen waar ik die kan bekijken...?
Bedoel je de <doctype> bovenaan het document? want die is gelijk...
code:
1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

In je browser kan je via View -> Character encoding zien welke charset er gebruikt wordt en handmatig een andere kiezen om te testen of dit ook daadwerkelijk het probleem oplost. Onder page info kan je sommige informatie uit de headers zien. Als je ze echt direct wilt bekijken heb je voor Firefox een plugin nodig zoals Web Developer of liveHTTPHeaders die hier al is genoemd.

Je moet dan vervolgens het blogsysteem aanpassen om ISO-8859-1 te gebruiken in plaats van UTF-8 wat wel eens lastig kan worden omdat je waarschijnlijk op verschillende plaatsen in de broncode moet gaan spitten. De verbinding die het systeem maakt met de database heeft zelf ook een encoding die waarschijnlijk op UTF-8 staat, dus als je de inhoud van de database, de meta tags en headers allemaal goed zet kan het alsnog mis gaan met vreemde tekens (Hindi, Chinees enz.).

De beste oplossing is om de data te converteren naar UTF-8 zodat je voor eens en altijd van het probleem af bent. De volgende query zou daarvoor gewoon moeten werken:

SQL:

1	ALTER TABLE table_name CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Je zal wel de encoding eerst via PhpMyAdmin terug moeten zetten zodat ze kloppen met de inhoud (ISO-8859-1) was want anders weet MySQL niet hoe de inhoud moet worden geconverteerd, en als het al UTF-8 is zal hij die velden gewoon negeren.

En de default charset van de database:

SQL:

1	ALTER DATABASE database_name DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_unicode_ci;

[ Voor 20% gewijzigd door Johnny op 15-06-2008 01:45 ]

Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.

zondag 15 juni 2008 10:36

Acties:

Voutloos

Dark Blue schreef op zondag 15 juni 2008 @ 00:53:
Mag ik vragen waar ik die kan bekijken...?

Dit is ook een te vaak voorkomend probleem, het hebben van onvoldoende kennis over HTTP. Weet je zeker dat je de belangrijkste request en response headers begrijpt? Begrijp je het verschil tussen GET en POST? Begrijp je de verschillende HTTP response codes etc. etc.

Wellicht gaan niet alle punten voor jou op, maar er zijn echt te veel mensen die alles in html proberen op te lossen (aan te klooien) terwijl het onderliggende protocol dit allemaal goed kan regelen.

Character encoding, caching regels, de client vertellen wat hij uberhaupt met de response kan, zorgen dat al dan niet idempotente acties goed gaan etc. etc. moet je allemaal via HTTP headers doen.

{signature}

zondag 15 juni 2008 12:58

Acties:

Dark Blue

Compositionista!

Alpenmeisje

Topicstarter

Ja Voutloos, inderdaad, ik weet maar weinig van GET en POST acties, van headers and so on.

4. Weet je zeker dat je op elk punt in je applicatie (correct) wat de encoding van elke string is? Vaak worden de HTTP headers of meta tags puur op de gok neergeplempt (trial & error) tot het probleem van huidige pagina opgelost is, maar als je vorige vraag niet kan beantwoorden, weet je ook niet of je het echt opgelost hebt, of toevallig de andere pagina's vernaggelt hebt.

...dat dus.

Dus rommel ik aan, zolang ik niks stukmaak. En ik kom het dan hier even vragen.

Ik heb even met mijn browser gecheckt wat hij als encoding kiest. Zowel FF als IE kiezen UTF-8, terwijl het hele document aangeeft ISO-8859-1 te zijn. Forceer ik hem naar Westers ( ISO-8859-1 ) of ( ISO-8859-15) dan gaat het opeens helemaal goed met die special chars.

Wat me nu opvalt, na het installeren van Live HTTP Headers, is dat eigenlijk alles goed gaat. Overal heb ik nu wel ISO-8859-1 in gebruik, in de code van mijn pagina's en in de headers geef ik dat aan enzo.

Maar de connectie met de database is UTF-8. Wanneer ik ingelogd ben op PHPMyAdmin kan ik dat ook niet veranderen. Ik kan wel de karakterset per database en per tabel veranderen. Heel specifiek heb ik die van de tabel waar dat blog uit moet komen nu op latin1_general_ci gezet.
Dat staat voor West-Europees niet-hoofdlettergevoelig. Ook hier: het is rommelen, maar het lijkt me de goeie.

Overigens kleine opmerking, mijn blog is helemaal in het Nederlands geschreven.

Ik weet niet waarom ik die MySQL Karakterset: UTF-8 Unicode (utf8) niet naar iets anders mag veranderen. De vraag is ook: zou dat wel moeten. Het is vast niet voor niets zo ingesteld? Ik kan wel alles geforceerd naar mijn gewenste karakterset om gaan zetten maar zoals je hierboven zegt, utf-8 is iets universeels, dus die zou dat aan moeten kunnen?

[ Voor 16% gewijzigd door Dark Blue op 15-06-2008 13:06 ]

heidiulrich.nl | adventura.nl : rugzakavonturen | pathwise.nl : prepping geeks to get jobs

zondag 15 juni 2008 13:37

Acties:

Johnny

ondergewaardeerde internetguru

Dark Blue schreef op zondag 15 juni 2008 @ 12:58:
Ja Voutloos, inderdaad, ik weet maar weinig van GET en POST acties, van headers and so on.

[...]

...dat dus.

Dus rommel ik aan, zolang ik niks stukmaak. En ik kom het dan hier even vragen.

Ik heb even met mijn browser gecheckt wat hij als encoding kiest. Zowel FF als IE kiezen UTF-8, terwijl het hele document aangeeft ISO-8859-1 te zijn. Forceer ik hem naar Westers ( ISO-8859-1 ) of ( ISO-8859-15) dan gaat het opeens helemaal goed met die special chars.

Dat is dan goed, nu weet je zeker dat je inhoud ISO-8859-1 is en intact is.

Wat me nu opvalt, na het installeren van Live HTTP Headers, is dat eigenlijk alles goed gaat. Overal heb ik nu wel ISO-8859-1 in gebruik, in de code van mijn pagina's en in de headers geef ik dat aan enzo.

Wat bedoel je met dat "alles goed gaat", dat zowel de headers als de meta tags nu op ISO-8859-1 staan, maar de tekens worden toch nog steeds verkeerd weergegeven?

Maar de connectie met de database is UTF-8. Wanneer ik ingelogd ben op PHPMyAdmin kan ik dat ook niet veranderen. Ik kan wel de karakterset per database en per tabel veranderen. Heel specifiek heb ik die van de tabel waar dat blog uit moet komen nu op latin1_general_ci gezet.
Dat staat voor West-Europees niet-hoofdlettergevoelig. Ook hier: het is rommelen, maar het lijkt me de goeie.

Als je de charset van de tabel nu overeenkomt met de inhoud dan kan je hem nu veilig omzetten naar UTF-8 met de query die ik eerder gaf. Als je dan de meta tags en headers ook terug zet naar UTF-8 zouden alle problemen moeten zijn opgelost.

Ik weet niet waarom ik die MySQL Karakterset: UTF-8 Unicode (utf8) niet naar iets anders mag veranderen. De vraag is ook: zou dat wel moeten. Het is vast niet voor niets zo ingesteld? Ik kan wel alles geforceerd naar mijn gewenste karakterset om gaan zetten maar zoals je hierboven zegt, utf-8 is iets universeels, dus die zou dat aan moeten kunnen?

Vaak is dit een instelling in het configuratiebestand waar alleen de hostingprovider toegang tot heeft en werkt dan voor alle verbindingen met alle databases op die server, als je het zelf wilt aanpassen zal je iedere keer dat je een verbinding maakt met de database doormiddel van een query de charset moeten instellen, het blogsysteem zet dus zijn eigen verbinding waarschijnlijk op UTF-8 of gebruikt de default, het is dus niet iets wat je in PhpMyAdmin kan instellen.

Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.

zondag 15 juni 2008 14:22

Acties:

Dark Blue

Compositionista!

Alpenmeisje

Topicstarter

Johnny schreef op zondag 15 juni 2008 @ 13:37:
Wat bedoel je met dat "alles goed gaat", dat zowel de headers als de meta tags nu op ISO-8859-1 staan, maar de tekens worden toch nog steeds verkeerd weergegeven?

Nou, ik doorloop de lijst die Live HTTP Headers me uitpoept bij het inladen van de pagina. En telkens onderaan het tweede kopje zie je wat de karakterset is. En die is overal ISO-8859-1, bij elke request naar content, naar plaatjes, noem maar op. Behalve bij de éérste request naar de database, daar is hij UTF-8.

Als je de charset van de tabel nu overeenkomt met de inhoud dan kan je hem nu veilig omzetten naar UTF-8 met de query die ik eerder gaf. Als je dan de meta tags en headers ook terug zet naar UTF-8 zouden alle problemen moeten zijn opgelost.

Okay, dat wil ik wel eens proberen. Kun je precies zeggen wat je bedoelt met 'als de charset van de tabel nu overeenkomt met de inhoud'? De charset van de tabel is nu latin1_general_ci. De charset van het veld staat ook op latin1_general_ci. Ga ik per veld de inhoud bekijken, dan krijg ik dus inhoud in inputboxes onder elkaar. Heb ik daar toevallig een woord met rare tekens in staan, dan staat er gewoon "Het schaap creëert een hoopje" en niet "Het schaap cre & euml ; ert een hoopje".

Vaak is dit een instelling in het configuratiebestand waar alleen de hostingprovider toegang tot heeft en werkt dan voor alle verbindingen met alle databases op die server, als je het zelf wilt aanpassen zal je iedere keer dat je een verbinding maakt met de database doormiddel van een query de charset moeten instellen, het blogsysteem zet dus zijn eigen verbinding waarschijnlijk op UTF-8 of gebruikt de default, het is dus niet iets wat je in PhpMyAdmin kan instellen.

Ik heb mijn hoster ook al gemaild, zo van, het staat op UTF-8, je zult dat vast wel om een reden hebben gedaan... en met de vraag of hij weet wat ik kan doen om m'n special chars goed weer te geven. Ik denk dat hij het niet voor me gaat veranderen

... zoals jij hierboven laat zien kan ik waarschijnlijk middels een conversie al mijn documenten wel op UTF-8 krijgen én goed laten weergeven.

heidiulrich.nl | adventura.nl : rugzakavonturen | pathwise.nl : prepping geeks to get jobs

zondag 15 juni 2008 15:34

Acties:

Johnny

ondergewaardeerde internetguru

Dark Blue schreef op zondag 15 juni 2008 @ 14:22:
Okay, dat wil ik wel eens proberen. Kun je precies zeggen wat je bedoelt met 'als de charset van de tabel nu overeenkomt met de inhoud'?

Je inhoud is in jouw geval Nederlandstalige tekst die gecodeerd als ISO-8859-1, (latin1) maar MySQL weet dat niet, die ziet alleen wat bytes, daarom moet je zelf aangeven hoe de inhoud is gecodeerd. Wat je eerst deed was gewoon een andere codering kiezen, maar dat loste het probleem niet op omdat je inhoud gewoon hetzelfde bleef was, alleen MySQL dacht dat het UTF-8 was en de beschrijving dus niet meer klopt met de inhoud.

De charset van de tabel is nu latin1_general_ci. De charset van het veld staat ook op latin1_general_ci. Ga ik per veld de inhoud bekijken, dan krijg ik dus inhoud in inputboxes onder elkaar. Heb ik daar toevallig een woord met rare tekens in staan, dan staat er gewoon "Het schaap creëert een hoopje" en niet "Het schaap cre & euml ; ert een hoopje".

Nu komt de inhoud dus overeen met de beschrijving, dus kan MySQL de tabel correct vertalen van de ene naar de andere encoding met behulp van de gegeven query.

Entities zoals ë staan hier trouwens helemaal los van, die worden alleen gebruikt in HTML om tekens weer te geven die niet in de gebruikte encoding zitten. Met UTF-8 zou je nooit meer entities nodig moeten hebben.

[ Voor 10% gewijzigd door Johnny op 15-06-2008 15:34 ]

Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.

zondag 15 juni 2008 17:41

Acties:

Dark Blue

Compositionista!

Alpenmeisje

Topicstarter

Nu snap ik er niets meer van. Ik heb gedaan wat je zei, maar de pagina blijft die ? tekens weergeven met UTF-8.

HTML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml" xml:lang="nl" lang="nl">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
enz.

Ik heb beide queries uitgevoerd op de gegeven dingen:
bovenste query op mijn tabel, onderste query op mijn database. Overal zegt hij nu utf8_unicode_ci te zijn. De tekst in het veld staat er ook nog steeds gewoon zoals je het opleest.. met ë's enzo. Is er nu iets veranderd?

*linkjes weggehaald... niet zoveel bezoek nodig*.

Edit: Het is gelukt! Na het lezen van deze pagina over Mambo heb ik eens gekeken naar de config.php file van mijn eigen CMS (CmsMadeSimple).

En ja, daar mag je zelf een karakterset aangeven... en die was leeg. Die ISO dinges erin gezet, weer geupload... alles in de pagina ook naar ISO gezet, en tada! Hij doet het. In de tabel in de database staat nu alles nog wel als UTF-8. Op de trial en error manier is het dit keer dus gelukt om het goed te krijgen...

Nog even ter verduidelijking; mijn vorige blog kwam uit een heel apart blogsysteem (met eigen config files, requests naar de database) dus die zal wel érgens in z'n files hebben gehad dat hij ISO encoding moest gebruiken... waarschijnlijk dat hij daarom goed ging voorheen.

[ Voor 46% gewijzigd door Dark Blue op 15-06-2008 17:56 ]

heidiulrich.nl | adventura.nl : rugzakavonturen | pathwise.nl : prepping geeks to get jobs