Det tillvägagångssätt som beskrivs där är inte rekommenderat — det finns en funktion som heter mysqli::set_charset (och motsvarigheter för andra databasmoduler) som föredras.
En exempelanslutning som använder detta:
<?php
$mysql_server = '';
$mysql_user = '';
$mysql_password = '';
$mysql_database = '';
$mysqli = new mysqli($mysql_server, $mysql_user, $mysql_password, $mysql_database);
$mysqli->set_charset('utf8');
Precis som trådskaparen säger redan har gjorts så bör man se till att databaserna lagrar data i UTF-8, genom att sätta `collation` för databastabellerna till `utf8_swedish_ci` (eller `utf8_unicode_ci` om det inte är specifikt svensk data som ska lagras). Detta gör att man undviker ett översättningslager vid läsning/skrivning, och om man till databasen skickar UTF-8-tecken utan representation i den teckenkodning som lagringen sker i så kommer man få oväntade resultat, även om man sagt till PHP/MySQL att använda UTF-8 vid anslutning.
Miniutläggning om UTF-8 och MySQL
Låt säga att man använder ett `varchar(12)`-fält för lagring i databasen. På äldre versioner av MySQL (<4.1), så om man lagrade i UTF-8 och fick in ett multibytetecken så tog det helt enkelt multipla "chars" i anspråk (då "chars" rent tekniskt tolkades som "bytes" i dessa versioner). "Räksmörgås" skulle alltså inte fått plats i ett `varchar(12)`-fält i UTF-8.
Numera, med icke-antika versioner, så är "chars" verkligen "chars", så "Räksmörgås" får plats i `varchar(12)`. Dock, så om man lagrar i UTF-8, så reserverar varje "char" multipla "bytes" (3 för att vara exakt — notera att UTF-8 specificerar tecken på upp till 4 byte, men dessa stöds inte av MySQL med UTF-8-lagring — om man specifikt inte väljer en `utf8mb4`-lagring som tillkom i 5.5.3 som då reserverar just 4 byte). Detta blir relevant då en rad maximalt kan vara 65535 byte lång. Om man använder latin1 så kan man alltså använda `varchar(65535)` i en tabell, men om man kör UTF-8 så kan man max köra `varchar(21844)` (där alla kolumner delar på maxutrymmet). Man kan använda `text`- och `blob`-kolumner utöver detta, men de dras å sin sida med begränsningar i cachning och rekommenderas oftast att inte användas om det inte verkligen behövs.
Dessutom, om man försöker specificera en kolumn som är för stor för att få plats ensam i en tabell så konverterar MySQL tyst och automatiskt denna till `mediumtext`/`text` — men om den är för stor för tabellen pga att andra rader redan tagit upp utrymme, men rent teoretiskt skulle kunna existera ensam i en tabell, så får man felet "Row size too large". Var dessa konverteringsgränser ligger beror då alltså även på vald teckenkodning.
Viss röra i UTF-8-land, helt enkelt.
