Van oude PHP naar PDO

By using the new PHP function:

<?php
$link = mysqli_connect("127.0.0.1", "my_user", "my_password", "my_db");


if (!$link) {
    echo "Error: Unable to connect to MySQL." . PHP_EOL;
    echo "Debugging errno: " . mysqli_connect_errno() . PHP_EOL;
    echo "Debugging error: " . mysqli_connect_error() . PHP_EOL;
    exit;
}


echo "Success: A proper connection to MySQL was made! The my_db database is great." . PHP_EOL;
echo "Host information: " . mysqli_get_host_info($link) . PHP_EOL;


mysqli_close($link);
?>

Zal niet alleen de connection zijn, het hele script zal je aan moeten passen naar mysqli of pdo.
Dus hier zal het wel niet bij blijven.

@Starohosting heb je de afgelopen 10 jaar het nieuws niet gevolgd? Zo lang is de mysql-extensie al ongeveer verouderd.

En waarschuwt je host niet wanneer er wordt geupgra... oh, dit was jij zelf? En nu, kun je niet meer terug? Heb je dit niet eerst in een testomgeving getest want dit komt toch min of meer neer op een migratie? Jeweetwel, kijken of dingen nog werken in een nieuwe opstelling.

Anyhoo, misschien loont het inderdaad de moeite om eens een (grondige) schoonmaak te doen in je code of dingen gewoon opnieuw te schrijven. Zoals @Opium terecht aangeeft, dit zal van invloed zijn op je gehele website.

Het is tegenwoordig ook hip om te zorgen dat je chararacter encoderingen overal in de pas lopen. Dit is in ieder geval iets wat mist bij het maken van je connectie, en ook in de (door zichzelf gelikete? wtf lol) "verbetering" van @Puurhost - het (expliciet) selecteren van een character encoding via een set_charset() functie of methode.

Ook is security tegenwoordig een hot topic. Als je je bedient van het credo "filter input, escape output", je ook daadwerkelijk snapt wat dit betekent en hier naar handelt kom je al een heel eind.

Het zou niet misstaan om eens aandachtig (wellicht in versneld tempo) kennis te maken met (onder andere, maar niet uitsluitend) deze twee onderwerpen. Hiermee kun je jezelf een hele hoop ellende besparen.

Trouwens, als je alle query aanroepen niet hard gehardcode (mysql_connect, mysql_query etc.) maar via een wrapper had laten verlopen, was het aanpassen van deze functionaliteit mogelijk beperkt geweest tot het aanpassen van de implementatie van deze wrapper. Nu zul je heel je website door moeten.

Fair enough.

Als vervanging voor de oorspronkeljike MySQL API (alle functies die beginnen met mysql_) zijn er twee andere smaken beschikbaar: MySQLi en PDO.

Als je een snelle omzetting wilt doen in een (of) enkel(e) script(s) dan lijkt mij MySQLi (MySQL improved) het meest geschikt, omdat dit het dichtst bij de oorspronkelijke MySQL API staat.

MySQLi heeft een procedurele en een object georienteerde variant. Beide hebben voor- en nadelen. Het voordeel van de procedurele variant is bijvoorbeeld dat je (theoretisch) alle voorkomens van mysql_... haast kunt zoeken-en-vervangen door een mysqli_... variant.

Als het slechts een handjevol scripts betreft zou ik (in eerste instantie) geen gebruik maken van PDO (PHP Data Objects). Dit is namelijk een data abstractie laag, en deze is niet geschreven voor een specifieke database, maar hierbij moet je gebruik maken van een specifieke driver (PDO_MYSQL) om met je MySQL-database te communiceren.

