SQL Server 2005/2008 UTF-8 řazení / znaková sada

UTF-8 nelze nainstalovat jako znakovou sadu, protože to není znaková sada, je to kódování.

Pokud chcete uložit text Unicode, použijte datový typ nvarchar.

Pokud chcete ukládat text kódovaný pomocí UTF-8, uložte jej jako binární data (varbinary).

Počínaje SQL Server 2019 (nyní ve verzi beta/„Community Tech Preview“) existuje nativní podpora pro UTF-8 prostřednictvím nové řady řazení UTF-8. HOWEVER, mající schopnost používat UTF-8 anoneznamenat, že byste měli. Použití UTF-8 má určité nevýhody, jako například:

1. Pouze prvních 128 kódových bodů je 1 bajt (tj. Standardní 7bitový ASCII))
2. Dalších téměř 2 000 kódových bodů jsou 2 bajty, a proto není oproti UTF-16/NVARCHAR žádná úspora místa
3. Zbývajících 63k kódových bodů v BMP (tj. Rozsah U + 0800 - U + FFFF) je všech 3 bajtů, tedy 1 bytevětšínež stejný znak v UTF-16/NVARCHAR.
4. Jen to řekni: Doplňkové znaky jsou 4 bajty v obou kódováních, takže zde není žádný prostorový rozdíl
5. I když můžete ušetřit místo pomocí UTF-8, existuje velká šance, že za to uděláte zásah.

K čemu to skutečně patří: UTF-8 je návrh formátu úložiště, který umožňuje 8bitové systémy (které byly obvykle navrženy kolem ASCII a ASCII) Rozšířené - kódové stránky) pro použití Unicode, aniž by došlo k narušení nebo vyžadování jakékoli úpravy existujících souborů, aby se věci udržely v chodu. UTF-8 je vynikající pro souborové systémy a sítě, ale uložená datauvnitřSQL Server také není. Skutečnost, že data, která se právě stanou, jsouvětšinou(nebo zcela) v rámci standardu ASCII = rozsah vyžaduje méně místa než stejná data, když je uloženo jako UTF-16/NVARCHAR je vedlejší účinek. Jistě, je to vedlejší účinek, který se může ukázat jako užitečný, ale toto rozhodnutí musí učinit někdo, kdo chápe dataadůsledky/nevýhody tohoto rozhodnutí. Toto jenefunkce pro obecné použití.

Také hlavní případ použití pro UTF-8 (v SQL Serveru) je pro kód aplikace, který již používá UTF-8, možná již s jiným RDBMS, který jej podporuje, a neexistuje žádná touha ani schopnost aktualizovat schéma aplikace/schéma DB použít NVARCHAR datové typy (pro tabulky, proměnné, parametry atd.), nebo předponovat řetězcové literály velkým písmenem „N“. Cíl je stejný jako důvod existující UTF-8: umožnit kódu aplikace používat Unicode beze změny celkové struktury nebo vykreslování existujících dat neplatná. Pokud to popisuje vaši situaci, použijte UTF-8, ale uvědomte si, že s ní stále existuje několik chyb/problémů.

Pokud nemáte výslovnou potřebu pracovat s Unicode bez použití NVARCHAR nebo velkých řetězcových literálů s předponou "N", pak jediným dalším scénářem, kde je výhoda UTF-8, je, pokud máte Avětšinoustandard ASCII data, která musí umožňovat znaky Unicode, a používáte NVARCHAR(MAX) (což znamená, že vyhrála komprese dat) 't work') a tabulka se aktualizuje často (takže Clustered Columnstore Index pravděpodobně nepomůže).

Pro více informací viz můj příspěvek:

Nativní podpora UTF-8 v SQL Server 2019: Spasitel nebo Falešný prorok?

V mém případě jsem musel zobrazit arabské postavy a moje vývojová databáze byla v roce 2014, tady to fungovalo dobře. Zde jsem v dotazu viděl arabské znaky a moje řazení bylo SQL_Latin1_General_CP1256_CI_AS

Ale moje produkce byla v SQL serveru 2008 a nakonec to nepodporovalo UTF-8 charset. Tady jsem viděl všechny ??????????? protože UTF-8 není v SQL 2008 podporován.

Všechno, co jsem udělal, bylo změnit všechny varchar na nvarchar a viděl jsem arabskou char správně. Také změním své řazení databáze z roku 2008 na SQL_Latin1_General_CP1256_CI_AS