Newsgroup: it.comp.java
Titolo: ricezione oggetto da socket

Salve,
io ricevo un oggetto su un server socket, che ho sottoforma di byte[]
a questo punto, utilizzo una classe esterna x convertirlo in un
oggetto, e devo  passargli la codifica (il charset_encoding).
Il problema è che io non so quale charsert_encoing utilizzare, nel
senso che, l'array di byte ricevuto, può avere codifica Latin-1 ma
anche UTF-8.
In questo modo, se chiamo la classe esterna con il charset_encoding
sbagliato, ho problemi con i caratteri accentati.
La mia domanda: dato un byte[] è possibile ricavarne il
charset_encoding o è praticamente impossibile???
grazie

il 19/11/2008 10.16, Scrive 
web...@gmail.com
 43829952:

Un byte e' un byte, probabilmente quasi ogni valore possibile (da 0x00 a 
0xff) e' compreso nelle due codifiche.
Sapendo da dove proviene e come e' stato costruito l'array magari 
qualcosa si potrebbe fare, ma sarebbe comunque un indovinare.
-- 
Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñejoAlcoolInside
Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'


Cerca su google "ask smart questions".
Il tuo post manca di dettagli, non spiega il problema e da per scontata 
la soluzione. E' difficile aiutarti in questo modo.
I dettagli che mancano sono:
  - in che formato è salvato questo oggetto
  - cosa rappresenta questo oggetto
  - non fornisce dettagli sulla "classe esterna" e sul metodo che non
    riesci ad utilizzare
  - manca uno SSCCE
Il charset encoding di un dato è un meta-dato. Se il server non fornisce 
questo meta dato è molto difficile (se non impossibile) per il client 
ricostruire questo meta dato. A volte si usa incorporare questo 
meta-dato nel dato stesso. Un esempio di questo approccio è la prima 
riga di alcuni file XML:
	<?xml version="1.0" encoding="utf-16"?>
-- 
Andrea Francia
FtpServerStub ease your FTP Client unit-testing:
http://andreafrancia.it/ftpserverstub/

 o è praticamente impossibile???
non è la strada giusta. il server che ha fatto la conversione in un verso 
deve passarti il charset che ha usato per poter fare la conversione 
inversa. oppure usate convenzionalmente una codifica comune.

web...@gmail.com
 ha scritto:

Allora questo dice wikipedia
UTF-8
http://it.wikipedia.org/wiki/UTF-8
I caratteri il cui valore unicode è inferiore a U+0080 vengono
rappresentati con un singolo byte contenente il loro valore; essi
corrispondono esattamente ai 128 caratteri ASCII.
In tutti gli altri casi sono necessari fino a 4 byte, ognuno di questi
con il bit più significativo impostato a 1, in modo da distinguerli
dalla rappresentazione dei caratteri dell'alfabeto ASCII a 7 bit, in
particolare quelli il cui codice unicode è inferiore a U+0020,
tradizionalmente utilizzati come caratteri di controllo.
*****Le accentate occupano piu' di un carattere
ed in particolare (lo trovi sul link)
Intervallo Unicode
esadecimale 	UTF-16 	UTF-8
binario 	Note
0x000000 - 0x00007F 	00000000 0xxxxxxx 	0xxxxxxx 	Caratteri equivalenti 
al codice ASCII; I byte iniziano con 0
0x000080 - 0x0007FF 	00000xxx xxxxxxxx 	110xxxxx 10xxxxxx 	il primo byte 
inizia per 110 o 1110, il successivo(i) con 10
0x000800 - 0x00FFFF 	xxxxxxxx xxxxxxxx 	1110xxxx 10xxxxxx 10xxxxxx
0x010000 - 0x10FFFF 	110110xx xxxxxxxx
110111xx xxxxxxxx 	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 	UTF-16 richiede 
l'uso di coppie surrogate; viene sottratto il valore esadecimale 
0x10000, in modo che la sequenza dei bit non coincida con quella usata 
da UTF-8
   -------------------------