Omdat PDO an sich niet is geschreven voor enige database, is deze op voorhand dus ook niet optimaal ingesteld voor gebruik van een specifieke database zoals MySQL. Er zit dus nog wel een zekere leercurve ten aanzien van de gebruikmaking van PDO zelf en driver-specifieke instellingen. Met name dat laatste willen mensen nogal eens vergeten, en roemen PDO vooral omdat "deze ondersteuning biedt voor een heleboel databases". Daarbij vergeten ze voor het gemak ook even dat PDO van zichzelf geen Data Access Abstraction Layer heeft, oftewel, de syntax (vorm) van je SQL-code is nog steeds database-specifiek en databases zijn daarom niet vrij inwisselbaar, in ieder geval niet zonder aanpassing van de SQL code.

Enfin, MySQLi dus, als je het in eerste instantie simpel wilt houden. Je tegelijkertijd verdiepen in PDO kan trouwens ook geen kwaad.

Punten uit de vorige post zijn nog steeds van toepassing: let op character encoderingen en security in het algemeen (filter input, escape output).

Hier een PDO gerichte config class voor je db (voorbeeld).

<?PHP


namespace src\Data\config;


use PDO;


class DBConfig
{
    protected $dbConstring = "mysql:host=localhost;dbname=databasename";
    protected $dbUser = "databaseuser";
    protected $dbPass = "databasepass";
    public $con = null;
    public $error;
    
    public function __construct()
    {
        $this->connect();
    }
    
    public function __destruct()
    {
        $this->disConnect();
    }
    
    public function connect()
    {
        //Enkel verbinden als de verbinding reeds null is zo voorkom je meerdere connections in 1 request.
        if($this->con == null)
        {
            try
            {
                $this->con = new PDO($this->dbConstring,$this->dbUser,$this->dbPass);
                $this->con->setAttribute(PDO::ERRMODE_SILENT,PDO::ERRMODE_EXCEPTION);
            }
            catch(\PDOException $e)
            {
                $this->error = $e->getMessage();
                die('Er is een fout opgetreden bij het verbinden met de database. Probeer later opnieuw.<br>An error occured while connecting to the database. Please try again later.');
            }
        }
    }
    
    public function disConnect()
    {
        $this->con = null;
    }
}

En dan hier een voorbeeld van een data class (voorbeeld in hoe je beiden kan combineren en gebruiken):

<?PHP


namespace src\Data;


use src\Data\config\DBConfig;
use src\Entities\User;
use src\Languages\GetLanguageContent;


//Data klasse, verbinden met database


class UserDAO extends DBConfig
{
    private $dbh = '';
    
    public function __construct()
    {
        parent::__construct();
        $connection = new DBConfig();
        $this->dbh = $connection->con;
    }
    
    public function __destruct()
    {
        $this->dbh = null;
    }


    public function checkUsernameExsists($username)
    {
        $statement = $this->dbh->prepare("SELECT `id` FROM `users` WHERE `username` = :username ");
        $statement->execute(array(':username' => $username));
        if($statement->fetchColumn() > 0)
        {
            return TRUE;
        }
        else
        {
            return FALSE;
        }
    }
}

@MiCa-

Wat pointers:
class DBConfig
- er zit geen charset in je DSN (vanaf PHP 5.3.6, anders moet je dit via PDO::MYSQL_ATTR_INIT_COMMAND regelen)
- gebruik een IP in plaats van localhost, dat scheelt je weer een lookup
- het lijkt mij niet nodig om de DSN, dbUser of dbPassword te onthouden?
- het attribute wat je waarschijnlijk probeert in te stellen is PDO::ATTR_ERRMODE, niet PDO::ERRMODE_EXCEPTION, mogelijk hebben deze dezelfde numerieke waarde, maar ik zou daar dan toch de goede constante voor gebruiken

