2010-11-10 5 views

Respuesta

31

Lo que oyó está desactualizado y se aplica (solo parcialmente) a Ruby 1.8 o versiones anteriores. La última versión estable de Ruby (1.9) admite no menos de codificaciones de caracteres diferentes (contadas en mi sistema en este momento). Esto incluye prácticamente todos los formatos de transformación Unicode conocidos, incluido UTF-8.

La versión estable anterior de Ruby (1.8) tiene compatibilidad parcial para UTF-8.

Si usa Rails, se encarga de la codificación UTF-8 predeterminada. Si todo lo que necesita es conocimiento de codificación UTF-8, Rails funcionará para usted sin importar si ejecuta Ruby 1.9 o Ruby 1.8. Si tiene requisitos de codificación de caracteres muy específicos, debe apuntar a Ruby 1.9.

Si está realmente interesado, aquí hay un series of articles que describe los problemas de codificación en Ruby 1.8 y cómo se solucionaron, y finalmente se resolvió en Ruby 1.9. Rails todavía incluye soluciones provisionales para muchos defectos comunes en Ruby 1.8.

+0

para cualquier persona como yo que busque un acceso directo a un equivalente de $ KCODE para el cambio de codificación por defecto programático, lo que quiere es: Encoding.default_internal = 'utf-8' # Encoding.list.map (&: names) – Travis

+0

Link's dead. :( – user2357112

14

Eso no es verdad. Lo que es cierto es que Ruby no admite solo Unicode, también admite una gran cantidad de otras codificaciones.

Esto está en contraste con los sistemas como Java, .NET o Python, que siguen el modelo "Una codificación para gobernarlos a todos". Ruby tiene lo que uno de los diseñadores del sistema m17n de Ruby llama un modelo "CSI" (Code Set Indepedent), lo que significa que en lugar de todas las cadenas que solo tienen una y la misma codificación, cada cadena está etiquetada con su propia codificación.

Esto tiene algunas ventajas significativas tanto por su facilidad de uso como por su rendimiento, porque significa que si sus codificaciones de entrada y salida son iguales, nunca necesita transcodificar, mientras que con el modelo One True Encoding, necesita transcodificar dos veces en el peor de los casos (y ese peor caso desafortunadamente ocurre con bastante frecuencia, porque la mayoría de estos entornos eligen una codificación interna que nadie usa realmente), desde la codificación de entrada a la codificación interna y luego a la codificación de salida. En Ruby, necesitas transcodificar como máximo una vez.

El problema básico con el modelo OTE es que cualquiera que sea la codificación que elija como One True Encoding, será una elección completamente arbitraria, ya que simplemente no hay una sola codificación que use todo el mundo, o incluso la mayoría.

En Java, por ejemplo, eligieron UCS-2 como One True Encoding. Luego, un par de años más tarde, resultó que UCS-2 en realidad no era suficiente para codificar todos los caracteres, por lo que tuvieron que hacer un cambio incompatible con Java, para cambiar a UTF-16 como la codificación de One True. Excepto en ese momento, una porción significativa del mundo había pasado de UTF-16 a UTF-8. Si Java se hubiera inventado un par de años antes, probablemente hubieran elegido ASCII como One True Encoding. Si se hubiera inventado en otro país, podría ser Shift-JIS. Si hubiera sido inventado por otra empresa, podría ser EBCDIC. Es realmente completamente arbitrario, y una opción tan importante no debería ser ser.

+0

Muy interesante, muchas gracias! –

+14

Unicode no es una codificación – tchrist

+3

@tchrist: Es una codificación en el sentido de que asigna un * número * único para cada carácter (que es más o menos la definición del diccionario de "codificación" "). No es una codificación en el sentido de que no asigna un * patrón de bits * único para cada personaje (en jerga Unicode, ese es el trabajo del formato de transferencia). Lamentablemente, nunca he podido aparecer con un buen nombre para lo que es Unicode, aparte de "codificación". –

0

En this answer a una pregunta diferente, una persona dijo que tenía problemas con Iconv cuando manejaba datos Unicode en Ruby 1.9, pero no puedo garantizar su precisión.

15

Agregando la siguiente línea en la parte superior mi archivo lo resolvió.

# encoding: utf-8 
+1

encima de qué ??? –

+0

En la parte superior del archivo de código fuente. – Kannaiyan

+0

Sí, justo después de la línea [http://en.wikipedia.org/wiki/Shebang_(Unix)]. –

5

Esta es una pregunta muy antigua. La versión estable actual de Ruby es 2.0.1. Sí, maneja más de lo que puede lanzar en Unicode, pero tenga en cuenta que se rompe con bastante facilidad.

Tome un vistazo a este ejemplo de código y los resultados (inspirado en this):

["noël","","baffle"].each do |str| 
    puts "Result for '#{str}'" 
    puts " Size: #{str.size}" 
    puts " Reverse: [#{str.reverse}]" 
    puts " Uppercase: [#{str.upcase}]" 
end 

Result for 'noël' 
    Size: 5 << bad size 
    Reverse: [l̈eon] <= accent is shifted 
    Uppercase: [NOËL] 
Result for '' 
    Size: 2 
    Reverse: [] 
    Uppercase: [] 
Result for 'baffle' 
    Size: 4 
    Reverse: [efflab] <= doesn't really make sense 
    Uppercase: [BAfflE] <= should be "ELFFAB" 

El punto es: Rubí moderna maneja los conceptos básicos - Características de la secuencia más avanzados no se deben contar.

+0

No recibí tu comentario. ¿Por qué 'e ffl ab' es lo contrario de' baff e' tiene sentido? ¿O por qué la mayúscula de 'ba ffl e' debe ser' ELFFAB'? – eis

+0

inversa de 'deflector' debe ser' elffab', no 'efflab' :-) – kralyk

+3

@kralyk @GregPK Parece que' baff e e 'se trata correctamente, teniendo en cuenta que ffl es un carácter único. Realmente tiene sentido. :) – ray

Cuestiones relacionadas