Question

J'ai ceci:

>>> print 'example'
example
>>> print 'exámple'
exámple
>>> print 'exámple'.upper()
EXáMPLE

Ce que je dois faire pour imprimer:

EXÁMPLE

(où le 'a' obtient son accent aigu, mais en majuscules.)

J'utilise Python 2.6.

Était-ce utile?

La solution

Je pense qu'il est aussi simple que pas convertir en ASCII en premier.

 >>> print u'exámple'.upper()
 EXÁMPLE

Autres conseils

Dans 2.x python, juste convertir la chaîne en unicode avant d'appeler supérieure (). En utilisant votre code, qui est en format utf-8 sur cette page Web:

>>> s = 'exámple'
>>> s
'ex\xc3\xa1mple'  # my terminal is not utf8. c3a1 is the UTF-8 hex for á
>>> s.decode('utf-8').upper()
u'EX\xc1MPLE'  # c1 is the utf-16 aka unicode for á

L'appel à decode prend de son format actuel à unicode. Vous pouvez ensuite le convertir en un autre format, comme utf-8, en utilisant encode. Si le personnage était, par exemple, iso-8859-2 (tchèque, etc, dans ce cas), vous utilisez plutôt s.decode('iso-8859-2').upper().

Comme dans mon cas, si votre terminal n'est pas unicode / utf-8 conforme, le mieux que vous pouvez espérer est soit une représentation hexadécimale des caractères (comme le mien) ou de le convertir lossily en utilisant s.decode('utf-8').upper().encode('ascii', 'replace'), qui se traduit par ' EX? MPLE. Si vous ne pouvez pas faire de votre terminal émission unicode, écrire la sortie vers un fichier au format utf-8 et ouvrir que dans votre éditeur préféré.

Tout d'abord, je n'utilise que python 3.1 ces jours-ci; son mérite central est d'avoir des chaînes désambiguïsé d'octets à partir d'objets unicode. ce qui rend la grande majorité des manipulations de texte beaucoup plus sûr que l'habitude d'être le cas. pesant les billions de dollars de questions des utilisateurs en ce qui concerne les problèmes d'encodage 2.x python, la convention de u'äbc de python 2.1 était une erreur; avec explicite bytes et bytearray, la vie devient beaucoup plus facile.

D'autre part, si Py3K est pas votre goût, essayez d'aller avec from __future__ import unicode_literals, car cela va imiter le comportement de Py3K sur Python 2.6 et 2.7. cette chose aurait évité le (facilement engagé) que vous avez fait gaffe en disant print 'exámple'.upper(). essentiellement, c'est le même que dans Py3K: print( 'exámple'.encode( 'utf-8' ).upper() ). comparer ces versions (pour Py3K):

print( 'exámple'.encode( 'utf-8' ).upper() )
print( 'exámple'.encode( 'utf-8' ).upper().decode( 'utf-8' ) )
print( 'exámple'.upper() )

La première est, au fond, ce que vous avez fait quand il est utilisé une 'exámple' chaîne nue, à condition que vous définissez votre encodage par défaut à utf-8 (selon une déclaration BDFL, paramétrage de l'encodage par défaut lors de l'exécution est une mauvaise idée, donc en py2 vous devrez tromper en disant import sys; reload( sys ); sys.setdefaultencoding( 'utf-8' ), je présente une meilleure solution pour Py3K ci-dessous). quand vous regardez la sortie de ces trois lignes:

b'EX\xc3\xa1MPLE'
EXáMPLE
EXÁMPLE

