2012-07-11 21 views
5

En Python, tengo un texto que está codificado en Unicode. Este texto contiene espacios sin interrupciones, que quiero convertir a 'x'. Los espacios sin ruptura son iguales a chr(160). Tengo el siguiente código, que funciona muy bien cuando lo ejecuto como Django a través de Eclipse usando Localhost. No se convierten los errores y espacios sin interrupción.Python: reemplace el espacio de no separación en Unicode

my_text = u"hello" 
my_new_text = my_text.replace(chr(160), "x") 

Sin embargo cuando corro de ninguna otra manera (línea de comandos Python, Django vía de ejecución del servidor en lugar de Eclipse) Me aparece un error:

'ascii' codec can't decode byte 0xa0 in position 0: ordinal not in range(128) 

supongo que este error tiene sentido porque se trata de comparar Unicode (my_text) a algo que no es Unicode. Mis preguntas son:

  1. Si chr(160) no es Unicode, ¿qué es?
  2. ¿Cómo es que esto funciona cuando lo ejecuto desde Eclipse? Comprender esto me ayudaría a determinar si necesito cambiar otras partes de mi código. He estado probando mi código desde Eclipse.
  3. (más importante) ¿Cómo resuelvo mi problema original de eliminar los espacios sin interrupción? my_text definitivamente va a ser Unicode.

Respuesta

11
  1. En Python 2, chr(160) es una cadena de bytes de longitud uno cuyo único byte tiene un valor de 160, o a0 hex. No tiene ningún significado, excepto en el contexto de una codificación específica.
  2. No estoy familiarizado con Eclipse, pero puede estar jugando trucos de codificación propios.
  3. Si desea el carácter Unicode NO-BREAK SPACE, es decir, el código del punto 160, es unichr(160).

por ejemplo,

>>> u"hello\u00a0world".replace(unichr(160), "X") 
u'helloXworld 
+0

perfecto, gracias. unichr() funciona tanto a través de Eclipse como no a través de Eclipse. Es extraño que chr() y unichr() den el mismo resultado cuando se ejecutan desde Eclipse. – user984003

+1

Su configuración de Eclipse puede cambiar la codificación predeterminada a UTF8 en lugar de ASCII. Eso no es recomendable, por lo que ahora deberían ser razones obvias de compatibilidad. El código escrito en esa configuración puede no funcionar en otro lugar. –

+0

En realidad, ASCII (0x00 a 0x7F) es compatible con UTF-8, ya que los primeros 128 puntos de código de UTF-8 son los mismos que los de ASCII. Sin embargo, 0xa0 definitivamente no es ASCII, de ahí el error al usar 'chr' en lugar de' unichr' ... – dda

Cuestiones relacionadas