Charset, NLS_LANG e varie su Oracle...
Joe Skop
ho dei seri problemi a gestire il charset ed i caratteri accentati in
un db Oracle 9iR2 su architettura Linux RH9, e gestirli in output in
php.
Mi spiego.
Nella prima installazione su linux in inglese (RH9) ho realizzato il
db e l'installazione del server tenendo il charset predefinito
(dovrebbe essere ASCIII7). Risultato su sqlplus: qualsiasi carattere
accentato č stato sostituito da caratteri "strani".
Nella seconda installazione, partendo da RH in italiano, ho utilizzato
il charset UTF8, ricordando che l'UTF8 contiene i caratteri
internazionali e quindi la loro visualizzazione. Risultato: come
sopra.
Terza installazione, da RH in italiano, con db in italiano con charset
ISO8859-1 (non ho osato il 8859-15), finalmente vedo i caratteri
accentati in sqlplus.
Passiamo a php: tutto da capo, i caratteri risultano uguali ma senza
accento(e al posto di č). Ho provato ad inserire
export NLS_LANG=ITALIAN_ITALY.WE8ISO8859P1
in /etc/profile, in httpd.conf di apache, come
putenv("NLS_LANG=ITALIAN_ITALY.WE8ISO8859P1");
in php negli script, alternativamente, assieme... tutto vano.
C'č qualcuno che mi sa delucidare gentilmente sul problema? Grazie!
SAluti
JS
Joe Skop
>Salute,
>
>ho dei seri problemi a gestire il charset ed i caratteri accentati in
>un db Oracle 9iR2 su architettura Linux RH9, e gestirli in output in
>php.
>
[...]
Nessuno?
SAluti
JS
Alessandro Trebbi
> ho dei seri problemi a gestire il charset ed i caratteri accentati in
> un db Oracle 9iR2 su architettura Linux RH9, e gestirli in output in
> php.
prova a mettere un USING NCHAR_CS prima del from, oppure fai un alter
session subito dopo la connessione (non sono sicuro dell'USING
NCHAR_CS e non ho sottomano oracle9i per provare, nella 8 che sto
usando adesso non c'e' o forse sbaglio la sintassi)
comunque se devi creare una pagina html dovresti tradurre in è
quinditi serve a poco farti restituire la e accentata
Greetings,
Alessandro Trebbi
Pesaro, Italy
http://www.b3soft.com
-={Giorgio}=-
[...]
> C'č qualcuno che mi sa delucidare gentilmente sul problema? Grazie!
A volte la corretta visualizzazione del carattere accentato č un
problema proprio del presentation layer. Č una reminescenza di un
vecchio progetto fatto per un ufficio a Parigi, sul dibbě tutto ok
le variabili di ambiente tutto ok... sqlplus tutto ok, ma alla stampa
veniva fuori immondizia, il problema era nei processi che gestivano
la stampa.
La prox volta comunque non ti dannare a ricostruire "enne" istanze...
SQL>alter database set character set 'WE8ISO8859P1';
SQL>startup force
A meno di sintassi... :)
L'importante č che il CHARSET con cui hai creato la base dati sia un
sottoinsieme di quello al quale dovrei passare...
/G
PS: Fai anche prove con il tipo nchar
Joe Skop
wrote:
>> ho dei seri problemi a gestire il charset ed i caratteri accentati in
[...]
>
>prova a mettere un USING NCHAR_CS prima del from, oppure fai un alter
Provato, la sintassi deve essere errata.
Ho provato a risolvere, anzi, a vedere, il discorso anche lato server.
Se variando in /etc/profile (per essere sicuro che sia per tutti gli
utenti) come ho indicato varia anche la lingua (e quindi il set
caratteri) anche in sqlplus, allora il problema poteva e forse può
essere legato al lancio di apache o del php.
In php.ini, il file di configurazione del php, ho forzato il charset
iso-8859-1; nulla.
Allora ho variato, cercando nei files di configurazione vari, anche il
charset predefinito con cui parte l'apache, segnando anche qui
iso-8859-1. Nulla da fare, i caratteri non corrispondono ancora.
>
>comunque se devi creare una pagina html dovresti tradurre in è
>quinditi serve a poco farti restituire la e accentata
>
Beh, se ho il valore à posso sempre sostituirlo in 1000 modi in
à ma se perchè diventa perche, cosa sostituisco? :-)
Scusate il tono che poteva sembrare di impazienza nella mia richiesta
e replica di richiesta: non si tratta di impazienza ma di
"disperazione" hehe.
SAluti
JS
Joe Skop
<leva....@mclink.it> wrote:
[...]
>
>La prox volta comunque non ti dannare a ricostruire "enne" istanze...
>
>SQL>alter database set character set 'WE8ISO8859P1';
>SQL>startup force
Si, questo lo conoscevo, ma era che volevo partire (sono un testone!)
con un sistema ogni volta "pulito" per poter procedurizzare (!) tutto
da zero.
>L'importante è che il CHARSET con cui hai creato la base dati sia un
>sottoinsieme di quello al quale dovrei passare...
Beh, in teoria non ci dovevano essere problemi: la base dati è
iso-8859-1, l'output doveva essere iso-8859-1, quindi non ci
dovrebbero essere stati problemi...
>
>PS: Fai anche prove con il tipo nchar
Eh, questo è un argomento che mi devo approfondire.
Grazie per i suggerimenti!
SAluti
JS
Joe Skop
[guardare i post precedenti per le informazioni di base sul sistema e
sui problemi]
da /etc/init.d/httpd, ho cercato tutti i riferimenti esterni,
soffermandomi su questa chiamata;
# Source function library.
/etc/rc.d/init.d/functions
ho aperto poi il file, che a sua volta richiamava:
/etc/sysconfig/i18n
Il quale, infine, includeva:
LANG="it_IT.UTF-8"
e
SUPPORTED="en_US.UTF-8:en_US:en:it_IT.UTF-8:it_IT:it"
Aggiungendo e variando qui iso-8859-1, che ricordo era il charset con
cui sono stati creati i db, ed una volta riavviato il sistema,
finalmente tutto funziona a meraviglia. Per ora almeno! :-)
Notazione critica: da quel che mi risulta quindi, apache partiva
sempre con predefinito e accettabile solo charset UTF8; questo
problema non mi era mai successo di affrontarlo, ma probabilmente solo
ora con Oracle e php queste configurazioni sono venute alla luce. Sono
stupito che nessuno avesse mai affrontato il problema, che penso fosse
ricorrente: non mi pare di essere l'unico ad usare php con oracle
(anche se certamente il connubio non è dei più felici). Mah!
Grazie a tutti per la collaborazione, spero che queste mie poche righe
aiutino qualcuno in futuro!
SAluti
JS