vous pouvez voir que lorsque upper() se est appliqué au premier texte, il a agi sur les octets, et non sur les personnages. python permet la méthode upper() sur des octets, mais il est défini que sur l'interprétation US-ASCII d'octets. depuis utf-8 utilise des valeurs dans les 8 bits mais en dehors de US-ASCII (128 à 255, qui ne sont pas utilisées par l'US-ASCII), ceux-ci ne pas être affectés par upper(), alors quand on décode de retour dans la deuxième ligne, nous obtenons que á minuscules. enfin, la troisième ligne droite le fait, et oui, surprise, python semble être conscient que Á est la lettre majuscule correspondant à á. J'ai couru un test rapide pour voir ce que les caractères python 3 ne convertit pas entre majuscules et minuscules:

for cid in range( 3000 ):
  my_chr = chr( cid )
  if my_chr == my_chr.upper() and my_chr == my_chr.lower():
    say( my_chr )

parcourant la liste révèle très peu l'incidence des lettres latines, cyrilliques ou grecs; la plupart de la production est des caractères non-européens et la ponctuation. les seuls personnages que je pouvais trouver que python se sont mal sont Ԥ / ԥ (\ u0524, \ u0525, « cyrillique {capitale | petites} lettre pe avec descendeur »), aussi longtemps que vous restez en dehors des blocs Latin étendu-X ( consultez ceux-ci, ils pourraient donner des surprises), vous pouvez réellement utiliser cette méthode. Bien sûr, je n'ai pas vérifié l'exactitude des correspondances.

enfin, voici ce que je mets dans mon application Py3K section de démarrage: une méthode qui redéfinit le sys.stdout de codage voit, avec des références de caractères numériques (DND) comme fallback; cela a pour effet que l'impression sur la sortie standard ne sera jamais provoquer une erreur d'encodage unicode. quand je travaille sur ubuntu, _sys.stdout.encoding est utf-8; lorsque le même programme fonctionne sur Windows, il pourrait être quelque chose comme pittoresque cp850. la puissance de sortie semble starnge, mais l'application fonctionne sans soulever une exception sur les terminaux faibles d'esprit.

#===========================================================================================================
# MAKE STDOUT BEHAVE IN A FAILSAFE MANNER
#-----------------------------------------------------------------------------------------------------------
def _harden_stdout():
  """Ensure that unprintable output to STDOUT does not cause encoding errors; use XML character references
  so any kind of output gets a chance to render in a decipherable way."""
  global _sys_TRM
  _sys.stdout       = _sys_TRM = _sys_io.TextIOWrapper(
    _sys.stdout.buffer,
    encoding        = _sys.stdout.encoding,
    errors          = 'xmlcharrefreplace',
    line_buffering  = true )
#...........................................................................................................
_harden_stdout()

un conseil plus: lors du test, essayez toujours de print repr( x ) ou quelque chose de semblable qui révèle l'identité de x. toutes sortes de malentendus peuvent surgir si vous print x juste à py2 et x est soit une chaîne d'octets ou un objet unicode. il est très déroutante et sujette à causer beaucoup de tête-éraflure. comme je l'ai dit, essayez de déplacer au moins py26 avec celui de incantatoire de littéraux unicode à l'importation future.

et de fermer, citant une citation: "Glyphe Lefkowitz dit mieux dans son article encodage :

  

Je crois que dans le contexte de cette   discussion, le terme « chaîne » est   sans signification. Il y a du texte, et   est Bdonnées orienté YTE-(qui peut très   bien représenter du texte, mais il est pas encore   converti à elle). Dans les types Python,   Texte est unicode. Les données sont str. L'idée   de est juste un « texte non Unicode »   erreur de programmation en attente de se produire. "

Mise à jour: juste trouvé python 3 convertit correctement s LONG LETTRE MINUSCULE LATINE S à S lorsque uppercasing. chouette!

Je pense qu'il ya un peu de fond nous manque ici:

>>> type('hello')
<type 'str'>

>>> type(u'hello')
<type 'unicode'>

Tant que vous utilisez des chaînes « unicode » au lieu de chaînes « indigènes », les opérateurs comme supérieur () fonctionneront avec unicode à l'esprit. FWIW, Python 3 utilise unicode par défaut, ce qui rend la distinction en grande partie hors de propos.

Prendre une chaîne de unicode à str puis retour à unicode est suboptimale à bien des égards, et de nombreuses bibliothèques produira une sortie unicode si vous le voulez; essayez donc d'utiliser uniquement les objets unicode pour les chaînes en interne à chaque fois que vous le pouvez.

Essayez:

s = 'exámple'
print unicode(s).upper()
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top