J'écris du code python et je reçois le message d'erreur comme dans le titre, de la recherche cela a à voir avec le jeu de caractères.
Voici la ligne qui provoque l'erreur
hc = HealthCheck("instance_health", interval=15, target808="HTTP:8080/index.html")
Je n'arrive pas à comprendre quel caractère n'est pas dans le jeu ANSI ASCII? De plus, la recherche de "\ xe2" ne donne plus d'informations sur le caractère qui apparaît. Quel caractère de cette ligne est à l'origine du problème?
J'ai également vu quelques correctifs pour ce problème, mais je ne sais pas lequel utiliser. Quelqu'un pourrait-il clarifier quel est le problème (python n'interprète pas l'Unicode à moins qu'on ne lui dise de le faire?), Et comment je le réglerais correctement?
EDIT: Voici toutes les lignes proches de celle qui fait des erreurs
def createLoadBalancer():
conn = ELBConnection(creds.awsAccessKey, creds.awsSecretKey)
hc = HealthCheck("instance_health", interval=15, target808="HTTP:8080/index.html")
lb = conn.create_load_balancer('my_lb', ['us-east-1a', 'us-east-1b'],[(80, 8080, 'http'), (443, 8443, 'tcp')])
lb.configure_health_check(hc)
return lb
–
-\xe2\x80\x93
)Réponses:
Vous avez un octet errant qui flotte. Vous pouvez le trouver en exécutant
with open("x.py") as fp: for i, line in enumerate(fp): if "\xe2" in line: print i, repr(line)
où vous devez remplacer
"x.py"
par le nom de votre programme. Vous verrez le numéro de ligne et la ou les lignes incriminées. Par exemple, après avoir inséré cet octet arbitrairement, j'ai obtenu:4 "\xe2 lb = conn.create_load_balancer('my_lb', ['us-east-1a', 'us-east-1b'],[(80, 8080, 'http'), (443, 8443, 'tcp')])\n"
la source
O'Donnell
%E2
est un candidat. Généralement, le problème est de modifier le code avec des fonctionnalités «intelligentes» activées comme les «guillemets intelligents» remplacés"
par“
(U + 201C) et”
(U + 201D) ou se transformant--
en—
(U + 2014 em dash). Tous commencent par "\ xe2 \ x80" en UTF-8.Si vous essayez simplement d'utiliser des caractères UTF-8 ou que vous ne vous souciez pas de savoir s'ils sont dans votre code, ajoutez cette ligne en haut de votre
.py
fichier# -*- coding: utf-8 -*-
la source
Ou vous pouvez simplement utiliser:
# coding: utf-8
en haut du fichier .py
la source
\ xe2 est le caractère '-', il apparaît dans certains copier-coller, il utilise un aspect différent '-' qui provoque des erreurs d'encodage. Remplacez le «-» (du copier-coller) par le bon «-» (du bouton du clavier).
la source
Changer le codage des caractères du fichier,
mettez toujours en dessous de la ligne en haut de votre code
# -*- coding: utf-8 -*-
la source
J'ai eu la même erreur lors de la copie et du collage d'un commentaire à partir du Web
Pour moi, c'était une simple citation (') dans le mot
Je viens de l'effacer et de le retaper.
la source
L'ajout de la ligne # coding = utf-8 dans la première ligne de votre fichier .py résoudra le problème.
Veuillez en savoir plus sur le problème et son correctif sur le lien ci-dessous, dans cet article, le problème et sa solution sont magnifiquement décrits: https://www.python.org/dev/peps/pep-0263/
la source
J'ai eu cette erreur pour les caractères dans mes commentaires (en copiant / collant du contenu du Web dans mon éditeur à des fins de prise de notes).
Pour résoudre dans Text Wrangler:
la source
Basé sur PEP 0263 - Définition des codages de code source Python
Python will default to ASCII as standard encoding if no other encoding hints are given. To define a source code encoding, a magic comment must be placed into the source files either as first or second line in the file, such as: # coding=<encoding name> or (using formats recognized by popular editors) #!/usr/bin/python # -*- coding: <encoding name> -*- or #!/usr/bin/python # vim: set fileencoding=<encoding name> :
la source
J'ai eu le même problème et je viens de l'ajouter en haut de mon fichier (en Python 3, je n'avais pas le problème mais je le fais en Python 2
#!/usr/local/bin/python # coding: latin-1
la source
Si cela aide quelqu'un, pour moi, c'est arrivé parce que j'essayais d'exécuter une implémentation Django en python 3.4 avec ma commande python 2.7
la source
Après environ une demi-heure de recherche à travers le débordement de pile, je me suis rendu compte que si l'utilisation d'un guillemet simple "'" dans un commentaire passera par l'erreur:
SyntaxError: Non-ASCII character '\xe2' in file
Après avoir regardé le retraçage, j'ai pu localiser le guillemet simple utilisé dans mon commentaire.
la source
J'ai eu ce problème exact en exécutant le code .py simple ci-dessous:
import sys print 'version is:', sys.version
Le code DSM ci-dessus fournissait les éléments suivants:
1 'print \ xe2 \ x80 \ x98version est \ xe2 \ x80 \ x99, sys.version'
Le problème était donc que mon éditeur de texte utilisait des CITATIONS SMART, comme John Y l'a suggéré. Après avoir modifié les paramètres de l'éditeur de texte et ré-ouvert / enregistré le fichier, cela fonctionne très bien.
la source
J'essaie d'analyser cet étrange apostraphe de fenêtres et après avoir essayé plusieurs choses, voici l'extrait de code qui fonctionne.
def convert_freaking_apostrophe(self,string): try: issuer_rename = string.decode('windows-1252') except: issuer_rename = string.decode('latin-1') issuer_rename = issuer_rename.replace(u'’', u"'") issuer_rename = issuer_rename.encode('ascii','ignore') try: os.rename(directory+"/"+issuer,directory+"/"+issuer_rename) print "Successfully renamed "+issuer+" to "+issuer_rename return issuer_rename except: pass #HANDLING FOR FUNKY APOSTRAPHE if re.search(r"([\x90-\xff])", issuer): issuer = self.convert_freaking_apostrophe(issuer)
la source
Mon cas \ xe2 était un
’
qui devrait être remplacé par'
.En général, je recommande de convertir UTF-8 en ASCII en utilisant par exemple https://onlineasciitools.com/convert-utf8-to-ascii
Cependant, si vous souhaitez conserver UTF-8, vous pouvez utiliser
#-*- mode: python -*- # -*- coding: utf-8 -*-
la source
J'ai eu le même problème, mais c'était parce que j'ai copié et collé la chaîne telle quelle. Plus tard, lorsque j'ai tapé manuellement la chaîne, l'erreur a disparu.
J'ai eu l'erreur à cause du
-
signe. Lorsque je l'ai remplacé par la saisie manuelle d'un-
l'erreur a été résolue.Chaîne copiée
10 + 3 * 5/(16 − 4)
Chaîne saisie manuellement
10 + 3 * 5/(16 - 4)
vous pouvez clairement voir qu'il y a un peu de différence entre les deux traits d'union .
Je pense que c'est à cause du formatage différent utilisé par différents systèmes d'exploitation ou peut-être simplement par des logiciels différents.
la source
Pour moi, le problème était dû à "'" ce symbole dans les guillemets. Comme j'avais copié le code à partir d'un fichier pdf, cela a causé cette erreur. Je viens de remplacer "'" par ce "'".
la source
Si vous voulez repérer le caractère qui a causé cela, affectez simplement la variable problématique à une chaîne et imprimez-la dans une console iPython.
Dans mon cas
In [1]: array = [[24.9, 50.5], [11.2, 51.0]] # Raises an error In [2]: string = "[[24.9, 50.5], [11.2, 51.0]]" # Manually paste the above array here In [3]: string Out [3]: '[[24.9, 50.5]\xe2\x80\x8b, [11.2, 51.0]]' # Here they are!
la source
pour moi, le problème a été causé en tapant mon code dans Mac Notes, puis en le copiant à partir de Mac Notes et en le collant dans ma session vim pour créer mon fichier. Cela a fait de mes guillemets simples le type incurvé. pour le réparer, j'ai ouvert mon fichier dans vim et remplacé tous mes guillemets simples courbes par le type droit, simplement en supprimant et en retapant le même caractère. Ce sont Mac Notes qui ont fait le même coup de touche produire le guillemet simple incurvé.
la source
Je n'ai pas pu trouver quel était le problème pendant longtemps, mais plus tard, j'ai réalisé que j'avais copié une ligne "UTC-12: 00" à partir du Web et que le trait d'union / tiret était à l'origine du problème. Je viens d'écrire à nouveau ce "-" et le problème a été résolu.
Ainsi, parfois, les lignes copiées-collées donnent également des erreurs. Dans de tels cas, réécrivez simplement le code copié et cela fonctionne. Lors de la réécriture, il semblerait que rien n'ait changé, mais l'erreur disparaîtra.
la source
Beaucoup de bonnes solutions ici.
Un défi qui n'est pas vraiment abordé dans aucun d'entre eux est de savoir comment identifier visuellement certains caractères non ASCII difficiles à repérer qui ressemblent à d'autres caractères ASCII simples. Par exemple, les tirets fr peuvent apparaître presque exactement comme des tirets et les guillemets bouclés ressemblent beaucoup à des guillemets droits, selon la police de votre éditeur de texte.
Ce one-liner, qui devrait fonctionner sur Mac ou Linux, supprimera les caractères qui ne sont pas dans la plage imprimable ASCII et vous montrera les différences côte à côte:
# assumes Bash shell; for Bourne shell (sh), rearrange as a pipe and # give '-' as second argument to 'sdiff' instead sdiff --suppress-common-lines script.py <(tr -cd '\11\12\15\40-\176' <script.py)
Les caractères
\11
,\12
et\15
sont respectivement tabulation, nouvelle ligne et retour chariot en octal; la plage restante correspond aux caractères ASCII visibles. ( pointe du chapeau )Un autre conseil glané de ce thread SO utilise une classe de caractères inverses constituée de tout ce qui n'est pas dans la plage visible ASCII et la met en évidence:
grep --color '[^ -~]' script.py
Cela devrait également fonctionner correctement avec la version macOS / BSD de grep.
la source
Lorsque j'ai un problème similaire lors de la lecture de fichiers texte que j'utilise ...
f = open('file','rt', errors='ignore')
la source