class UserDAO
- wat je eigenlijk wilt controleren met de checkUsernameExsists methode (let op spelling :)) is of het precies één resultaat oplevert, dit kun je misschien beter doen met COUNT(id) en dan kijken of fetchColumn de waarde '1' oplevert (vergelijk met mysql_num_rows()); NB: als je dit als precheck wilt gebruiken voor het toevoegen van een gebruiker zal dit trouwens ook in een transactie i.c.m. FOR UPDATE gebruikt moeten worden
- kun je niet beter een database-object meegeven bij creatie of uit een registry halen of (mogelijk omstreden) van je db class een static ding maken (factory)? je maakt nu wel elke keer een nieuw database object aan als er al eerder ergens een database object was; dit lijkt mij een verspilling van resources? dit zal overigens niet resulteren in een tweede connectie naar je database omdat je DSN waarschijnlijk onveranderd is, als deze hetzelfde is als die van een eerdere connectie, dan wordt deze hergebruikt; dit kan wel mogelijk weer voor problemen zorgen bij het definitief afsluiten van een connectie, waarschijnlijk blijft deze bestaan zolang er nog één connectie "open staat", waarschijnlijk is het verstandiger om een database-object (de connectie naar een specifieke database) maar 1x te maken ten einde verwarring te voorkomen (oftewel, maak zo'n object eenmalig aan en geef deze op enigerlei wijze door bij de creatie van andere objecten die een db-connectie nodig hebben)

Citaat van FangorN

Het is tegenwoordig ook hip om te zorgen dat je chararacter encoderingen overal in de pas lopen. Dit is in ieder geval iets wat mist bij het maken van je connectie, en ook in de (door zichzelf gelikete? wtf lol) "verbetering" van @Puurhost - het (expliciet) selecteren van een character encoding via een set_charset() functie of methode.

Mijn verbetering komt gewoon vanaf de PHP website. Ik ben zelf voorstander van het in de goede richting wijzen van mensen, maar uiteindelijk het de persoon zelf laten oplossen. Ik ben het met je eens dat de code netter en veiliger kan, maar voor een script als dit lijkt me dat niet gelijk nodig. Daarbij was het voor de TS via deze functie het makkelijkst geweest om zijn script om te bouwen, waarbij via PDO natuurlijk een veel mooiere optie was geweest.

Wat enorm handig dat je berichten van jezelf kan liken... Foutje dus

Nog geen problemen ondervonden met men beiden classes, ook heb ik nog andere data classes met ook weel functies en ze doen het allemaal prima, ik voorkom in mijn script wel meerdere connecties maar het gebruik van meerdere data objecten lijkt mij geen problemen te geven, vooral bij een project waar maar 1 database word gebruikt.

ERROMODE_EXCEPTION heb ik erbij geplaatst om geen SQL error maar een standaard message weer te geven bij een mislukte database verbinding.

Hoe stel je voor om mijn data class te gaan schrijven om slechts 1 data object te gebruiken voor al mijn functies ?
Dus eig zou ik dan moeten alle nodige queries op die bepaalde pagina uitvoeren in 1 enkele statement?

Citaat van MiCa-

Nog geen problemen ondervonden met men beiden classes, ook heb ik nog andere data classes met ook weel functies en ze doen het allemaal prima, ik voorkom in mijn script wel meerdere connecties maar het gebruik van meerdere data objecten lijkt mij geen problemen te geven, vooral bij een project waar maar 1 database word gebruikt.

Dit komt omdat MySQL zelf ook redelijk intelligent is - deze voert automatisch vertalingen uit.

Voorbeeld: je hele website is UTF-8 en ook je MySQL database-tabellen zijn utf8, echter bij het maken van een connectie stel jij geen character encoding in. MySQL gaat wellicht van een andere default (bijvoorbeeld latin1) uit. Als jij dan iets wegschrijft naar een tabel ziet MySQL "Hee, mijn connectie is latin1, maar mijn tabel is utf8, laat ik deze data omzetten naar utf8". Maar als je je data al aangeleverd had als utf8 (immers, je website was al UTF-8), dan staat nu je data DUBBEL GE-ENCODEERD (EDIT: dit klopt niet helemaal, in wezen is je data nu gewoon corrupt) in je tabel. Dit merk je wellicht in eerste instantie niet, omdat als je data weer opvraagt vanuit MySQL, dan constateert MySQL "Hee, mijn connectie is latin1, maar mijn data is utf8, laat ik deze weer terugvertalen". Je gaat dan weer terug van een dubbele naar een enkele UTF-8 encodering en daarom LIJKT het goed te gaan.

EDIT: daarbij zit ook mogelijk nog de complicatie dat (de oorspronkelijke) UTF-8 data mogelijk gelezen wordt als latin1, dus mogelijk wordt je data hierdoor extra door de mangel gehaald. MySQL voert wel de "omgekeerde bewerking" uit wanneer deze weer wordt uitgelezen maar de data in je database is in wezen corrupt.

Wanneer je de manier van communiceren met je database repareert openbaren deze problemen zich pas. Dan lijkt het mij handiger dat je op voorhand overal dezelfde character encoderingen hanteert. Dit is ook efficienter, want MySQL hoeft niets te vertalen.

Citaat van MiCa-

ERROMODE_EXCEPTION heb ik erbij geplaatst om geen SQL error maar een standaard message weer te geven bij een mislukte database verbinding.

Dat snap ik, maar de syntax van setAttribute() is setAttribute(OPTIE, WAARDE). Wat jij doet is op de plek van een OPTIE (nog) een WAARDE invullen. Om te bereiken wat jij probeert te doen zul je dus zoiets moeten doen:

// stel via de optie PDO::ATTR_ERROR_MODE de waarde PDO::ERRMODE_EXCEPTION in
$this->con->setAttribute(PDO::ATTR_ERROR_MODE, PDO::ERRMODE_EXCEPTION);

Citaat van MiCa-

Hoe stel je voor om mijn data class te gaan schrijven om slechts 1 data object te gebruiken voor al mijn functies ?

Dat stel ik niet voor, ik stel voor om één instance van DBConfig te creeren die (op een manier) "globaal" (lees: overal) op te vragen is zodat je deze als parameter mee kunt geven bij creatie van je data-objecten. Objecten zijn call-by-reference, dus er wordt niets gedupliceerd. Dit lijkt mij stukken efficienter dan in elk data-object een nieuwe instance creeren van de DBConfig class (ook al wordt onder water van dezelfde fysieke database-verbinding gebruik gemaakt omdat je DSN overal hetzelfde is).

Je geeft dus in de __construct() methode van je UserDAO class een (eerder -en eenmalig- aangemaakt) object van de klasse DBConfig() mee als parameter in plaats van dat je dit object creeert in de __construct() routine zelf. Volgens mij is dit een voorbeeld van dependency injection, waarmee het mogelijk / makkelijker wordt om "losse koppelingen" te maken. Dit in tegenstelling tot hardcoded definities, zoals nu het geval is.

Nu ik er over nadenk, ik snap niet helemaal waarom UserDAO extend van DBConfig?

Bedankt man, snap ik volkomen en de manier waarop mijn applicatie geschreven is kan ik ook gewoon vanuit eender wel script meteen de DB class aanspreken zonder eerst een data class aan te spreken maar dit doe ik gewoon bewust niet ik houd het voor mezelf liever code en data gescheiden.
Heb echter bewust gekozen om mijn logic en data gescheiden te houden om sneller te kunnen werken in de toekomst, voor iedere tabel in mijn database heb ik een data class waar alle queries betreffende die tabel geschreven worden in de fucnties van de data klasse (handig voor mij om snel aanpassingen te doen aan queries voor tabel users bv, i.p.v. te gaan zoeken in 1 of meerdere bepaalde scripts.

De reden dat al mijn data classes dan de DBConfig extenden is omdat er enkel queries worden uitgevoerd in de data class en nergens anders, leek me ook beetje logisch om het op die manier te gaan schrijven dan.

Niet om mezelf meer schrijf werk te bezorgzen (wat ik uiteindelijk een beetje doe) maar gewoon om het feit dat wanneer ooit iets moet aangepast worden of er treed een bug op dan weet ik ook precies waar ik dat moet doen (a.h.v. eender welke error) in plaats van te gaan zoeken in 1 bepaald 'all-in' script. En net omdat dit vooral geschreven is voor een groot project vind ik het ook maar meer dan aangenaam als alles netjes gescheiden en logisch in elkaar zit.

En nu ga je me misschien uit lachen maar voor iedere tabel in de database heb ik dus: een logic class, data class en een entity class.
In men logic class hoort gewoon alle website code niet-database gerelateerd, data class alle queries en dergelijke en in mijn entity classes ga ik bv van een tabel een object maken, handig om na het fetchen van gegevens deze ook door te spelen naar de view in de vorm van een object.

Verder had ik gewoon even snippets gepost van voorbeelden hoe ik PDO aanpak in mijn applicatie, hoop de starter er toch mee geholpen te hebben, althans op vlak van verbinding leggen met de database, de rest doet hij beter zelf

Ik zie nu ook wel in dat ik wat extra schrijf werk kon vermijden maar op vlak van dataload en snelheid ondervind ik met deze methode geen problemen ik zou echter wel UTF8 kunnen gaan gebruiken maar mijn database is voornamelijk latin1_swedish_ci en CMS velden deze worden dan als UTF8 opgehaald vandaar ook de keuze om charset niet te bepalen, PDO zorgt ervoor dat de charset toegewezen in de database waarden van het veld automatisch worden gebruikt. Weet niet in hoevere dit vertraging kan veroorzaken maar switchen naar 1 charset doe ik dus niet om die bepaalde reden, ik houd mijn standaard (niet HTML of geen speciale karakters) velden liever in latin1.

Citaat van MiCa-

ik zou echter wel UTF8 kunnen gaan gebruiken maar mijn database is voornamelijk latin1_swedish_ci

latin1_swedish_ci is een collation, geen character encoding! Dit zijn twee verschillende dingen.

De 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).

De character encoding bepaalt de manier waarop symbolen op byte-niveau worden opgeslagen (lees: ge-encodeerd). Twee teksten op je scherm die dezelfde symbolenreeks weergeven kunnen compleet verschillende character encoderingen hebben.

Citaat van MiCa-

PDO zorgt ervoor dat de charset toegewezen in de database waarden van het veld automatisch worden gebruikt.

Het is altijd beter om expliciet in te stellen wat een character encoding zou moeten zijn, in plaats van er van uitgaan dat een default de juiste character encoding selecteert of automagisch raadt. In het geval deze aanname / verwachting niet klopt / uitkomt heb je potentieel (op termijn) grote problemen.

EDIT: Ik denk dat je het als volgt moet zien. Met het aanroepen van set_charset() maak je in wezen een afspraak met je database. Hierin:
- beloof je enerzijds informatie aan te leveren in de afgesproken character encoding (en je database gaat hier ook van uit)
- tracht je database anderzijds data terug te geven in deze character encoding (waarbij de database een oprechte poging doet om vertalingen uit te voeren indien deze nodig zouden zijn)

Als je deze afspraak zelf niet expliciet maakt, weet je simpelweg niet wat er afgesproken is met je database! Ook als de data niet op de juiste manier wordt aangeleverd of de data niet op de juiste manier in de database staat opgeslagen is de kans zeer groot dat er een spraakverwarring ontstaat wanneer er data wordt weggeschreven of opgehaald, vaak met desastreuze gevolgen.

Citaat van MiCa-

ik houd mijn standaard (niet HTML of geen speciale karakters) velden liever in latin1.

Ik denk dat je jezelf daarmee tekort doet. Tegenwoordig is UTF-8 volgens mij wel de de facto standaard. Daarnaast beperk je jezelf enorm qua "beschikbare karakters" want de letterbak van latin1 is nogal klein, die van UTF-8 is vele malen groter. Strict genomen is latin1 volgens mij ook geen standaard, UTF-8 wel.

Citaat van FangorN

EDIT: daarbij zit ook mogelijk nog de complicatie dat (de oorspronkelijke) UTF-8 data mogelijk gelezen wordt als latin1, dus mogelijk wordt je data hierdoor extra door de mangel gehaald. MySQL voert wel de "omgekeerde bewerking" uit wanneer deze weer wordt uitgelezen maar de data in je database is in wezen corrupt.

Dit heb ik nog even nagekeken en zoals ik dacht/vreesde/eigenlijk al wist ga je dit niet oplossen met een simpele utf8_decode() nadat je je _set_charset() goed hebt ingesteld ofzo.

Je kunt dus ook niet zomaar terugschakelen naar de juiste charset in de communicatie met je database omdat de DATA in je database eerst gerepareerd moet worden. Je zit nu in wezen met latin1-encoded-data-in-een-utf8-database, beter bekend als "de gebakken peren" :).

