it-swarm-eu.dev

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

Nemohu najít možnost přímo nastavit UTF-8 rellated Collations/Charsets v SQL Server 2005/2008, stejně jako je možné nastavit v jiných strojích SQL, ale v SQL Server 2005/2008 existují pouze latinské a SQL řazení.

Existuje nějaká možnost vynutit/nainstalovat tyto kolace/charsety v SQL Server engine (pro oba ver.) 2005/2008 na OS Win2008

16
mKorbel

Ne, není. SQL Server nepodporuje UTF-8.

Pokud chcete data Unicode, musíte definovat sloupce jako nvarchar/nchar. Poznámka: interně to SQL Server ukládá jako UCS-2.

Všimněte si, že to bylo požadováno od MS on Connect a existuje starší článek KB . A nějaké informace také na tomto blog

13
gbn

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).

2
Guffa

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?

1
Solomon Rutzky

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

0
Halim