hallo, ik wil een record wegschrijven met een zinnetje weer
bv. "het is vandaag 10° en mooi weer"
indien ik dit bijwerkt of wegschrijft in de MYSQL database krijg ik het volgende te zien
"het is vandaag 10"
Alles achter de 10 wordt niet weggeschreven
wat kan daar de oorzaak van zijn?
aan allen
bedankt voor het meedenken.
probleem treed niet op als ik via phpmyadmin upload
dus ben ik verder gaan zoeken
als ik de volgende regel op remark zet doet die het wel goed verwerken
//$db->set_charset("utf8");
ik ben nog verder aan het testen geweest.
en als ik de strings eerst
$weer = utf8_encode($weer);
en daarna de query uitvoert upload die de gehele string incl ° (graden )
hierbij kan de remark weer weggehaald worden bij $db->set_charset("utf8");
topic is dus opgelost.
Fijn dat het directe probleem is opgelost... maar ik voel mij toch genoodzaakt te benadrukken dat dit waarschijnlijk geen optimale oplossing is. Ik zal proberen uit te leggen waarom.
De reden dat het bovenstaande werkt is in zekere zin een (toevallige) samenloop van omstandigheden. Op het moment dat je dingen programmeert is het verstandig om zo min mogelijk aan het toeval over te laten. Daartoe is het meestal handig om zoveel mogelijk dingen expliciet in te stellen. Zo ook de character encoding van je database-connectie.
De bovenstaande aanpak mag dan werken, maar de character encoding van de betreffende tekst flippert al dan niet onder water een aantal keren heen en weer tussen UTF-8/utf8 en een andere encodering, en de enige reden dat dit goed gaat is omdat de default character encoding die MySQL gebruikt toevallig overeenkomt / compatibel is met die andere encodering.
Mocht een van de twee veranderen (bijvoorbeeld door een verhuizing naar een andere server, een upgrade van MySQL of een verandering in de aanlevering van de informatie, of misschien simpelweg omdat je dit alles op een andere omgeving ontwikkelt dan waar deze code daadwerkelijk wordt gebruikt) dan breekt deze aanpak opnieuw. Het is beter om op zoveel mogelijk plekken expliciet voor te schrijven in welke vorm informatie aangeleverd moet worden.
Mijn vraag is dan ook: hoe komt deze informatie normaliter in de database terecht? Is iemand echt de inhoud van een tekstbestand aan het aanpassen, of gebruik je een formulier, of iets anders (hierboven heb je het over PHPMyAdmin)?
Op het moment dat dat duidelijk is (hoe informatie wordt aangeleverd) kunnen we (verder) kijken hoe je dit op een fatsoenlijke(re) manier in de database krijgt, zonder ook maar één keer een vertaalslag tussen encoderingen te maken. Dit laatste biedt geen enkele ruimte voor de "ruis" die je mogelijk bij dit soort vertalingen ondervindt, zoals je beschreef in je oorspronkelijke vraagstuk.
Voorkomen lijkt mij in dit geval beter dan (tijdelijk) genezen.
sorry voor de late reactie
Het wordt aangestuurd op een lokale pc met een programma in C++ builder van borland.
Het tekenset wat daar wordt gebruikt is dan windows 1252
Dit wordt met een post verzonden naar het script op de server.
de coalitie staat van de mysql database ingesteld op utf8_general_ci.
Okay, dus je bronmateriaal is Windows-1252 geëncodeerd. Dit zou equivalent (of in ieder geval in grote lijnen compatibel) moeten zijn met latin1.
Voor het begrip is het volgende heel belangrijk: je moet set_charset() zien als het contract tussen jouw code en de database. Dit contract heeft twee belangrijke speerpunten:
- jij moet er zorg voor dragen dat de informatie die jij aan MySQL aanlevert van de voorgeschreven encodering is
- MySQL doet haar best om de informatie (uit de database) terug te geven in de voorgeschreven encodering
En het allerbelangrijkste hierbij is de realisatie dat MySQL hiertoe, indien nodig, en naar beste vermogen, vertalingen tussen encoderingen uitvoert. De encodering waarmee je werkt en de encodering waarin data staat opgeslagen mogen dus best van elkaar verschillen.
Voor het wegschrijven van Windows-1252 informatie houdt dit dus (theoretisch :)) in dat je voor het wegschrijf-script latin1 gebruikt. Het lijkt mij nog steeds belangrijk om dit expliciet in te stellen middels set_charset(). MySQL ziet vervolgens "Hee, ik krijg hier latin1-data binnen, maar ik moet dit wegschrijven naar een utf8-tabel/kolom." en maakt dan automatisch -en naar beste vermogen- een vertaalslag naar utf8 conform het contract.
NB: als dit niet werkt en er toch karakters verdwijnen dan zul je dieper moeten duiken in de precieze verschillen tussen de encoderingen of een soort van workaround moeten verzinnen.
En als je vervolgens deze informatie weer wilt weergeven, bijvoorbeeld op een HTML-pagina met UTF-8 encodering, dan stel je dus set_charset() in op utf8 (en daarnaast zou het HTML-document een meta-tag of PHP header moeten bevatten waaruit blijkt welke encodering deze gebruikt). Als je dan data uit je database trekt dan ziet MySQL "Hee, ik krijg hier het verzoek om informatie te retourneren in utf8, en de informatie in kwestie is al utf8, dus ik hoef verder niets te vertalen." en retourneert de informatie (rechtstreeks) in utf8 conform het contract.
Een collation is de manier waarop karakters worden vergeleken (wanneer zijn symbolen gelijk) en gesorteerd (welke symbolenreeks komt alfabetisch voor een andere symbolenreeks bij het sorteren op een tabelkolom) en heeft niet echt invloed op encodering of de bijbehorende problematiek. Tegelijkertijd hoef je niet te verwachten dat de collatie voorspelbaar werkt indien de data in je database verkeerd geëncodeerd is.
