UTF-8 докрай

Съхранение на данни :

• Посочете utf8mb4 набор от знаци във всички таблици и текстови колони във вашата база данни. Това прави MySQL физически да съхранява и извлича стойности, кодирани в UTF-8. Имайте предвид, че MySQL имплицитно ще използва utf8mb4 кодиране, ако utf8mb4_* е посочено съпоставяне (без изричен набор от знаци).

• В по-старите версии на MySQL (<5.5.3) за съжаление ще бъдете принудени да използвате просто utf8 , който поддържа само подмножество от символи на Unicode. Иска ми се да се шегувах.

Достъп до данни :

• В кода на вашето приложение (напр. PHP), в какъвто и метод за достъп до DB използвате, ще трябва да зададете набора от знаци за връзка на utf8mb4 . По този начин MySQL не извършва преобразуване от своя UTF-8, когато предава данни на вашето приложение и обратно.

• Някои драйвери предоставят свой собствен механизъм за конфигуриране на набора от символи за връзка, който едновременно актуализира собственото си вътрешно състояние и информира MySQL за кодирането, което ще се използва при връзката - това обикновено е предпочитаният подход. В PHP:

  • Ако използвате PDO абстракционен слой с PHP ≥ 5.3.6, можете да посочите charset в DSN :

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

  • Ако използвате mysqli , можете да извикате set_charset() :

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

  • Ако сте останали с обикновен mysql но случайно работите с PHP ≥ 5.2.3, можете да извикате mysql_set_charset .

• Ако драйверът не предоставя свой собствен механизъм за настройка на набора от символи за връзка, може да се наложи да издадете заявка, за да кажете на MySQL как вашето приложение очаква данните за връзката да бъдат кодирани:ИМЕНА НА НАСТРОЙКИ 'utf8mb4' .

• Същото съображение относно utf8mb4 /utf8 се прилага както по-горе.

Изход :

• Ако вашето приложение предава текст към други системи, те също ще трябва да бъдат информирани за кодирането на знаците. При уеб приложенията браузърът трябва да бъде информиран за кодирането, в което се изпращат данните (чрез HTTP заглавки на отговор или HTML метаданни ).

• В PHP можете да използвате default_charset php.ini или ръчно издайте Content-Type MIME хедър себе си, което е просто повече работа, но има същия ефект.

• Когато кодирате изхода с помощта на json_encode() , добавете JSON_UNESCAPED_UNICODE като втори параметър.

Въвеждане :

• За съжаление, трябва да проверите дали всеки получен низ е валиден UTF-8, преди да се опитате да го съхраните или да го използвате някъде. mb_check_encoding() на PHP прави номера, но трябва да го използвате религиозно. Наистина няма начин да заобиколите това, тъй като злонамерените клиенти могат да изпращат данни в каквото си кодиране искат и не намерих трик, който да накарам PHP да направи това вместо вас надеждно.

• От моя прочит на текущата HTML спецификация , следните под-куршуми вече не са необходими или дори валидни за съвременния HTML. Моето разбиране е, че браузърите ще работят и ще подават данни в набора от знаци, посочен за документа. Въпреки това, ако сте насочени към по-стари версии на HTML (XHTML, HTML4 и т.н.), тези точки все още може да са полезни:

  • Само за HTML преди HTML5 :искате всички данни, изпращани до вас от браузърите, да са в UTF-8. За съжаление, ако използвате единствения начин да направите това надеждно, е да добавите accept-charset атрибут на всичките ви
    тагове: .
  • Само за HTML преди HTML5 :имайте предвид, че спецификацията на W3C HTML казва, че клиентите "трябва" по подразбиране да изпращат формуляри обратно към сървъра в какъвто и набор от знаци, който сървърът обслужва, но това очевидно е само препоръка, следователно необходимостта да бъде изрично за всеки един маркер.