sql >> Databáze >  >> RDS >> Oracle

rozdíl mezi NLS_NCHAR_CHARACTERSET a NLS_CHARACTERSET pro Oracle

Obecně jsou všechny vaše body správné. NLS_NCHAR_CHARACTERSET definuje znakovou sadu pro NVARCHAR2 , et. al. sloupce, zatímco NLS_CHARACTERSET se používá pro VARCHAR2 .

Proč je možné, že vidíte čínské znaky s US7ASCII ?

Důvodem je, že znaková sada vaší databáze a znaková sada klienta (tj. viz NLS_LANG hodnota) jsou obě US7ASCII . Vaše databáze používá US7ASCII a "myslí" také klient odesílá data pomocí US7ASCII . Neprovádí tedy žádnou konverzi řetězců, data se přenášejí bit po bitu z klienta na server a naopak.

Díky tomu můžete použít znaky, které US7ASCII ve skutečnosti nepodporuje . Uvědomte si, že v případě, že váš klient používá jinou znakovou sadu (např. když používáte ODP.NET Managed Driver v aplikaci Windows), data budou nesmysl! Také pokud byste uvažovali o migraci znakové sady databáze, máte stejný problém.

Další poznámka:Nemyslím si, že byste získali stejné chování s jinými znakovými sadami, např. pokud by vaše databáze i váš klient používali WE8ISO8859P1 například. Uvědomte si také, že máte ve skutečnosti nesprávnou konfiguraci. Vaše databáze používá znakovou sadu US7ASCII , váš NLS_LANG hodnota je také US7ASCII (s největší pravděpodobností to není vůbec nastaveno a Oracle jej nastaví jako výchozí US7ASCII ), ale skutečná znaková sada SQL*Plus, resp. váš cmd.exe terminál je s největší pravděpodobností CP950 nebo CP936.

Pokud chcete vše nastavit správně, můžete buď nastavit proměnnou prostředí NLS_LANG=.ZHT16MSWIN950 (Zdá se, že CP936 není společností Oracle podporován) nebo před spuštěním sqlplus.exe změňte kódovou stránku pomocí příkazu chcp 437 . S tímto správným nastavením neuvidíte žádné čínské znaky, jak byste pravděpodobně očekávali.




  1. Jak dosáhnout vysoké dostupnosti PostgreSQL pomocí pgBouncer

  2. C# volání oracle uložené funkce

  3. Zápis IDEF1X

  4. Profilování dat:Zjišťování podrobností o datech