OPGELOST: Juiste character set gebruiken (mysql->php->html)

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Erwin H

Erwin H

13/06/2012 15:25:28
Quote Anchor link
Niet echt een vraag die nog nooit voorbij is gekomen, maar op de een of andere manier krijg ik de settings niet juist. Volgens mij volg ik alle punten die ik er ooit over gelezen heb, maar het klopt niet...

Situatie:
Ik heb een tekst in mijn database staan waarin het woord 'Höxter' zit. Dus met een o-umlaut (ja het is Duits). Als ik via de command line tool in mijn MySQL database kijk dan staat het er letterlijk zo.
Probeer ik het naar het scherm te krijgen dan krijg ik niet die o-umlaut, maar iets anders.

De stappen die ik al heb gezet:
1) controle of de database wel de correcte charset heeft: staat nu op utf8_general_ci (tabel en kolom).
2) connectie met de database zet ik via een query "set names 'utf8', character set 'utf8'" ook op utf8. Dit heeft effect, want als ik het niet doe krijg ik andere tekens. Overigens gebruik ik PDO.
3) bij het versturen naar de browser stuur ik de volgende header mee: 'Content-type: text/html; charset=utf8'
4) in mijn HTML heb ik nog een meta tag met: <meta content="text/html; charset=utf8">

Dus, database staat op utf8, connectie is utf8, header is utf8, meta tag is utf8. En toch krijg ik niet de juiste tekst in beeld. Wat ben ik nog vergeten, of in welke stap hierboven is een foutje geslopen?
Gewijzigd op 13/06/2012 17:05:23 door Erwin H
 
PHP hulp

PHP hulp

12/10/2024 00:13:15
 
Kris Peeters

Kris Peeters

13/06/2012 15:37:29
Quote Anchor link
Kan je zien naar mijn reactie hier?

http://www.phphulp.nl/php/forum/topic/utf8-/84693/#603653

Volgens mij zo ongeveer het zelfde probleem
 
- SanThe -

- SanThe -

13/06/2012 15:42:43
 
Erwin H

Erwin H

13/06/2012 15:56:23
Quote Anchor link
@Kris,
Het enige andere wat ik daar zie is dat je utf8_unicode_ci gebruikt, in plaats van utf8_general_ci. Wat ik heb gelezen zou dat niet uit moeten maken (maar heb ik nog niet geprobeerd).

@Santhe
iso ipv utf gebruiken in de html helpt in mijn geval niet. Wat ik wel interessant vond in dat topic was de &..; codes gebruiken in plaats van de echte tekens. Daar ga ik nog even op verder. Misschien dat ik daar mee verder kom.

Toevoeging op 13/06/2012 16:01:07:

Nope, dat werkte dus ook niet. Ik heb de string geconverteerd met htmlentities, maar dat helpt helemaal niets. Het lijkt alsof de string die erin gaat al incorrect is, dus dat het probleem zit bij het uitlezen van de database. In de database zit het goed, dat kan ik controleren, maar het komt er blijkbaar niet goed uit.
 
Kris Peeters

Kris Peeters

13/06/2012 16:08:53
Quote Anchor link
Ik heb mijn code zelf nog eens geprobeerd.
Juist find/replace "euro" -> "umlaut", kwestie dat alles nieuw is (nieuwe DB-tabel aangemaakt, ...).

Ik heb geen enkel probleem met ümlauts
 
Erwin H

Erwin H

13/06/2012 16:12:33
Quote Anchor link
Die laatste opmerking begrijp ik niet helemaal, hoe wil je dat ik die characters zoek? Bedoel je met een str_replace?

Overigens net even gechecked met mb_check_encoding en de string die uit de database komt is volgens die check wel een correcte UTF-8 string.
 
- SanThe -

- SanThe -

13/06/2012 16:14:19
Quote Anchor link
Ik begrijp het ook nog steeds niet helemaal.

Als ik, zoals hierboven, Höxter als voorbeeld neem.
En ik geef dat in bij <input type="text" name="naam"/>
Als er gepost is doe htmlentities($_POST['naam']);

Bij gebruik van
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
wordt het een rommeltje met in de broncode: H&Atilde;&para;xter
En gebruik ik
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1" />
dan is het netjes leesbaar en in de broncode: H&ouml;xter
 
Reshad F

Reshad F

13/06/2012 16:14:58
Quote Anchor link
yep je moet gewoon zoals wouter zegt al die rare tekens. ë á etc etc die er zijn in een array zetten in de utf_8 variant. wanneer je het weer weergeeeft op je scherm een decode erop gooien.
 
Erwin H

Erwin H

