Oracle Globalization Support – Parte I

lunedì 14 luglio 2008 alle 14:07 | Pubblicato su Installation and Configuration, Oracle Certification | 2 commenti
Tag: , ,

Ieri sera, si, domenica sera (i casi della vita) sono riuscito a dedicare un’ora allo studio per l’esame OCP. Non avendo accesso diretto al volume I della “Oracle Database 10g: Administration Workshop II – Student Guide” sono balzato al volume 2 che in realtà contiene solo gli ultimi due capitoli e poi ci sono le esercitazioni pratiche. Gli ultimi due capitoli sono:

  • 15 – Database Security
  • 16 – Globalization Support

Siccome il capitolo “Database Security”  era troppo per una domenica sera sono passato al capitolo 16. Anche questo non è proprio il massimo della vita, ma fa parte del programma, quindi ho sfruttato l’innaturale pace che regnava a casa mia per affrontare questo impegno.

L’argomento è piuttosto noiso, soprattutto perchè per mia fortuna non mi sono dovuto mai scontrare con problematiche di questo tipo (a parte l’utilizzo del character set UTF8). Però essere preparati è sempre utile e ieri sera infatti ho capito e imparato cose nuove.

Character Set

Il primo elemento di supporto alla globalizzazione fornito da Oracle è il supporto a più character set (che spesso abbrevierò con la notazione charset). Il character set non è altro che una tabella di codifica di caratteri grafici (lettere, numeri, simboli, ideogrammi, …) in numeri. Questa tabella è necessaria perchè come sappiamo bene  tutti i computer elaborano solo numeri. Un esempio di charset, forse il più conosciuto è ASCII. In questo caso la tabella di codifica contiene solo 128 elementi, perchè usa solo 7 bit. Chiaramente una simile tabella è insufficente per gestire tutti i metodi di scrittura diffusi nel mondo. Pian piano sono proliferati i charset, quello di Winzoz (ops, windows, ad esempio CP1252 che copre i caratteri usati in italiano (a, b, c, é , …) poi ce ne sono un po’ emessi dall’ISO, ad esempio ISO-8859-p15 che copre i caratteri della lingua italiana e include anche il simbolo dell’euro. Questi charset sono a 8 bit (un byte) e quindi contengono ben 256 elementi. Fin che un database deve essere utilizzato sono in uno stato, quindi con un set ben delimitato di caratteri, non ci sono grandi problemi. Se invece il database è in qualche modo mondiale e deve gestire caratteri che derivano da più nazioni cominciano i problemi. Qui arriva il charset univervale, UTF-8. Si tratta di un charset a lunghezza variabile, superinsieme di ASCII. UTF-8 codifica a un byte tutti i caratteri gia presenti nella tabella ASCII,  poi codifica a 1 o 2 byte il resto dei caratteri utilizzati in europa, poi vi sono una serie di simboli e caratteri asiatici rappresentati a 3 byte, infine vi sono dei caratteri, definiti supplementari codificati con 4 byte. Vi è anche una versione UTF-16, che codifica i caratteri con 2 o 4 byte. Lo standard UTF, viene aggiornato continuamente (credo per aggiungere nuovi caratteri supportati) e attualmente siamo alla versione 4.0, supportata da Oracle e chiamata AL40UTF8. La versione precedente era la 3.2 e in oracle viene chiamata AL32UTF8.

Il grosso problema nella gestione dei charset sta nella comunicazione tra client e server. Anche i terminali che vengono usati come client a loro volta utilizzano dei charset e se questi charset sono diversi da quello usato lato server occorre fare delle conversioni. Oracle a livello  “Oracle Net” cerca di gestire in modo trasparente queste conversioni. In particolare ieri ho capito (forse) meglio cosa significa l’impostazione del charset lato client: essa viene usata da Oracle per fare la conversione, ma l’impostazine deve indicare il charset utilizzato dal terminale, altrimenti si rischia di dare ad Oracle una falsa indicazione inducendolo a fare o non fare una conversione come andrebbe fatto e facendo finire nel database dati invalidi.  Questo meccanismo non mi è ancora completamente chiaro, ma da quel che vedo in giro non sono solo. Il punto è che bisogna proprio fare attenzione alla charset usato dal programma client. Ad esempio se uso sqlplus da una finestra dos in windows e mi collego a un database con charset UTF-8 posso facilmente confondermi se uso ad esempio lettere accentate. Infatti accade che, almeno sulla macchina che uso io,  la tabella dei codici è la 850. Ora, che diavolo di tabella sia non lo so, però so che non è compatibile con UTF-8 e che vengono fuori un saccoi di casini.  Sto ancora cercando di capire bene, ma pare che la tabella 65001 sia compatibile con UTF-8.

Il charset di un database oracle viene definito al momento della creazione e salvo rari casi non è possibile fare una conversione.

NLS_LANG

Oltre le tabelle dei caratteri vi sono altri aspetti che fanno parte del supporto alla globalizzazione: la lingua dei messaggi, la lingua nelle date (i nomi dei giorni della settimana, dei mesi), il formato della data, i separatori per i decimali, il simbolo della valuta, i metodi di ordinamento. In oracle vi è un parametro che permette di impostare queste cose, è NLS_LANG il cui valore ha un formato più meno così:

<language>_<territory>.<charset>

Il linguaggio determina ovviamente la lingua dei vari messaggi, ma anche il linguaggio con cui vengono visualizzati i nomi dei giorni della settimana e i mesi nelle date. L’altro elemento influenzato dal linguaggio è il metodo di ordinamento (vi sono le regole diverse). Questi due elementi possono anche essere settati in modo indipendente trami i parametri NLS_DATE_LANGUAGE e NLS_SORT; il valore di questi due parametri se non settato esplicitamente viene derivato dall’elemento <language> del parametro NLS_LANG.

Dall’elemento <territory> derivano invece i valori dei seguenti parametri:

  • NLS_CURRENCY: il simbolo della valuta, Euro, dollaro, sterlina, yen ecc.
  • NLS_DUAL_CURRENCY
  • NLS_ISO_CURRENCY
  • NLS_DATE_FORMAT
  • NLS_NUMERIC_CHARACTERS, i separatori per i decimali e per le migliaia
  • NLS_TIMESTAMP_FORMAT
  • NLS_TIMESTAMP_TZ_FORMAT

I tre elementi che compongono il valore del parametro NLS_LANG sono opzionali e possono essere specificati singolarmente, ad esempio:

NLS_LANG = _JAPAN

NLS_LANG = .US7ASCII

Infine vi sono dei parametri NLS il cui valore non viene inferito da NLS_LANG:

  • NLS_CALENDAR (mai usato)
  • NLS_COMP (può essere BINARY, il default, ANSI o LINGUISTIC
  • NLS_LENGTH_SEMANTICS, assume importanza fondamentale per i tipi char e varchar in caso di charset multibyte, credo di averne già parlato

Arrivato a questo punto mi rendo conto di aver scritto più quanto avevo preventivato e quindi sarò costretto a esaurire l’argomento in più post (spero bastino due).

Concludo questo post ricordando solo il settaggio dei parametri “NLS” avviene a quattro livelli:

  1. DATABASE
  2. AMBIENTE CLIENT
  3. SESSIONE CLIENT
  4. FUNZIONE SQL

Ma mano che si scende di livello si “sovrascrive” i settaggi del livello superiore.

2 commenti »

RSS feed for comments on this post. TrackBack URI

  1. […] superino la mezz’ora mi porta talvolta a fare dei post frettolosi, come è accaduto per il precedente. D’altra parte se non l’avessi fatto così in fretta probabilmente avrei finito per non […]

  2. […] dedicato un paio di post alla gestione della “globalizzazione” in Oracle, i post sono questo  e questo. Ad oggi ogni tanto ancora incontro problemi nella gestione sul database di caratteri […]


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: