Newsgroup: it.comp.software.database
Titolo: Charset, NLS_LANG e varie su Oracle...

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


[...]
Nessuno?
SAluti
JS

 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 &egrave;
quinditi serve a poco farti restituire la e accentata
Greetings,
Alessandro Trebbi
Pesaro, Italy
http://www.b3soft.com

 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


Beh, se ho il valore à posso sempre sostituirlo in 1000 modi in
&agrave; 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

PS: Fai anche prove con il tipo nchar
Eh, questo è un argomento che mi devo approfondire.
Grazie per i suggerimenti!
SAluti
JS

Direi che ho risolto il problema. Procedura:
[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