Pregunta

tengo esto:

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

¿Qué tengo que hacer para imprimir:

EXÁMPLE

(donde la 'a' obtiene su acento agudo, pero en mayúsculas.)

Estoy usando Python 2.6.

¿Fue útil?

Solución

Creo que es tan simple como no convertir a ASCII en primer lugar.

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

Otros consejos

En Python 2.x, simplemente convertir la cadena a Unicode antes de llamar superior (). Utilizando su código, que está en formato UTF-8 en esta página 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 á

La llamada a decode lo toma de su formato actual a Unicode. A continuación, puede convertirlo a otro formato, como UTF-8, mediante el uso de codificación. Si el personaje estaba en, por ejemplo, iso-8859-2 (Checa, etc, en este caso), debe en su lugar utilizar s.decode('iso-8859-2').upper().

Al igual que en mi caso, si el terminal no es Unicode / UTF-8 compatible, lo mejor que puede esperar es o bien una representación hexadecimal de los personajes (como el mío) o para convertirlo lossily usando s.decode('utf-8').upper().encode('ascii', 'replace'), que se traduce en " EX? MPLE'. Si no puede hacer que su terminal de espectáculo Unicode, escribir el resultado en un archivo en formato UTF-8 y abierto que en su editor favorito.

En primer lugar, yo sólo uso Python 3.1 en estos días; su mérito es tener el centro de cadenas de bytes desambiguados de objetos Unicode. esto hace que la gran mayoría de las manipulaciones de texto mucho más seguro que solía ser el caso. con un peso de los billones de preguntas de los usuarios con respecto a los problemas de Python 2.x de codificación, la convención u'äbc de Python 2.1 fue sólo un error; con bytes explícita y bytearray, la vida se vuelve mucho más fácil.

En segundo lugar, si py3k no es su sabor, a continuación, tratar de ir con from __future__ import unicode_literals, ya que esto imitar el comportamiento de py3k en Python 2.6 y 2.7. esto habría evitado la (fácilmente comprometida) cometer un error que hizo al decir print 'exámple'.upper(). En esencia, este es el mismo que en py3k: print( 'exámple'.encode( 'utf-8' ).upper() ). comparar estas versiones (por py3k):

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

La primera de ellas está, básicamente, lo que hizo cuando utilizó un 'exámple' cadena pura, siempre y cuando se establece su codificación predeterminada a utf-8 (según un pronunciamiento BDFL, estableciendo la codificación predeterminada en tiempo de ejecución es una mala idea, por lo que en AP2 que tendrá que engañar a esto diciendo import sys; reload( sys ); sys.setdefaultencoding( 'utf-8' ); os presento una mejor solución para py3k abajo). cuando se mira a la salida de estas tres líneas:

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

se puede ver que cuando upper() consiguió aplica al primer texto, actúa en bytes, no en caracteres. Python permite que el método upper() en bytes, pero sólo se define en la interpretación US-ASCII de bytes. desde UTF-8 utiliza valores dentro de 8 bits pero fuera de US-ASCII (128 hasta 255, que no se utilizan por US-ASCII), los que no habrá afectados por upper(), por lo que cuando desciframos de vuelta en la segunda línea, obtenemos que la minúscula á. Por último, la tercera línea lo hace bien, y sí, sorpresa, pitón parece ser consciente de que Á es la letra mayúscula correspondiente a á. Hice una prueba rápida para ver qué caracteres Python 3 no convierte entre mayúsculas y minúsculas:

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

visionar la lista revela muy pocos casos de las letras latinas, cirílico, griego o; la mayor parte de la producción es caracteres no europeos y puntuacion. los únicos personajes que podría encontrar que pitón has fallado son Ԥ / ԥ (\ u0524 \ u0525, 'cirílico {Capital | pequeñas} PE carta con descensor'), así como el tiempo que permanezca fuera de los bloques extendido-X Latina ( echa un vistazo a los que, podrían dar sorpresas), que en realidad podría usar ese método. por supuesto, no lo hice comprobar la corrección de las asignaciones.

Por último, aquí es lo que he puesto en mi sección de arranque de aplicaciones py3k: un método que redefine ve el sys.stdout codificación, con referencias de caracteres numéricos (NCR) como de respaldo; esto tiene el efecto de que la impresión de la salida estándar nunca se levantará un error de codificación Unicode. Cuando trabajo en ubuntu, _sys.stdout.encoding es utf-8; cuando el mismo programa se ejecuta en Windows, que podría ser algo pintoresco como cp850. la fuerza de salida se ve starnge, pero la aplicación se ejecuta sin generar una excepción en aquellos terminales cortos de luces.

#===========================================================================================================
# 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()

una pieza más del consejo: cuando se prueba, siempre trate de print repr( x ) o una cosa similar que revela la identidad de x. todo tipo de malentendidos pueden surgir si sólo print x en AP2 y x es o bien un octeto cadena o un objeto Unicode. es muy desconcertante y propenso a causar una gran cantidad de rascarse la cabeza. como ya he dicho, tratar de mover al menos a py26 con la de futuro Unicode importación literales encantamiento.

y para cerrar, citando una cita: "Glifo Lefkowitz dice mejor en su artículo Codificación :

  

Creo que en el contexto de esta   discusión, el término "cadena" es   sin sentido. Hay texto, y hay   es Bde datos orientada YTE-(que muy puede   así representar texto, pero no es todavía   convertida a él). En los tipos de Python,   El texto es Unicode. Los datos son str. La idea   de "texto no Unicode" es sólo una   error de programación a punto de ocurrir ".

Actualización: acabo de enterar pitón 3 convierte correctamente Latina de la LETRA DE LARGO S a S cuando uppercasing. aseado!

Creo que hay un poco de historia que nos falta aquí:

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

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

Mientras usted está utilizando cuerdas "Unicode" en lugar de cadenas "nativos", los operadores como superior () operarán con Unicode en mente. Fwiw, Python 3 utiliza Unicode de manera predeterminada, por lo que la distinción en gran medida irrelevante.

Tomar una cadena de unicode a str y luego de vuelta a unicode es subóptima de muchas maneras, y muchas bibliotecas producirá una salida Unicode si lo desea; así que trate de usar sólo los objetos unicode para las cadenas internamente siempre que pueda.

Inténtelo:

s = 'exámple'
print unicode(s).upper()
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top