Dit kan nog meevallen als je helemaal geen speciale karakters in teksten hebt zitten, dus als de karakters in je DATA het normale ASCII-repertoire niet ontstijgen dan is mogelijk geen conversie nodig, maar als je een knettergrote database hebt dan wordt het wellicht lastig om hier garanties voor af te geven (better safe than sorry).

De omschakeling naar de juiste charset is ook het moment dat je de conversie moet uitvoeren zodat je een "clean break" hebt tussen latin1-encoded-data-in-een-utf8-database (die je dus gaat repareren) en nieuwe data die er mogelijk (na de omschakeling) weer bij gaat komen (waarvan de encodings wel kloppen). Je bent eigenlijk helemaal genaaid als kloppende en niet-kloppende data door elkaar loopt, want wat moet je dan converteren? Dan zou je per tabel moeten vaststellen wat wel en wat niet geconverteerd dient te worden.

En dan de conversie zelf. Die is nog niet zo makkelijk. Indien je geinteresseerd bent heb ik daar een artikeltje over geschreven (shameless self plug). Scroll naar de paragraaf "How to fix utf8 tables with latin1 encoded data".

LET WEL HEEL GOED OP HET VOLGENDE: Het allereerste wat er moet gebeuren is HET MAKEN VAN EEN GRONDIGE ANALYSE van wat er in jouw geval aan de hand is! Het kan heel goed zijn dat er in jouw situatie hele andere dingen aan de hand zijn. Mogelijk is je connectie en DATA in orde, maar geef je in je Content-Type header of metatag geen, of niet de goede character encoding door. Ook kun je al in de situatie verzeild zijn geraakt dat je DATA zowel kloppende als corrupte records heeft.