13/06/2012 16:16:07
Quote Anchor link
Bij mij wordt het nog grappiger. Ik heb net met een str_replace de ö door de o vervangen. Er verandert niets. Als het echter andersom doe, dus de o vervangen door de ö, dan krijg ik die ö wel te zien!

Toevoeging op 13/06/2012 16:17:02:

@Reshad, gewoon een ö invoegen lukt dus wel gewoon..... en de ö zoeken in de tekst lukt niet eens.... dus hoe kan ik die vervangen?
 
Reshad F

Reshad F

13/06/2012 16:17:55
Quote Anchor link
kijk hier heb je diverse voorbeeldjes staan.

http://nl.php.net/utf8_encode
 
Erwin H

Erwin H

13/06/2012 16:20:22
Quote Anchor link
Punt is, het IS al een UTF-8 string (gechecked met mb_check_encoding). Dus nog een keer encoden maakt het er niet beter op.
 
- SanThe -

- SanThe -

13/06/2012 16:22:01
Quote Anchor link
Reshad F op 13/06/2012 16:14:58:
yep je moet gewoon zoals wouter zegt al die rare tekens. ë á etc etc die er zijn in een array zetten in de utf_8 variant. wanneer je het weer weergeeeft op je scherm een decode erop gooien.


Moet volgens mij veel simpeler kunnen. Dit lijkt mij een grote omweg.
 
Erwin H

Erwin H

13/06/2012 16:25:15
Quote Anchor link
Wat ik ook probeer, het komt niet goed op het scherm. Mijn indruk is dus dat het niet goed uit de database komt. Iemand enig idee wat aan die kant nog te doen is?
 
Kris Peeters

Kris Peeters

13/06/2012 16:27:06
Quote Anchor link
Erwin H op 13/06/2012 16:12:33:
Die laatste opmerking begrijp ik niet helemaal, hoe wil je dat ik die characters zoek?


Ik bedoelde in mijn code.
Ik heb een nieuwe index.php aangemaakt.
Daarin de code gezet waarin ik naar verwees.
In die code komt het woord "euro" een paar keer voor; dit is ook de naam van de DB-tabel.
Ik heb dus, in die code elke "euro" vervangen door "umlaut";
een nieuwe tabel "umlaut" gemaakt, door die sql-dump uit te voeren in phpMyadmin
...
 
Reshad F

Reshad F

13/06/2012 16:56:40
Quote Anchor link
volgens mij begreep je me niet helemaal wat ik bedoel is.

gebruik vult in ö
de letter ö wordt opgevangen en als utf_8 variant in de database gezet.
wanneer je het weer op je scherm wilt weergeven zet je een utf_8 decode op de output en klaar. je krijgt wee ö

phphulp.wouterj.nl <-- voorbeeld
 
Erwin H

Erwin H

13/06/2012 17:03:39
Quote Anchor link
Opgelost.....

En dan waarom, want dit is een dusdanig heikel onderwerp dat het hoe en waarom wel handig is denk ik.

Oorspronkelijk was mijn database niet juist ingesteld op utf. Daarom kwam in eerste instantie niets correct. Ik heb toen wel de database correct ingesteld, alleen was de conversie niet correct gegaan van de tekst die er al instond (geen idee of dat normaal wel zou moeten). Ik heb toen 1 record handmatig aangepast met de juiste tekst, en die als test gebruikt. Andere records waren dus uberhaupt al corrupt.

Het test record stond dus wel goed op mijn scherm, maar was in feite niet correct gecodeerd. Daarom was de string die ik zag wel UTF-8, maar toch zag ik niet de juiste tekens.

Inmiddels heb ik de data (die toch uit een csv bestand kwam) opnieuw ingeladen, met de connectie naar de database correct ingesteld op UTF-8. Daarmee was de input goed en nu is de output ook goed. Ik zie het nu correct op mijn scherm. Maar overigens zie ik de tekens niet meer correct in mijn command line tool voor MySQL, maar dat klopt dus eigenlijk wel.

Dus stappen die ik heb gedaan om het correct op het scherm te krijgen:
1) maak de database aan met correcte character set (utf8) en collation (utf8_general_ci)
2) zorg bij elke connectie naar de database dat de settings goed zijn (ik gebruik de query "SET names utf8, COLLATION_CONNECTION='utf8_unicode_ci', CHARACTER SET utf8" (dus ook bij de invoer van data!)
3) stuur de utf8 header naar de browser ('Content-type: text/html; charset=utf8')
4) gebruik de meta tag (<meta http-equiv="Content-Type" content="text/html; charset=utf-8">)
5) optioneel, gebruik nog htmlentities() om de rare characters om te zetten. Zonder htmlentities werkt het overigens ook in FF.

Bedankt voor de hulp en hopelijk scheelt dit ook weer voor anderen!
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.