UnicodeDecodeError: 'utf-8' #191
Comments
MaelREBOUX
added
Python
|
C'est ici que ça semble se produire : https://github.com/3liz/QgisCadastrePlugin/blob/master/cadastre_import.py#L597-L602 Est-ce qu'il y aurait un caractère non UTF-8 dans un des fichiers MAJIC ? |
|
Bonjour, J'ai exactement la même erreur qu'évoquée ci-dessus en tentant d'importer les fichiers MAJIC 2019 avec Qgis 3.4. Ce qui est étonnant, c'est que l'importation avec le 2.19 fonctionne bien. Voici le message d'erreur : Ma configuration : Version de Python : 3.7.0 |
|
Bonjour, J'ai la même chose. UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf7 in position 1199: invalid start byte
Traceback (most recent call last):
File "C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_dialogs.py", line 727, in processImport
qi.importMajic()
File "C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_import.py", line 444, in importMajic
item['method']()
File "C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\cadastre\cadastre_import.py", line 581, in importMajicIntoDatabase
for a in self.chunk(fin, self.maxInsertRows):
File "C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf7 in position 1199: invalid start byte
Version de Python : 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)]
Version de QGIS : 3.4.11-Madeira Madeira, 9a8a6d4687
Chemin Python :
• C:/PROGRA~1/QGIS3~1.4/apps/qgis-ltr/./python
• C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python
• C:/Users/s.maison/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins
• C:/PROGRA~1/QGIS3~1.4/apps/qgis-ltr/./python/plugins
• C:\Program Files\QGIS 3.4\bin\python37.zip
• C:\PROGRA~1\QGIS3~1.4\apps\Python37\DLLs
• C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib
• C:\Program Files\QGIS 3.4\bin
• C:\PROGRA~1\QGIS3~1.4\apps\Python37
• C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\site-packages
• C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\site-packages\win32
• C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\site-packages\win32\lib
• C:\PROGRA~1\QGIS3~1.4\apps\Python37\lib\site-packages\Pythonwin
• C:/Users/xxxx/AppData/Roaming/QGIS/QGIS3\profiles\default/python
C:\Users\xxxx\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins\cadastre\formsA mon avis c'est dans le MAJIC qui bug mais pas encore trouvé |
|
Le truc c'est que cela passe en QGIS 2.18.21 et plug 1.5.6 |
|
Salut pour info j'ai eu le problème sur l'une des communes de Loire-Atlantique. Le problème ne vient pas du plugin CADASTRE mais d'un fichier MAJIC: en effet j'ai trouvé des caractères en hexadécimale au beau milieu d'un de mes fichiers Majic. Repère dans le log, le fichier sur lequel le plugins s'est arrêté, celui-ci contient à coup sûr une caractère qui n'est pas en UTF-8. Il faut trouvé ce caractère en ouvrant ton fichier dans un éditeur de texte et l'effacer. Le caractère est évident à voir il est sous forme hexadécimal (dans mon cas il s'affichait de manière assez visible sous Notepad : un espèce de "xBD" sur fond noir. le bloc-note de Windows interprète quant à lui ce caractère sous la forme d' un "Û". tente une recherche avec ce fameux caractère avec un peu de chance ce sera le même que dans mon cas sinon t'es bon pour te taper quelques milliers de lignes à décortiquer. Pour ma part j'ai enlevé ce caractère et ça roule. Bon courage |
|
Le souci vient en effet des fichiers MAJIC, mais le plugin doit pouvoir les gérer. Est-ce que toutes les personnes concernées par ce bug peuvent tester de modifier la ligne 579 du fichier et remplacer with open(fpath) as fin:par with open(fpath, 'rb') as fin:Puis redémarrer QGIS, et retenter l'import. |
|
J'ai testé ta modification, je n'ai pas d'erreur lors de la création de la base Postgres. Je te fournis un extrait très minimaliste du fichier MAJIC (il reste 5 lignes sur les 19000 d'origine) avec les fameux caractères qui posent problème pour que tu te rendes compte également des décalages que cela génère (J'ai trafiqué quelques chiffres sans incidence sur la forme du fichier pour m'éviter un coup de marteau de la CNIL)--> je pense que le soucis vient des décalages et ça me parait difficile de résoudre ça via le plugin: à mon avis il faut mettre les mains dans les fichiers MAJIC et les corriger à la main. Ce n'est pas très sorcier et je pense c'est un cas quasi exceptionnel: sur 200 communes téléchargées je n'ai eu qu'un seul fichier erroné. Je pense même que c'est mieux de laisser le plugin en l'état car l'erreur python permet de savoir quel fichier pose problème. |
|
Désolé pas encore testé je test ce soir |
|
oupss la log tu l'as trouve où |
|
J'ai fais le test et même résultat que mathieuTOUBLANC |
|
@sebGIS --> Le log est là (voir la capture ci-dessous) la procédure d'import s'arrêtera sur le fichier ayant un caractère non-reconnu, soit le dernier qui s'affiche dans le journal (log). Dans mon cas, comme tu peux le voir sur la capture, le plugin s'est arrêté sur le chargement du fichier "ART.DC21.W19440.PDLL.A2019.N000933.txt" qui est un des fichiers MAJIC de la commune de Pornichet.
|
|
ok merci |
|
Tente une recherche du caractère "Û" avec le bloc-note de Windows, avec un peu de chance ça matchera (repère l'endroit dans le fichier). Après c'est plus lisible de modifier avec un autre éditeur de texte comme Notepad ou PSPad. T'as combien de lignes dans ton fichier? |
|
768891 lignes |
|
Presque un million de lignes ce n'est pas envisageable de le faire manuellement, moi j'avais seulement 19000 lignes. Tente la recherche avec le caractère que je t'ai indiqué sous le bloc-note, as tu essayé au moins? (difficile de faire une recherche sous Notepad car tu ne peux pas taper le caractère au clavier, il s'affichait en hexadécimal dans mon cas) |
|
bah oui mais avec le bloc note cela plante trop de ligne pas moyen d'utiliser l'outil recherche |
|
Il doit bien y avoir une solution: par exemple je penserais aussi à découper mon fichier en 10 pour avoir 10 fichiers de 80000 lignes. Là ça doit passer facilement ou alors ton ordinateur manque terriblement de puissance. Chez moi la recherche aboutie instantanément (Processeur I7 et 8Go de mémoire vive). Dans la recherche copie/colle ça: Û Ou alors donne moi ton mail qu'on échange en privé pour éviter de pourrir la discussion ici. Tu pourras me fournir ton fichier MAJIC pour que je regarde si tu me fais confiance: évidemment dans ma structure nous avons l'autorisation de la CNIL pour accéder au fichiers MAJIC. |
|
non c'est fait mais c'est Û |
MaelREBOUX
added
the
données
ça confirme que le pb vient des données. Pb à remonter à votre centre des impôts pour correction car c'est pas normal ça ! J'ai tendance à croire que ça va pas être possible de gérer ça dans le code d'import. N'est-ce pas @mdouchin ? |
|
Oui j'ai trouvé aussi mon caractère de merde. |
|
De mon côté, j'ai aussi testé le "Û"sur le fichier propriétaire (celui qui pose problème) dans le bloc note mais ça ne renvoi aucun caractère. Il faut que je poursuive les recherches... |
|
Oui nous avons échangé en privé avec @sebGIS pour son cas, il a fini par trouvé lui-même son fameux caractère hexadécimal qui pose problème et malheureusement ce n'était pas le même que le mien. Voilà pour info à quoi cela ressemblait dans mon fichier sous NotePad ("Û" sous le bloc note):
et voici pour @sebGIS à la ligne 109801 (faut être courageux, bravo à lui)!
|
|
Merci à tous pour vos tests, solutions, etc. Et bienvenue dans la joie des fichiers MAJIC (avec parfois des caractères hiéroglyphes, ou des dates 'NSP' ou 'INCONNU' au lieu de 20191001). J'avais déjà intégré du code pour nettoyer les données non ASCII ici
Mais cela ne suffit pas car là c'est carrément la function chunk qui pose souci en amont
NB: l'idée de chunk, c'est de pouvoir justement charger les gros fichiers MAJIC par bout, pour ne pas surcharger la RAM. Je vais devoir modifier cette méthode pour y intégrer un test/remplacement des caractères pourris |
|
Corrigé via 89b8e11 Pouvez-vous tester svp ? |
|
Bonjour, Je viens de mettre à jour les scripts avec la modification de hier, j'ai toujours l'erreur. |
|
Pour info, dans notepad on peut trouver où sont les caractères non ASCI. |
tr -c "[:space:] -~" "X"<PROP.txt>NEWPROP.txt |
|
Le passage sur QGis confirme que le soucis n'est plus au niveau de l'encodage (il n'arrivait pas à afficher l'erreur). ERREUR : MAJIC - Les données concernent des départements et codes direction différents : Alors que tout commence par 560. |
|
Pour ma part, la version 1.8.1 du plugin corrige bien l'erreur: |
|
Par contre j'ai une grosse différence de performance entre la version 1.8.0 et 1.8.1: |
|
deuxième test réalisé à l'instant sur une autre commune: Je devrais peut-être poster mon commentaire sur un autre sujet, je ne sais pas. Mes tests sont réalisés communes par commune, mais j'imagine qu' à l'échelle d'un département la différence peut se compter en heures, voir en jours selon la machine qu'on possède. |
|
@mathieuTOUBLANC Merci de créer une nouvelle demande sur github pour les soucis de performance. Pouvez vous y ajouter le log de chaque import, histoire de voir quelle requête prend du temps ? |
|
Bonjour, |
|
@mdouchin |
|
Bonjour, |
|
@djes pourriez vous proposer un pull request ? Si vous n'êtes pas familier avec Github, vous pouvez modifier directement le fichier ici: https://github.com/3liz/QgisCadastrePlugin/edit/master/cadastre_import.py @sebGIS merci pour le retour. Il faut absolument qu'on trouve ce qui rallonge l'import. Pourriez-vous SVP lancer l'import sur une bdd de test avec les 2 versions et poser ici le log complet de l'import ? |
|
@mdouchin Pas de pb une avec la version 1.8.1 et l'autre en 1.8.0 (j'ai pas gardé je le trouve où) Postgres 9.6 |
|
Merci @sebGIS La version 1.8.0 peut être trouvée ici: On peut dans QGIS 3.4 ajouter une extension depuis un ZIP. Il faut bien sûr supprimer d'abord l'extension 1.8.1 |
|
N'oubliez pas de renommer le fichier zip en cadastre.zip ainsi que le dossier contenu, sinon ça ne fonctionne pas. |
C'est fait : djes@ddcbd31 |
|
Désolé |
|
log 1.8.1 |
|
Bah après trois test avec la version 1.8 j'arrive à la + ou - la même chose. |
|
Bonjour @sebGIS Peut-on fermer ce ticket ? |
|
oui c'est bon merci |
|
pas retrouver le bon je suis sebGIS |
|
Merci pour le retour |
|
c'est normal
Le jeu. 3 sept. 2020 à 15:37, Étienne Trimaille <notifications@github.com>
a écrit :
… Merci pour le retour
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#191 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI2ZGB7RMANB4KT5LNMCRRDSD6LYZANCNFSM4IJ7AZ3A>
.
|
|
Bonjour,
J'ai fini par trouver comment corriger mon problème (la résolution de celui-ci est peut-être similaire) Dans le fichier QgisCadastrePlugin/cadastre/cadastre_import.py Lines 1015 to 1016 in 2b2c0e3 Voici le fix: with open(scriptPath, 'w', encoding='utf-8') as fout:
fout.write(data)La locale système ne doit pas être configuré comme il faut dans QGIS. # Explicitly open with ascii encoding:
# ❌ Error:
# UnicodeEncodeError: 'ascii' codec can't encode character '\u2122' in position 0: ordinal not in range(128)
with open('/tmp/test', 'w', encoding='ascii') as fout:
fout.write(u"\u2122")
# Open without encoding specified:
# ❌ Error or ✅ Works depending of system locale :
# UnicodeEncodeError: 'ascii' codec can't encode character '\u2122' in position 0: ordinal not in range(128)
with open('/tmp/test', 'w') as fout:
fout.write(u"\u2122")
# Explicitly open with utf-8 encoding:
# ✅ Works
with open('/tmp/test', 'w', encoding='utf-8') as fout:
fout.write(u"\u2122")Pour forcer la locale dans QGIS, j'ai ajouté la variable d'environnement
Je ne suis pas sûr qu'il faille garder ce paramétrage mais ca aide pour débugger. |
Bonjour,
Voici le problème que j'ai rencontré à l'utilisation du plugin :
Description du bug
Lors du lancement de l'import des données en base spatialite dans le plugin Cadastre, un message d'erreur python apparaît concernant l'encodage. Y aurait-il un moyen de le résoudre simplement en changeant l'encodage ? si oui, dans quels fichiers et comment savoir par quel encodage ?
Reproduire le bug
Étapes pour reproduire le bug
Même problème rencontré en changeant de version Qgis et en réinstallant l'extension.
Idem avec une base existante ou une nouvelle base spatialite.
Idem avec la création d'un schéma sous Postgres/postgis.
Log
Environnement
Windows 7
Version de Python : 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)]
Version de QGIS : 3.8.1-Zanzibar Zanzibar, dcd95cc648
Version du plugin : Version 1.7.1
Testé et reproduit en version QGIS LTR 3.4.1
Merci d'avance pour le temps que vous pourrez consacrer à ce problème.
The text was updated successfully, but these errors were encountered: