2011-07-15 14 views
6

Estoy tratando de recoger algo de raw_input Unicode en el entorno de programación Python por defecto, y por lo que yo sé, que debería ser tan simple como:Unicode de entrada en el entorno de programación Python (Mac OS X)

>>> c = raw_input() 
日本語 
>>> print c 
日本語 

Sin embargo, cuando trato de ingresar los caracteres Unicode, la computadora emite algunas protestas y termino con una cadena vacía. (Para hacer esto, hago clic en el selector IME cerca de la hora y selecciono el método de entrada apropiado [que en este caso es la entrada japonesa]). Fuera del IDE de python, la entrada funciona bien, puedo ingresar los caracteres y el sistema los reconoce como recibidos. En el IDE, escribiré algunos hiragana, y la ventana de selección de kanji desplegable aparece como de costumbre, pero cuando selecciono la representación adecuada y presiono enter, esos pitidos vienen y termino sin nada. Me imagino que hay un entorno involucrado en algún lugar que me he perdido.

versiones son:

Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin 

y

Python 2.5.4 (r254:67916, Jun 24 2010, 21:47:25) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin 

ninguno de los cuales trabajo. También hay esto:

>>> import sys 
>>> sys.getdefaultencoding() 
'ascii' 
>>> sys.stdin.encoding 
'UTF-8' 
>>> sys.stdout.encoding 
'UTF-8' 
>>> sys.getfilesystemencoding() 
'utf-8' 

pero por lo que he leído, el defaultencoding es una bestia misteriosa. Cambiarlo en realidad no arregla nada de todos modos. Es decir,

>>> import sys 
>>> sys.setdefaultencoding('utf-8') 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
AttributeError: 'module' object has no attribute 'setdefaultencoding' 
>>> reload(sys) 
<module 'sys' (built-in)> 
>>> sys.setdefaultencoding('utf-8') 
>>> # !!! 
... c = raw_input() 
no dice! 

no funciona. Solo más pitidos. Tampoco puedo cortar y pegar texto japonés de otras aplicaciones.

+0

Por "IDE de Python" ¿quiere decir IDLE? –

+0

Si te refieres a IDLE, me funciona bien con Python 2.6.5. –

+0

En realidad, me refería a REPL, pero me impresionó el cerebro. – fromClouds

Respuesta

0

Editar: Probé Python desde la línea de comandos (Terminal), y no funciona, y me llegan los pitidos que está hablando. No parece ser una limitación de Terminal, ya que puedo pegar los caracteres en el $ prompt en bash bien. Funciona en Idle, como muestro a continuación.

Edición # 2: Es interesante que esta sola línea funciona:

$ python -c "exec(\"c=raw_input()\nprint c\")" 
日本語 <-- pasted 
日本語 

me gustaría poner esto en un comentario, pero no sería formatear correctamente. La salida de 2.6.5 MacOSX:

Python 2.6.5 (r265:79359, Mar 24 2010, 01:32:55) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin 
Type "copyright", "credits" or "license()" for more information. 

    **************************************************************** 
    Personal firewall software may warn about the connection IDLE 
    makes to its subprocess using this computer's internal loopback 
    interface. This connection is not visible on any external 
    interface and no data is sent to or received from the Internet. 
    **************************************************************** 

IDLE 2.6.5  
>>> c=raw_input() 
日本語 
>>> print c 
日本語 
>>> c 
u'\u65e5\u672c\u8a9e' 
>>> 
+0

Muy bien, es bueno tener una confirmación independiente de lo que estaba experimentando. Sin embargo, cuando enciendo IDLE, tampoco puedo ingresar caracteres japoneses, aunque en lugar de rechazarlo directamente, simplemente pasa los caracteres ASCII. (No estoy seguro de si está familiarizado con la entrada japonesa, pero escribe cosas en inglés fonético, y las reemplaza con fonética japonesa, y luego, cuando llega al final de una palabra, le da un menú desplegable de que seleccionas la versión ideográfica (carácter chino). Nada de esto sucede en IDLE (aunque funciona cortar y pegar). – fromClouds

+0

@fromClouds - No estoy familiarizado con esa forma de entrada (¡gracias por la mini lección!) IDLE parece tomarse un poco de libertad con IO estándar, y supongo que hay algo no estándar en la forma en que acepta la entrada del teclado. Dudo que encuentres una opción de configuración para esto, y es posible que tengas que encontrar un IDE diferente de IDLE para trabajar con. –

+0

Gracias Chris, creo que lo haré. Probablemente solo conecte una interfaz web para esto por el momento. Además, recupero lo que dije previamente, cortar y pegar (para lo que sea razón) se bloquea IDLE. – fromClouds

0

Prueba esto:

import codecs, sys 
sys.stdin = codecs.getreader('UTF-8')(sys.stdin) 
sys.stdout = codecs.getwriter('UTF-8')(sys.stdout) 
sys.stderr = codecs.getwriter('UTF-8')(sys.stderr) 

print u'\u65e5\u672c\u8a9e' 

Esto funciona para mí para caracteres no ASCII al usar la masilla con la codificación del terminal a UTF-8. Veo cuadros porque no tengo fuentes para caracteres CJK instalados, pero creo que esto debería hacerlo por usted.

La razón por la que esto funciona es que, de manera predeterminada, el intérprete de Python utiliza el códec 'ascii' para stdin, stdout y stderr. Y como ASCII solo define valores de bytes de 0 a 127, solo se pueden imprimir los valores de bytes.

3

He tenido el mismo problema. En mi caso, resultó ser un libedit problema.Lo arreglé instalando readline, que tuve que hacer desde el código fuente (desde aquí: http://pypi.python.org/pypi/readline) ya que al usar pip o easy_install, por alguna razón, no reemplazó readline.

Si tiene ipython instalado, se le indicará en el arranque si está usando libedit. Y, si tiene la misma experiencia que yo, verá los mismos problemas tanto en el intérprete de python en Terminal como en ipython. Una vez que readline realmente se instaló, y ipython ya no me informó que estaba usando libedit, los problemas para ingresar a Unicode desaparecieron tanto en python como en ipython.

. (Nota: También tengo instalado bpython - y, ya que no parece utilizar readline o libedit, sino más bien sus propias rutinas de edición de línea, entrando en Unicode bpython siempre trabajadas)

3

La codificación defaulten no debería afectar aquí. Tuve un problema similar y, para mí, la solución fue verificar la opción Escape no entrada ASCII en Terminal> Preferencias> Configuraciones> Avanzado. También asegúrese de que la codificación de caracteres esté configurada en Unicode (UTF-8) en la misma página de configuración.

Cuestiones relacionadas