Hopelijk is iedereen (die dit leest) nu wat beter doordrongen van het belang van kloppende / in lijn zijnde character encoderingen want niemand zit waarschijnlijk op zo'n conversietraject te wachten waarin je je corrupte data fixt, hiervoor zul je namelijk je applicatie / website tijdelijk offline moeten halen voor publiek om te garanderen dat dit allemaal goed verloopt (en daarvoor zul je uitgebreid moeten testen of de conversie lukt, backups moeten maken et cetera).

Ik hoef waarschijnlijk niet uit te leggen wat downtime weer voor consequenties kan hebben (onbereikbare site, mogelijk omzetverlies, reputatieverlies etc.).

VOORKOMEN > GENEZEN

Bedankt man, ik denk dat je me verkeerd begrijpt mijn latin1 coalaties in velden zijn meestal gwn int, decimal, float of date velden wrbij ik soms ook gewoon true of false doorspeel a.h.v. een int value.
Varchar velden deze krijgen utf8 net alsook text velden.

Ik verwerk alle nodige data netjes in mijn zijnde data laag en of logic laag, zodat deze slechts a.h.v. parameters worden doorgespeeld naar mijn view. Mijn view side html heeft de correcte UFT-8 charset en mijn data nodig voor bepaalde pagina's word tot nu toe nog steeds altijd netjes weergegeven zoals ik het wens, ook mijn CMS velden (waar gebruikers bv profiel opmaken) ondervindt tot nu toe nog geen problemen.