Latin-1
http://it.wikipedia.org/wiki/ISO_8859
Lo standard ISO 8859, più precisamente ISO/IEC 8859, è uno standard
comune ISO ed IEC per la codifica di caratteri ad 8 bit per il
trattamento informatico di testi. La norma è divisa in parti numerate
pubblicate separatamente (come ISO/IEC 8859-1, ISO/IEC 8859-2, etc),
ognuna delle quali può essere riferita informalmente come standard a sé
stante. Ci sono attualmente 15 parti definite, escludendo la ISO/IEC
8859-12, abbandonata.
   -----------------------
Se tu sapessi la lunghezza "aspettata" l'UTF e' piu lungo del Latin-1
con una unica eccezione ma in quel caso Latin-1 e UTF non dovrebbero 
fare differenza
Se non sai la lunghezza la cosa non e' deterministica (non ho 
approfondito piu' di tanto). In questo caso leggi tutto il messaggio e 
se trovi una coppia di byte
"C0" o "C1" seguita da un "80"-"83"  (hex) dovrebbe essere un UTF
s. e.& o.
--
ac

 qualcosa si potrebbe fare, ma sarebbe comunque un indovinare.
Beh. si potrebbe tentare un "certo" indovinamento o un "indovinamento" 
certo. Sempre fermo restando che un "byte e' un byte".
Sto divagando, ormai fuso, dalla scrittura di una routine "stocastica" ;-{)
--
ac

Vi introduco meglio nello scenario, in modo da chiarire meglio il
problema
Ho un server in ricezione di oggetti in formato ASN1, tali oggetti
vengono prelevati dal TCP e inoltrati a un decodificatore.
Il decodificatore richiede, oltre il byte[] (l'oggetto da
decodificare) anche il charset_encoding.
Il mio server si pone in ricezione di oggetti ASN1 codificati in
ISO-8859-1 (LATIN-1), perciò charset_encoding="ISO-8859-1"
Volevo gestire il caso in cui mi arrivassero oggetti codificati in
UTF-8
in tal caso, invierei il byte[] al decoder accompagnao da
charset_encoding="UTF8"
il problema deriva dal fatto che chi mi invia gli oggetti  NON mi
specifica l'encoding.
Quindi avevo ipotizzato la soluzione di "ricavarmi" l'encoding in
qualche modo (ma ho solamente il byte[]) e di conseguenza invocare il
decoder con l'opportuno valore per charset_encoding.
Altrimenti avevo prospettato la soluzione di mantenere due server
socket, uno adibito alla ricezione di ASN1 codificati in Latin-1 e uno
x quelli in UTF8, demandando allo "speditore" la scelta della porta in
base alla codifica che ha utilizzato, ma tale seconda scelta mi sembra
più "brutta", per diversi motivi che non sto ad elencarvi.

 Ho un server in ricezione di oggetti in formato ASN1,
Ha quanto sembra ANS.1 supporta già le stringhe UTF-8 con il tipo 
UTF8String e supporta vari altri charset: 
http://www.obj-sys.com/asn1tutorial/node128.html



Si, ok. Ma non cambia il mio problema. Non so a priori la codifica
dell'oggetto che mi arriva, e il decoder necessita di sapere se deve
creare l'oggetto corrispondente in UTF8 o ISO-8859-1.


 creare l'oggetto corrispondente in UTF8 o ISO-8859-1.
Mi sembra strano che il server debba sapere a priori la codifica del 
client? A mio avviso, in genere, è il client che deve adeguarsi alla 
codifica del server.
Non conosco ASN.1 ma mi sembra di capire che la codifica è importante 
solo per gli oggetti di tipo GeneralString. Non ti basta specificare nel 
documento di interfaccia di quel server che tutte le stringhe 
GeneralString saranno interpretate con ISO-8859-1? Se un client vuole 
mandarti una stringa in UTF-8 te la manderà dentro una UTF8String.



certamente, mi sembrava una cosa ottima offrire un supporto anche x i
messaggi UTF8 (lo standard di fatto rimane ISO-8859-1)
Purtroppo l'aderenza agli standard rimane un'utopia


 Purtroppo l'aderenza agli standard rimane un'utopia
