sql >> Databáze >  >> RDS >> Mysql

trvalý způsob provádění mysqli->set_charset()?

Správně jste diagnostikovali základní problém:I když můžete změnit výchozí znakovou sadu klienta MySQL v my.cnf klientského počítače nebo .my.cnf , tyto soubory PHP nepoužívá.

Pokud se zamyslíte nad tím, jak fungují rozšíření MySQLi/MySQL v PHP, bude to dávat smysl – nemají nic společného s mysql klientský program a nebudou procházet váš souborový systém pro konfigurační soubory, protože používají libmysql přímo.

Chcete-li změnit skutečnou výchozí znakovou sadu libmysql, budete muset znovu sestavit libmysql. To nemusí být odpověď, která se vám líbí (protože používáte předkompilované binární soubory MySQL), ale je to skutečná odpověď. Výchozí hodnoty jsou nastaveny v době kompilace a poté mohou být přepsány za běhu.

Pokud to nechcete dělat a volání set_charset() vás obtěžuje, můj návrh by byl jednoduše rozšířit třídu MySQLi a použít tuto třídu místo mysqli. tj.:

class MyDB extends mysqli {
  // (You could set defaults for the params here if you want
  //  i.e. $host = 'myserver', $dbname = 'myappsdb' etc.)
  public function __construct($host = NULL, $username = NULL, $dbname = NULL, $port = NULL, $socket = NULL) {
    parent::__construct($host, $username, $dbname, $port, $socket);
    $this->set_charset("utf8");
  } 
} 

Typicky v aplikaci stejně budete mít nějakou vrstvu abstrakce databáze, takže můžete buď nechat tuto vrstvu používat MyDB místo mysqli, nebo můžete tuto vrstvu nechat být MyDB a přidejte nebo přepište libovolné metody, které chcete (udělal jsem to s jednoduchými aplikacemi bez ORM).

Je dobrým zvykem mít vždy nějaký druh abstrakce databáze, i když to začíná jako class MyDB extends mysqli {} protože pak už nikdy nebudete muset hledat/nahrazovat celou kódovou základnu, abyste mohli provádět malé změny.

RE:vaše řešení, jak vysvětlujete, toto v podstatě napevno nakóduje celý váš db server na UTF-8 bez ohledu na to, co klienti požadují. Namísto více databází, z nichž každá má svou vlastní znakovou sadu, server pracuje pouze s UTF-8 a může tiše zmanipulovat data, pokud se klienti připojí s jinou znakovou sadou. To je zásadně špatně, protože jste efektivně přesunuli jeden aspekt konfigurace vaší aplikace (databázovou znakovou sadu) z počítače aplikace/klienta na databázový server, kam ve skutečnosti nepatří.

Pokud přemýšlíte o vrstvách zásobníku aplikací,

[server] <=> [network] <=> [client libmysql] <=> [PHP binary] <=> [app]

pak pochopíte, že „správné“ místo pro konfiguraci specifickou pro aplikaci, jako je tato, je v samotné aplikaci, nikoli jinde v zásobníku. Možná se vám nebude líbit, že musíte v PHP specifikovat znakovou sadu vaší databáze, ale když se nad tím zamyslíte, tak to tam opravdu patří, protože tam také zadáváte samotnou databázi, ke které se chcete připojit – je to parametr připojení, nejde o problém s konfigurací serveru. Pevné kódování znakové sady kdekoli jinde činí vaši aplikaci nepřenosnou.



  1. Kolik znaků můžete uložit do 1 bajtu?

  2. Export dat MySQL do Excelu v PHP

  3. Co ve skutečnosti znamená max_connections?

  4. Připojení PDO bez názvu databáze?