Ik zal zeker eens bekijken om eventueel de database om te zetten naar utf8 maar indien dit zoals je zei een grote invloed kan hebben op data zal ik daarom eerst al men bestaande pagina's testen en kijken wat de gevolgen zijn, indien ok dan geen enkel probleem ben dan ten minste blij dat mijn database in orde is en de code betreffende de connectie ook voor toekomstig gebruik.

Citaat van MiCa-

ik denk dat je me verkeerd begrijpt mijn latin1 coalaties in velden zijn meestal gwn int, decimal, float of date velden wrbij ik soms ook gewoon true of false doorspeel a.h.v. een int value.

Euh, ik denk niet dat het wat uit maakt wat voor collations je geeft aan numerieke of date(time)velden. Numerieke velden volgen (uiteraard) een numerieke sortering, en date(time) velden (die in wezen string velden zijn geloof ik) volgen deze door hun opbouw en karaktergebruik in wezen ook. Collations gaan over het matchen en de sortering van textuele velden.

Zoals ik al eerder aangaf is het waarschijnlijk niet verstandig om uit te gaan van een default, het is gewoon verstandiger om zelf expliciet een character encoding in te stellen, veel ondubbelzinniger dan dat wordt het niet.

Je zou als volgt (zie ook het eerdergenoemde artikel) een vlugge check uit kunnen voeren met twee functies:

