probleem met htmlentities in php 5.6

‘probeer dit eens op te slaan in een kolom met charset utf8’

Dit gaat onherroepelijk een SQL fout opleveren.

De moraal: Mysql's utf8 is niet gelijkwaardig aan de 'officiële' utf8, in MySQL gebruik je hiervoor de charset mb4utf8

Afgezien van het feit dat de string van Ger Latin1 is met dank aan deze site ;-) begrijp ik niet waarom het tot fouten zou leiden voor MySQL. Ja, utf8mb4 biedt volledige Unicode dekking voor MySQL, maar in mijn beleving is het waarschijnlijker dat PHP 5 zelf problemen geeft met UTF8. Ik ging daarnet even browser en kwam dit stukje tegen: http://stackoverflow.com/questions/571694/what-factors-make-php-unicode-incompatible
En ik moet zeggen dat als ik dat lees, ik het liefst mijn appje in vollediger taal zou willen herschrijven, ware het niet dat het wel veel werk is in 1x. (zit nu in migratie van MySQL naar PostgreSQL).
Verder is alom bekend dat PHP 6 en volledige Unicode support ook nog niet gelukt is, hopelijk brengt PHP 7 verbetering.

Wat een hoop reacties en tekst. Een en ander roept wat vragen op.

Thomas:
@1 ... Als je de PHP header weglaat zou de browser tijdens het lezen van het document kunnen besluiten om het document opnieuw te gaan lezen naar aanleiding van de metatag omdat dit afwijkt van de default "leesmode", maar dit maakt verder voor snelheid eigenlijk niets meer uit tegenwoordig.

Grappig. Maar dat zou betekenen als je een pagina zonder php op maakt dat de browser ook opnieuw zou kunnen starten ...
header() moet dan voor de eerste html output staan neem ik aan.

@2 ... Maakt het nog wat uit welke van de 2 regels (php_value default_charset "utf-8" en
AddDefaultCharset utf-8 ) in de .htaccess zouden moeten staan? Of zijn ze aanvullend aan elkaar?

@3 ... het instellen van de charset voor de databaseverbinding. Heeft die betrekking op ingaand verkeer (iets naar de database toe schrijven), uitgaand verkeer, of op beide?

Thomas:
Als je oorspronkelijke een latin1 tabel had met latin1 encoded data dan zou deze zonder problemen omgezet moeten kunnen worden met een ALTER TABLE statement. Ook de data in de tabel wordt dan geconverteerd naar de nieuwe character encodering.

Als ik via phpMyAdmin de charset heb gewijzigd, dan heeft op de achtergrond ALTER TABLE gedraaid volgens mij. Net even geprobeerd en ik zie dat de volgende sql wordt uitgevoerd:

ALTER TABLE `m_boeken` CHANGE `auteur` `auteur` TINYTEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ;

In phpMyAdmin ziet de tekst er correct uit. Mag ik daarmee concluderen dat de tekst als utf-8 in de tabel zit? Zo ja, dan zou alleen de ontbrekende codering van de databaseverbinding het probleem zijn ...

Verder zie ik iets over mb_strlen ipv strlen. In de documentatie zie ik niets dat er op wijst dat strlen niet meer correct is in php5. Is dit misschien iets voor toekomstige ontwikkelingen?

Dat was het even voor dit moment,

Nogmaals bedankt voor alle input en hopelijk krijg ik nog even een eenduidige reactie op bovenstaande.

Jop

[size=xsmall]Toevoeging op 09/11/2015 21:03:18:[/size]

mysqli_set_charset($dblink, 'utf8');

Klopt het dat het utf8 is en geen utf-8?

@3 ... het instellen van de charset voor de databaseverbinding. Heeft die betrekking op ingaand verkeer (iets naar de database toe schrijven), uitgaand verkeer, of op beide?

Beide

dan zou alleen de ontbrekende codering van de databaseverbinding het probleem zijn ...

Dat probeer ik je duidelijk te maken ;)

In de documentatie zie ik niets dat er op wijst dat strlen niet meer correct is in php5.

