Je analyse du XML avec la fonction Elementtree.Parse (). Cela fonctionne, à l'exception de certains caractères UTF-8 (caractère d'octets unique au-dessus de 128). Je vois que l'analyseur par défaut est XMLtreeebuilder qui est basé sur expatriés.
existe un analyseur alternatif que je peux utiliser qui peut être moins strict et autoriser des caractères UF-8? P>
C'est l'erreur I 'M Obtenir avec l'analyseur par défaut: P>
ExpatError: not well-formed (invalid token): line 311, column 190
4 Réponses :
octet 0x92 n'est jamais valide comme le premier octet d'un caractère UTF-8. Il peut être valide comme un octet ultérieur. Voir Ce guide UTF-8 pour une table des séquences d'octets valides.
Pourriez-vous nous donner une idée de ce que les octets entourent 0x92? La déclaration XML comprend-elle un codage de caractères?
On dirait que vous avez du texte CP1252. Si tel est le cas, il doit être spécifié en haut du fichier, par exemple.:
s.decode("CP1252").encode("UTF-8")
Pas européen, nous sommes définitivement aux États-Unis. Je ne le fais pas, je promets :)
Votre question est brouillée: vous avez dit que le texte est "Canít", qui est une petite lettre I avec une aiguë (U2019). Je traite régulièrement de suffisamment de langues étrangères inconnues que j'interprète comme écrit. Veuillez corriger la question. La réponse est la même; Il suffit de substituer CP852 pour CP1252. Au fait, 0x92 dans CP1252 n'est pas une apostrophe, c'est un «devis» droit. Je ne devrais probablement pas être étonné que certains logiciels soient suffisamment cassés pour obtenir Apostrophes mal. (Pas votre faute - la faute du logiciel sorti cette chaîne.)
@Glenn Maynard: (1) La reproduction du texte non ASCII par un OP est souvent brouillée. Ce que vous voyez n'est pas toujours ce qu'ils ont. the_raw_bytes.repr () est leur ami et le vôtre. Son "Aposttratamé" était un indice vital (2) "Petite lettre I avec une aiguë (U2019)": hein? Selon la norme UNICODE, U + 2019 est la bonne guillemande unique qui codée dans CP1252 est 0x92 (3) Les fabricants du logiciel prétendument brisé doivent avoir lu la norme UNICODE sur U + 2019: "C'est le caractère préféré à utiliser pour Apostrophe ". (4) CP852? Son 0x92 -> petite lettre L (ell pas i oeil) avec aiguë
Je dois souligner que si la norme UNICODE dit que le caractère préféré de l'apostrophe est une citation étroite, la norme UNICODE est fausse. Cela enfreint le bon sens de nombreuses manières évidentes et je peux garantir que 0x27 Apostrophe continuera de rester la bonne représentation d'une apostrophe.
Désolé d'être incertain, mais le texte est vraiment: 63 61 6e 92 74, peu importe ce à quoi on ressemble dans un éditeur particulier.
Je l'ai eu, mais ce que j'ai interprété, c'est que cette ficelle d'octet est apparue dans les rédacteurs comme dans le poste, c'est pourquoi je me suis retrouvé au CP852. Quoi qu'il en soit, votre réponse est là - il suffit d'utiliser s.decode ("CP1252"). Encode ("utf-8") ou ajouter En haut de la Fichier XML s'il est logique de le modifier directement. (Vous ne voulez pas faire cela "de manière transparente" - ça va gâcher des numéros de ligne dans des erreurs, etc.)
@Glenn Maynard: Pourquoi fini par CP852 est mystère. Caractère dans Post semble être U + 00Ed Latin Petite lettre I (Eye) avec aiguë. 0x92 en CP852 est U + 013A Latin Petite lettre L (ell) avec aiguë. Regardez: ĺí. Autres candidats: Mac-Roman, etc. U + 00ED (Eye), CP125X U + 2019 Devis unique à droite. Outre un problème oculaire, il y a un problème de probabilité a priori: prob (Europe de l'Est utilisant un codage DOS pour XML) moins que prob (coding Mac-xxxx) beaucoup moins que prob (suspects habituels (CP125X notamment CP1252)). Ensuite, il y a un problème de contexte: Canĺt ne peut-il pas ... quelle langue a un cluster de consonne NLT ??
Êtes-vous simplement trolling, ou pensez-vous vraiment que vous dites quelque chose de pertinent? J'ai donné la bonne réponse à la question de cette personne. Ici, je vais même éditer ma réponse avec la correction triviale que j'ai soulignée deux fois déjà.
ah. C'est "ne peut pas", évidemment, et en effet, 0x92 est une apostrophe dans de nombreuses pages de code Windows. Votre éditeur suppose plutôt que c'est un fichier Mac. ;)
Si c'est un coup de pied, la réparation du fichier est la bonne chose à faire. Mais presque toujours lorsque vous devez importer d'autres peuples XML, il y a beaucoup de choses qui ne sont tout simplement pas d'accord avec le codage indiqué. J'ai constaté que la meilleure solution consiste à décoder avec le paramètre d'erreur 'xmlcharrefreplace', et dans des cas graves, votre propre remplacement de caractères personnalisé résout les problèmes les plus courants pour ce client particulier.
Je recommanderai également LXML en tant que bibliothèque XML à Python, mais ce n'est pas le problème ici.
Je vais commencer à partir de la question suivante: "Y a-t-il un analyseur alternatif que je peux utiliser qui peut être moins strict et permettre des caractères UTF-8?"
Tous les analyseurs XML accepteront les données codées dans UTF-8. En fait, UTF-8 est le codage par défaut.
Un document XML peut commencer par une déclaration comme celle-ci: ou comme ceci:
Cependant, vos données ne sont pas codées dans UTF-8 ... c'est probablement Windows-1252 AKA CP1252. Si l'encodage n'est pas UTF-8, le créateur doit inclure une déclaration (ou le destinataire peut comporter un) ou le destinataire peut transcoder les données à UTF-8. Ce qui suit présente ce qui fonctionne et ce qui ne fonctionne pas:
ou ne pas avoir une déclaration du tout ... Dans chaque cas, l'analyseur décodera le document à l'aide de UTF-8.