Aan de MySQL-kant de functie HEX(). Deze retourneert de hexadecimale waarde van (een getal of) een string.

Aan de PHP-kant de functie bin2hex(). Deze converteert binaire data naar een hexadecimale representatie. Merk hierbij op dat PHP strings ziet als simpelweg "byte sequences" (dit is dus in feite binaire data).

Het mooie van deze functie is is dat deze character encoding unaware zijn, oftewel, het maakt niet uit van welke character encoding je gebruik - de vertaling is altijd hetzelfde.

DE TEST
Staat ook min of meer beschreven in het artikel: haal met een query een tekstkolom op, en tevens de HEX() waarde van deze tekst. Zorg uiteraard dat er wat "exotische" karakters in zitten, anders maakt het allemaal niet zoveel uit (standaard ASCII karakters hebben in de meeste character encoderingen dezelfde representatie op byte-niveau).

Vervolgens druk je de tekst af, de HEX()-variant van deze tekst (eventueel opgedeeld in leesbare regels met chunk_split() ofzo) en tevens de bin2hex() variant van de tekst (ook hier kun je weer een chunk_split() gebruiken om eea leesbaar te maken).

Als de HEX()-variant AFWIJKT van de bin2hex() variant (afgezien van uppercase/lowercase dan he) dan wil dit zeggen dat MySQL voor jou een vertaalslag heeft uitgevoerd omdat er ergens een verschil in character encoderingen is geconstateerd.

Wanneer deze twee verschillen dan heb je een GROOT PROBLEEM, al is dat niet direct evident.

Persoonlijk vind ik de stellingname "in mijn applicatie werkt alles, dus ik ga niets repareren" niet heel erg goed verdedigbaar (te meer omdat je niet weet of je data wel goed is geformatteerd). Stel bijvoorbeeld dat jij data (met tekst uiteraard eh) uit een tabel ergens anders moet importeren waar alles wel goed is geconfigureerd, dan gaat dat naar alle waarschijnlijkheid niet vliegen. Je (corrupte) data is op voorhand niet meer compatibel met andere systemen.

Of uitwisseling van data via webservices? Of dus in het algemeen: wanneer je data deelt. Je kunt wel doen alsof iets UTF-8 is, maar als dat niet het geval is dan komt dat snel genoeg naar buiten (denk maar aan RSS feeds).

Just because something works, does not make it right.

Het minste wat je kunt doen is nagaan of alles klopt, dat is namelijk op dit moment nogal onzeker, en nog beter zou zijn om (eerst te testen en vervolgens) expliciet een CE in te stellen.

Je kunt nu in ieder geval niet meer zeggen dat je hier niet(s) van (af) wist :).