UTF-8 hela vägen igenom

Datalagring :

• Ange utf8mb4 teckenuppsättning på alla tabeller och textkolumner i din databas. Detta gör att MySQL fysiskt lagrar och hämtar värden kodade inbyggt i UTF-8. Observera att MySQL implicit kommer att använda utf8mb4 kodning om en utf8mb4_* sortering anges (utan någon explicit teckenuppsättning).

• I äldre versioner av MySQL (<5.5.3) kommer du tyvärr att bli tvungen att helt enkelt använda utf8 , som bara stöder en delmängd av Unicode-tecken. Jag önskar att jag skojade.

Dataåtkomst :

• I din applikationskod (t.ex. PHP), oavsett vilken DB-åtkomstmetod du använder, måste du ställa in anslutningsteckenuppsättningen till utf8mb4 . På så sätt gör MySQL ingen konvertering från sin ursprungliga UTF-8 när den lämnar data till din applikation och vice versa.

• Vissa drivrutiner tillhandahåller sin egen mekanism för att konfigurera anslutningsteckenuppsättningen, som både uppdaterar sitt eget interna tillstånd och informerar MySQL om kodningen som ska användas på anslutningen - detta är vanligtvis det föredragna tillvägagångssättet. I PHP:

  • Om du använder PDO abstraktionslager med PHP ≥ 5.3.6, du kan ange teckenuppsättning i DSN :

     $dbh = new PDO('mysql:charset=utf8mb4');
    

  • Om du använder mysqli , du kan ringa set_charset() :

      $mysqli->set_charset('utf8mb4');       // object oriented style
      mysqli_set_charset($link, 'utf8mb4');  // procedural style
    

  • Om du har fastnat med vanlig mysql men råkar köra PHP ≥ 5.2.3 kan du ringa code>mysql_set_charset .

• Om drivrutinen inte tillhandahåller sin egen mekanism för att ställa in anslutningsteckenuppsättningen kan du behöva skicka en fråga för att berätta för MySQL hur din applikation förväntar sig att data om anslutningen ska kodas:SET NAME 'utf8mb4' .

• Samma övervägande angående utf8mb4 /utf8 gäller enligt ovan.

Utdata :

• Om din applikation överför text till andra system måste de också informeras om teckenkodningen. Med webbapplikationer måste webbläsaren informeras om kodningen i vilken data skickas (via HTTP-svarsrubriker eller HTML-metadata ).

• I PHP kan du använda default_charset php.ini-alternativet eller manuellt utfärda Content-Type MIME header själv, vilket bara är mer jobb men har samma effekt.

• När du kodar utdata med json_encode() , lägg till JSON_UNESCAPED_UNICODE som en andra parameter.

Indata :

• Tyvärr bör du verifiera varje mottagen sträng som giltig UTF-8 innan du försöker lagra den eller använda den var som helst. PHPs mb_check_encoding() gör susen, men du måste använda den religiöst. Det finns verkligen ingen väg runt detta, eftersom skadliga klienter kan skicka data med vilken kodning de vill, och jag har inte hittat något knep för att få PHP att göra detta åt dig på ett tillförlitligt sätt.

• Från min läsning av den nuvarande HTML-specifikationen , är följande underpunkter inte längre nödvändiga eller ens giltiga för modern HTML. Jag förstår att webbläsare kommer att arbeta med och skicka data i den teckenuppsättning som specificeras för dokumentet. Men om du riktar in dig på äldre versioner av HTML (XHTML, HTML4, etc.), kan dessa punkter fortfarande vara användbara:

  • Endast för HTML före HTML5 :du vill att all data som skickas till dig av webbläsare ska vara i UTF-8. Tyvärr, om du går efter det enda sättet att på ett tillförlitligt sätt göra detta är att lägga till accept-charset attribut till alla dina
    taggar: .
  • Endast för HTML före HTML5 :notera att W3C HTML-specifikationen säger att klienter "bör" som standard skicka formulär tillbaka till servern i vilken teckenuppsättning servern serverade, men detta är tydligen bara en rekommendation, därav behovet av att vara explicit på varje enskild tag.