Vita da tecnici

Entries from Gennaio 2008

Java encoding addedum no. 5: il peccato capitale String.getBytes()

Gennaio 31, 2008 · 1 Commento

Si conclude con questo articolo la panoramica sull’encoding in Java e sulle ragioni delle eccezioni che spesso si incontrano nel fare il parsing dei file xml.

Questo ultimo articolo è dedicato alla fonte più ricorrente di tali errori. la chiamata del metodo getBytes della classe String senza parametri (parametri nella getBytes?? eh sì, esite anche la getBytes che accetta un argomento). L’esperienza mi insegna che dove c’è una getBytes() e del parsing xml prima o poi compaiono errodi di encoding. Perchè?

Perchè effettua l’encoding usando il charset della piattaforma su cui gira java e quindi varia da sistema operativo a sistema operativo. Chi riceve la sequenza di caratteri tradotta in byte non sa che encoding è stato usato, per cui si può solo indovinare. Se proprio serve serializzare dei caratteri in uno stream di byte la prima cosa da fare è concordare l’encoding in modo che chi riceve e chi trasmette possa scambiarsi i dati. Consiglio di utilizzare UTF-8 che consente di inviare caratteri di vario tipo (anche quelli non europei). Neanche a farlo apposta in questi giorni mi sono scontrato con del mio codice (sigh) che per fare il parsing di un file xml richiede come parametro un InputStream; peccato che la funzione chiamante passasse una stringa. Per passare da una stringa ad un inputstream si fa getBytes e poi si passa il risultato ad un ByteArrayInputStream. E zac!! ci si espone ad errori di encoding perchè i parser leggono da InputStream l’encoding da utilizzare che non c’entra nulla con quello dello stream che è ottenuto da una getBytes. La soluzione è di aggiungere un metodo che accetta come parametro un reader e usare un StringReader.

Categorie: Pensieri sparsi · java encoding · xml caratteri accentati · xml encoding

Non ci posso credere: al primo posto su google!

Gennaio 22, 2008 · Nessun Commento

Mentre scrivevo il post precedente ho cercato su google “utf byte exception” per ottenere la dicitura dell’eccezione java.

Il primo risultato è stato il mio blog!!

ho deciso di immortalare l’evento con un bello screenshot (attenzione la risoluzione è 1680X1050).

google_uft_exception

Categorie: Pensieri sparsi

Java encoding addedum no. 4 xml all’interno dell’xml

Gennaio 22, 2008 · Nessun Commento

Questo è il penultimo dei post che riguarda l’xml encoding e tratta un argomento che si può presentare quando si ha a che fare con delle applicazioni che si basano su scambio di messaggi xml. Capita a volte che le applicazioni message oriented abbiano una struttura a due livelli:

  1. il primo livello di xml trasmette i campi generali (es il mittente, il nome del servizio, il contenuto informativo)
  2. il secondo livello di xml trasmette il contenuto vero proprio ed è rappresentato da un campo del primo livello

Esempio

<message>

<sender>Giovanni</sender>

<service>invio_fattura</service>

<content><![CDATA[

<?xml version="1.0" encoding="ISO-8859-1"?>
<fattura> 	<numero>2</numero>  	<data>20080131</data> ... ...  </fattura>

]]></content>

</message>

Tale strutturazione si usa quando si vuole creare uno scheletro di comunicazione da usare per diversi servizi che vengono chiesti a dei fornitori in tempi diversi. Gli sviluppi successivi possono riutilizzare “l’infrastruttura” di comunicazione e concentrarsi solo sul contenuto senza dover configurare endpoint diversi e “menate varie”.

Una soluzione di questo tipo pone un problema di encoding particolare; infatti per evitare il famoso Invalid byte 2 of 3-byte UTF-8 sequenceed annessi e connessi è necessario capire cosa succede se il messaggio viene trasportato via rete tramite protocollo http.

Il contenuto del tag content è a tutti gli effetti una stringa che, nel caso di cdata non viene toccata (si può inserire il contenuto facendo l’escaping dei caratteri, ma il messaggio diventa molto meno leggibile ad occhio nudo). La domanda da porsi è: se all’interno di CDATA ci sono dei caratteri accentati con che encoding vengono trasmessi?

La risposta è: a priori non è dato saperlo. Eh? Perchè?

Analizziamo il “viaggio” del messaggio; se si usa un web service client (tipo quelli generati da AXIS) abbiamo a disposizione un metodo di un oggetto che, presi i parametri di input, crea un xml e tramite un http client, lo invia “come stringa” (è una semplificazione, ma serve per non perdersi nei dettagli) all’http server. l’http client specifica un encoding nell’header http; il server legge l’encoding e ricostruisce una stringa che rappresenta il messaggio xml. A questo punto sul server il web service può essere implementato tramite un metodo che accetta gli stessi parametri del client (stile AXIS) o viene fornito un albero JDOM, DOM4J o XOM da cui prelevare i dati (stile Spring Web Services). In entrambi i casi il contenuto del campo content è accedibile come stringa. Stringa = sequenza di caratteri per cui non esiste problema di encoding, la conversione byte-caratteri è stata presa in carico dall’http server o dalla libreria che implementa i meccanismi di web service.

Che problemi ci sono allora?

Che il contenuto di content deve essere dato in pasto alla nostra libreria XML preferita che crea un albero o una serie di eventi; ma nell’header del messaggio contenuto in content è specificato un encoding che non ha più alcun legame con l’encoding reale. Tale informazione sull’encoding va ignorata.

Come si fa?

La soluzione l’ho citata nel post precedente: si usa un reader al posto di un input stream.

Ricetta facile e veloce: se dobbiamo dare in pasto ad una libreria xml del contenuto che proviene da una stringa utilizziamo un reader e non un inputstream

Categorie: change encoding · java encoding · xml caratteri accentati · xml encoding