Ma il supporto a UTF8 non c'e' già in ASN.1? Con le UTF8String?



In realtà il particolare messaggio ASN.1 che mi arriva è in formato
BER, e per utilizzarlo ho bisogno di un decoder esterno che necessita
il passaggio del charset_enoding.
Se mi arriva in fomrato UTF-8 e lo passo al decoder specificando
ISO-8859-1 ho problemi nella lettura dei caratteri accentati.


 problema
OK. Forse al mio solito non sono stato chiaro.
Il succo della mia risposta era questo (nell'altro ramo)
In questo caso leggi tutto il messaggio e se trovi una coppia di byte
"C0" o "C1" seguita da un "80"-"83"  (hex) dovrebbe (e') essere un UTF
0x000000 - 0x00007F     utf 8-->    0xxxxxxx  <-- questo per il latin-1 
dovrebbe essere uguale
0x000080 - 0x0007FF     utf-8-->    110xxxxx 10xxxxxx
i.e. se hai il byte array completo e' necessario fare uno scan 
sull'array per verificare la condizione suddetta. Se e' riscontrata si 
passa come UTF altrimenti come ISO-8859
'c0'-'c1' hanno la loro corrispondenza su latin-1 ma '80'-'83' no. Non 
mi sembra che questa configurazione sia fra il set dei caratteri 
nazionali e/o speciali (compresa fra 'A0' e 'FF'). La tabella e' bella 
stesa nel link a latin-1 che avevo citato alla voce "tabella".
Tutto cio' prima di avviare al decoder.
Ora pero' tu scrivi questo:
"In realtà il particolare messaggio ASN.1 che mi arriva è in formato
BER, e per utilizzarlo ho bisogno di un decoder esterno che necessita
il passaggio del charset_enoding.
Se mi arriva in fomrato UTF-8 e lo passo al decoder specificando
ISO-8859-1 ho problemi nella lettura dei caratteri accentati."
La cosa e' quindi diversa. E mi sembra il classico gatto che si morde la 
coda.
Per interpretare il BER hai bisogno del decoder, il decoder ha bisogno 
di sapere se il BER e'  utf o iso. Bene passaglielo 2 volte
1) Latin-1
2) c'e' in giro un '80'-'83' nel ritorno?
3) se si e' un UTF8 (o comunque ci sono caratteri 0x000080 - 0x0007FF)
4) altrimenti va bene cosi'
Questo se ho interpretato bene le specifiche di codifica.
--
ac

 2) c'e' in giro un '80'-'83' nel ritorno?
sorry
2) c'e' in giro  una coppia in cui il primo byte e' compreso fra 'C0' e 
'DF' ed il secondo fra '80' e 'BF'
e quindi la cosa e' imprecisa anche se , sempre che  il riferimento sia 
Italia, i nostri riferimenti nazionali cadono nell'intervallo 'E0' - 
'FF' (i minuscoli). I maiuscoli stanno nell'intervallo 'C0' - 'DF' ma 
nell'intervallo '80'-'BF' non c'e' nulla che ci riguardi.
Ma se tre indizi fanno una prova la presenza di piu' coppie di questo 
tipo portano alla quasi assoluta certezza.
--
ac


A livello di costo computazionale credo costi di meno, per ogni
stringa dell'oggetto generato, controllare se sia in formato latin-1.
Se false, convertirla in fomato latin-1.
Anche perchè gli oggetti hanno diversi attributi, di cui circa la metà
stringhe, e quindi il controllo verrebbe ridotto alle sole stringhe
(credo sia un risparmio rispetto il controllo del byte[])
In effetti, se passo al decoder la codifica sbagliata, viene generato
un oggetto che avrà problemi di codifica dei soli caratteri accentati,
cmq convertibili da un formato ad un altro

web...@gmail.com
 ha scritto:

Uhmmmmm...... si mi sembra piu' semplice e veloce (Occam ed il suo 
rasoio hanno colpito ancora).
Effettivamente se passi una latin-1 come utf dovrebbe dirti "sbagliato" 
se ci sono le accentate).
Se ho capito il processo che vuoi fare.
--
ac


esattamente.