[Gfoss] Trovare errori encoding

Salve,
come noto, l'importazione di uno shapefile, o anche altri formati, in un
db è generalmente un'operazione a rischio, perché i caratteri accentati
possono non essere interpretati correttamente. Talvolta ci si accorge
della cosa solo molto tempo dopo, quando magari si sono creati dati
derivati ecc.
La domanda: sapete che si sia una query già pronta, o un altro sistema,
per accorgersi se in una tabella c'è un qualsiasi carattere "strano",
convertito non correttamente?
Saluti, e grazie.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

Salve,
In occasione del referendum ho voluto fare delle prove tecniche con R e lo
scraping table da web dei dati sull'affluenza di tutti i comuni italiani,
ottenendo una tabella con due campi: comune e affluenza, questa tabella poi
l'ho messa in join con lo shapefile comuni scaricato dal sito istat:
problema: l'istat scrive i nomi dei comuni con caratteri speciali (à, è,
ecc..), il Ministero dell'Interno con caratteri tutti maiuscole; quindi una
query sarebbe l'ideale!!!

saluti

Il giorno 16 aprile 2016 07:17, Paolo Cavallini <cavallini@faunalia.it> ha
scritto:

Salve,
come noto, l'importazione di uno shapefile, o anche altri formati, in un
db è generalmente un'operazione a rischio, perché i caratteri accentati
possono non essere interpretati correttamente. Talvolta ci si accorge
della cosa solo molto tempo dopo, quando magari si sono creati dati
derivati ecc.
La domanda: sapete che si sia una query già pronta, o un altro sistema,
per accorgersi se in una tabella c'è un qualsiasi carattere "strano",
convertito non correttamente?
Saluti, e grazie.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

--
*Salvatore Fiandaca*
*mobile*.:+39 327.493.8955
*m*: *pigrecoinfinito@gmail.com <pigrecoinfinito@gmail.com>*
*blog:** https://pigrecoinfinito.wordpress.com/
<https://pigrecoinfinito.wordpress.com/&gt;\*

43°51'0.54"N 10°34'27.62"E - EPSG:4326

“Se la conoscenza deve essere aperta a tutti,
perchè mai limitarne l’accesso?”
R. Stallman

On Sat, Apr 16, 2016 at 07:17:42AM +0200, Paolo Cavallini wrote:

La domanda: sapete che si sia una query già pronta, o un altro sistema,
per accorgersi se in una tabella c'è un qualsiasi carattere "strano",
convertito non correttamente?

Non e' facile definire "strano".
Forse potresti fare una lista di caratteri "non strani"
e controllare che tutti i caratteri nei valori di un campo
siano presenti in quel set.

--strk;

On Tue, 19 Apr 2016 16:42:54 +0200
Sandro Santilli <strk@keybit.net> wrote:

On Sat, Apr 16, 2016 at 07:17:42AM +0200, Paolo Cavallini wrote:

> La domanda: sapete che si sia una query già pronta, o un altro sistema,
> per accorgersi se in una tabella c'è un qualsiasi carattere "strano",
> convertito non correttamente?

Non e' facile definire "strano".
Forse potresti fare una lista di caratteri "non strani"
e controllare che tutti i caratteri nei valori di un campo
siano presenti in quel set.

di solito sono quelli oltre il 127 ascii.
fare una analisi preventiva dei dati comporta comunque sapere il set di caratteri usato.
ad esempio nelle specifiche tecniche di RT i dati devono essere consegnati in cp1252.
dopodiché attraverso una riga di python

return v.encode('cp1252')

non ho nessun problema ad infilare l'informazione in uno shapefile.

questo per dire che forse è meglio prevenire il fatto.
ciao

--
Marco Guiducci <marco.guiducci@regione.toscana.it>
Firenze, via di Novoli 26
055 4383194

On Wed, Apr 20, 2016 at 09:45:19AM +0200, Marco Guiducci wrote:

On Tue, 19 Apr 2016 16:42:54 +0200
Sandro Santilli <strk@keybit.net> wrote:

> On Sat, Apr 16, 2016 at 07:17:42AM +0200, Paolo Cavallini wrote:
>
> > La domanda: sapete che si sia una query già pronta, o un altro sistema,
> > per accorgersi se in una tabella c'è un qualsiasi carattere "strano",
> > convertito non correttamente?
>
> Non e' facile definire "strano".
> Forse potresti fare una lista di caratteri "non strani"
> e controllare che tutti i caratteri nei valori di un campo
> siano presenti in quel set.

di solito sono quelli oltre il 127 ascii.

Beh, le lettere accentate italiane non sono in quella fascia
(per esempio).

fare una analisi preventiva dei dati comporta comunque sapere il set di caratteri usato.

Infatti la stessa definizione di carattere non puo' prescindere
dall'encoding. Per determinare se un carattere e' strano devi prima
determinare cosa sia un carattere, potrebbe essere definito come un
solo byte oppure come multibyte...

ad esempio nelle specifiche tecniche di RT i dati devono essere consegnati in cp1252.

Perche' non UTF8 ?

--strk;

  () Free GIS & Flash consultant/developer
  /\ http://strk.keybit.net/services.html

ad esempio nelle specifiche tecniche di RT i dati devono essere consegnati in cp1252.

Perche' non UTF8 ?

perche' la C toscana non e' codificabile :wink:

Il 20 aprile 2016 14:00, Sandro Santilli <strk@keybit.net> ha scritto:

On Wed, Apr 20, 2016 at 09:45:19AM +0200, Marco Guiducci wrote:

On Tue, 19 Apr 2016 16:42:54 +0200
Sandro Santilli <strk@keybit.net> wrote:

> On Sat, Apr 16, 2016 at 07:17:42AM +0200, Paolo Cavallini wrote:
>
> > La domanda: sapete che si sia una query già pronta, o un altro sistema,
> > per accorgersi se in una tabella c'è un qualsiasi carattere "strano",
> > convertito non correttamente?
>
> Non e' facile definire "strano".
> Forse potresti fare una lista di caratteri "non strani"
> e controllare che tutti i caratteri nei valori di un campo
> siano presenti in quel set.

di solito sono quelli oltre il 127 ascii.

Beh, le lettere accentate italiane non sono in quella fascia
(per esempio).

Infatti.
Quindi nei files RT non ci vanno le lettere accentate.
Le accentate si fanno con l'apostrofo.

A.