De functie strlen werkt op byte niveau, het telt het aantal bytes. Bij Latin1 (single byte character set) staat dat gelijk aan het aantal karakters.
UTF8 slaat karakters op in 1 t/m 4 of 6 bytes. Dus krijg je met strlen() op een UTF8 tekst als 'überhaupt' een andere lengte dan met mb_strlen(), die laatste telt wel het aantal karakters van een multi-byte string.
Hou je daar geen rekening mee dan kan het de werking van je programma verpesten.
Het hangt van de programma af, of het PHP-deel informatie bewerkt of alleen doorgeeft tussen browser <=> database.

Ik haak af in dit topic. Al de informatie die hier gespuid wordt kan beter gebundeld worden in een tutorial of artikel, maar het heeft volgens mij weinig meer van doen met de oorspronkelijke vraag van de topicstarter.

Mocht je nog informatie willen PM me maar.

Toch is dit wel een van de betere, meer inhoudelijke topics met goede argumenten. Dus het lezen waard. Kost wel wat tijd, maar dan heb je ook wat.

Beste allen,

Allemaal bedankt voor jullie input. Extra informatie is helemaal niet verkeerd. Maar het kan ook verwarrend en diffuus worden. Als gebruiker van dit forum voel ik me soms van het kluit in het riet gestuurd worden omdat ik te veel informatie krijg of niet relevante informatie. Wellicht goed, bezien vanuit mijn positie als vragensteller, om een aantal zaken in de gaten te houden bij het beantwoorden, denk ik:
- wat is precies de vraag?
- als je twijfelt over de vraag, stel dan gerichte wedervragen om de vraagstelling te verduidelijken.
- beter geen antwoord dan het antwoord op een andere vraag
- probeer met je antwoord rekening te houden met het niveau van de vraagsteller
- probeer een antwoord te formuleren dat niet meer vragen op roept dan nodig
- verwijzingen naar andere documentatie (in dit geval niet echt van toepassing) is als achtergrond informatie vaak leuk, maar als antwoord niet echt duidelijk. Vaak heb ik al verschillende zaken bekeken voor ik hier een vraag stel. Mocht je verwijzen naar andere documentatie, geef dan duidelijk aan waar het antwoord volgens jou in die documentatie te vinden is.
- probeer in je antwoord niet te veel zijpaden op te gaan, en als je een zijpad op gaat geef dan duidelijk aan wat en waarom dat zijpad wordt bewandeld. Het verhaal van die mb-str* functies is op zich interssant, maar blijkt vooral van toepassing als je in strings met special characters wilt gaan plakken en knippen. Dat was hier helemaal niet het geval. Leuk om te weten, maar werkte voor mij verwarrend.
- probeer als het even kan een concreet voorbeeld te geven.
- geef aan waarom je iets op een bepaalde manier zou moeten doen, daar leer ik van, dan kan ik het hopelijk de volgende keer zelf ;-)
- probeer een antwoord van een ander niet over te doen, tenzij er pertinente onzin in staat volgens jou.

Zo geef ik op een gegeven moment aan dat ik het allemaal ga bestuderen en als het nodig is dat ik dan extra vragen zal stellen om eea meer duidelijk te krijgen. Voor ik eventueel aanvullende vragen had gesteld, wordt er al een berg aan aanvullende informatie uitgestort. Dat werkte voor mij alleen maar verwarrend.

Hopelijk maakt deze reactie de kwaliteit van dit forum nog beter. Nogmaals, iedereen bedankt voor hun input en bijdragen!

Jop

PS het probleem was opgelost met het instellen van de charset voor de db-verbinding.

Beste jo, bedankt voor je terugkoppeling. De info die over je wordt uitgestort was wel wat veel inderdaad, een leermomentje voor ons.

Voor wie nooit meer dit soort problemen wil is er een tut op:
http://www.phphulp.nl/php/tutorial/php-algemeen/unicode-enzo/831

Goed idee An tje! Ik heb je een mail gestuurd met wat tips.