Mostrando y guardando acentos

Hola a todos.
Cuando quiero usar Ror para páginas en español tengo un par de
problemas:

  • Si en un fichero .rhtml pongo:

Hora: <%= @time %>

, me sale la hora junto con lo de "hora estandar romance", pero en vez de la "a" del estandar me sale un cuadradito, no el acento (estándar). He intentado poner diferente codificación con esto: ó Pero sigue sin solucionarse. Sugerencias?
  • Si inserto desde formularios algo con acentos, se guarda en la bdd y
    al mostrarse aparece bien. Sin embargo, en la bdd se ha guardado con
    caracteres raros. Esto no sería un problema (pues se visualiza bien en
    la aplicación), pero me gustaría saber cómo puedo solucionarlo por si en
    algún momento dado tengo que volcar la bdd (no me gustaría cambiar esos
    cartacters a mano) o cualquier cosa.

Gracias.

um…echando un vistazo a algunos posts he probado que ambos problemas
se resuelven poniendo en el controlador

before_filter :set_charset
def set_charset
@headers[“Content-Type”] = "text/html; charset=ISO-8859-1
end

Pero no entiendo por qué si pongo lo mismo directamente en la vista (en
la etiqueta meta), me lo ignora…
A parte de esto… no he tenido que modificar nada a la hora del envío
de los formularios.

On 2/10/07, Damaris F. [email protected] wrote:

ó

Primero, recomiendo la lectura de
http://www.joelonsoftware.com/articles/Unicode.html.

Y ahora explicaciones, si el servidor o la cabecera meta content-type
determinan un charset el navegador del usuario enviará lo que el
usuario haya introducido en los formularios con ese charset. Si tu
página se envía en utf-8 los formularios volverán en utf-8, si las
páginas las mandas en iso-8859-1 los formularios volverán en
iso-8859-1. Al almacenarse en la base de datos y volver a la página
aparecerán correctamente.

Cuando dices que en la base de datos lo ves con caracteres “raros”, a
pesar de que no dices que base de datos ni como lo ves, supongo que
has guardado los datos codificados en utf-8 y los intentas ver como
iso-8859-1, que como son diferentes codificaciones, ves diferentes
resultados. Si haces un backup, no tocas el archivo de backup, y lo
vuelves a cargar no debería hacer nada raro.

De cualquier forma las codificaciones de caracteres es una cosa
bastante “complicadilla” ya que hay que establecerla y comprobarla en
muchos sitios. Lo que se envia desde el servidor, los archivos del
disco duro, la comunicación con la base de datos, el locale del
sistema operativo, el formato de almacenamiento de la base de datos,
… Como siempre al ser algo hecho por estadounidenses nunca piensan
demasiado en los demás, que no utilizamos únicamente sus letras.

Sobre lo del “@date” apareciendo mal, no se de donde viene @date, pero
posiblemente el usuario con el que corre el interprete de Ruby esté
configurado con un locale diferente con el que envias los datos desde
el servidor, y por eso al usuario le aparecen caracteres “raros”.

Personalmente siempre intento guardar y transmitir los datos en UTF8
ya que es un formato que permite su utilización por el rango
másgrande de personas sin muchos problemas y sin ocupar demasiado,
mientras que con ISO-8859-1, si bien los idiomas del oeste europeo
funcionarán sin problemas, los idiomas de Europa del Este y de Asia no
funcionarán.

um…echando un vistazo a algunos posts he probado que ambos problemas
se resuelven poniendo en el controlador

before_filter :set_charset
def set_charset
@headers[“Content-Type”] = "text/html; charset=ISO-8859-1
end

En realidad eso te funciona bien hasta que metes llamadas ajax en tu
aplicación (si el ajax hace update de las vistas). Cuando hagas eso, el
type “text/html” entra en conflicto con el “text/javascript” que ajax
devuelve. Preguntando por xhr? se puede resolver.

Otra cosa a tener en cuenta es que tal cual funciona la implementación
de las llamadas remote con rails (y más en concreto el método serialize
de prototype.js) todo lo que envíes mediante ajax va a ir codificado en
utf-8, así que si no lo tienes en cuenta, cuando recibas parámetros
mediante llamadas “to_remote” vas a tener resultados inesperados porque
en principio deberían ir en el charset que tú indicas en la cabecera,
pero a la hora de la verdad no es así.

saludos,

javier ramírez

Um… no sé, no tendría problemas en tenerlo todo codificado en utf8,
pero si lo hago así, la base de datos (que también he probado a ponerla
en utf8), me sigue almacenando esos caracteres de forma extraña.Cuando
digo raros digo que en vez de “Camion” con acento en la “o”, me sale
algo asi como “CamieUan”, con esas vocales con dieresis, y es lo que
quiero resolver, y no sé qué encoding debo poner para ello.

javier ramirez wrote:

um…echando un vistazo a algunos posts he probado que ambos problemas
se resuelven poniendo en el controlador

before_filter :set_charset
def set_charset
@headers[“Content-Type”] = "text/html; charset=ISO-8859-1
end

En realidad eso te funciona bien hasta que metes llamadas ajax en tu
aplicación (si el ajax hace update de las vistas). Cuando hagas eso, el
type “text/html” entra en conflicto con el “text/javascript” que ajax
devuelve. Preguntando por xhr? se puede resolver.

Otra cosa a tener en cuenta es que tal cual funciona la implementación
de las llamadas remote con rails (y más en concreto el método serialize
de prototype.js) todo lo que envíes mediante ajax va a ir codificado en
utf-8, así que si no lo tienes en cuenta, cuando recibas parámetros
mediante llamadas “to_remote” vas a tener resultados inesperados porque
en principio deberían ir en el charset que tú indicas en la cabecera,
pero a la hora de la verdad no es así.

saludos,

javier ramírez

Y aparte de eso, tampoco sé por qué sí funciona ese método en el
controlador para establecer la cabecera, y no el ponerla “a pelo” en el
archivo .rhtml de las vistas…

Um… no sé, no tendría problemas en tenerlo todo codificado en utf8,

No tienes porqué tenerlo todo en utf8… pero si lo tienes, te vas a
ahorrar unas cuantas llamadas a iconv. Si usas otro encoding, los datos
que te vengan por ajax vas a tenerlos que convertir antes al encoding
deseado.

pero si lo hago así, la base de datos (que también he probado a ponerla en utf8), me sigue almacenando esos caracteres de forma extraña.Cuando digo raros digo que en vez de “Camion” con acento en la “o”, me sale algo asi como “CamieUan”

ya podría ser que la base de datos te lo esté almacenando bien y que tu
problema sea que el cliente que utilizas para ver los datos no te
permita ver el juego de caracteres en utf-8 (por ejemplo, si utilizas el
cliente de línea de comandos es fácil que te pase eso).

Para asegurarte de que todo se guarda y se muestra bien, el encoding
debería ser coherente en estos cinco puntos:
a)cabecera http
b)cabecera meta
c)conexión con la base de datos (en el database.yml)
c)definición de las tablas/instancia en la base de datos
e)encoding en el que están tus fuentes de la aplicación

Además, lógicamente, si lees de cualquier fuente externa deberías
asegurarte que todo se convierte al encoding deseado (en ruby lo puedes
hacer usando iconv). Y debes tener la precaución adicional que te
comentaba de las llamadas remotas con rails si tu encoding no es utf-8.

Para asegurarte de que todo va bien, ponle a todas tus páginas el
doctype al principio, y así evitarás que el browser utilice el modo
quirks (suponiendo que el html es correcto) y que utilice el encoding
que le indicas.

Un buen comienzo para una página web que use utf-8 podría ser:

//

Saludos,

javier ramirez

el copy/paste me traicionó antes y te puse la cabecera mal. Me falta
especificar el charset en el meta

Un buen comienzo para una página web que use utf-8 podría ser:

//<html xmlns=“http:‎//www.w3.org/1999/xhtml”" xml:lang=“en” lang=“en”>

En realidad debería decir

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

saludos,

j

bien… no es el copy/paste… es my thunderbird

<meta http-equiv="Content-Type" content="text/html; "/> 

entre text/html; y la comilla del final, me faltaría ponerle
“charset=utf-8”

Por algún motivo mi thunderbird se niega a enviarlo si lo pongo
directamente, y no quiero perder el tiempo en escaparlo por si tampoco
funciona… así que te lo dejo escrito en texto plano :wink:

Estamos de estreno… si necesitas llevar el control de tus gastos
visita http://www.gastosgem.com !!Es gratis!!

Je, no, lo habías puesto bien antes :smiley:
Ahora que dices lo de mi cliente… Pues tienes razón, yo tengo
instalado MySQL (server), y aunque mi base de datos está en utf-8, sí
que es cierto que cuando instalé el tema le puse “latin” por algún lado,
así que claro, se estará viendo como latin…

De los 5 pasos que me dices en el post previo, no entiendo el último, el
“e”.

Sobre la cabecedera de mis archivos, aunque ponga esa cabecera, me
seguía sin funcionar, tenía que poner el tema del encoding en el
controlador, no entiendo por qué.

Ah! Y muchas gracias por todas vuestras explicaciones, que no os he
dicho nada :S

De los 5 pasos que me dices en el post previo, no entiendo el último, el
“e”.

te decía que los fuentes de tu aplicación tienen que estar en el
encoding deseado también. Esto significa que tu código fuente, tus
ficheros .rb, tus .js, tus .rhtml… deberían tener el encoding que usas
para mostrar datos. Si no, cualquier literal que pongas directamente en
el fuente (mensajes de error, todo el código html…) se va a ver mal.

si tú tienes tu fichero .rhtml en ISO-8859-1 y tienes, por ejemplo, un
literal que dice “¿Guardar información entre diferentes visitas?” y
luego en tu vista le dices que lo muestre como utf-8… no se van a
mostrar correctamente caracteres como por ejemplo “¿”

Sobre la cabecedera de mis archivos, aunque ponga esa cabecera, me seguía sin funcionar, tenía que poner el tema del encoding en el controlador, no entiendo por qué.

Bueno… el mundo de los browsers y los estándars es como es. Yo por si
acaso lo pongo siempre en todos los sitios posibles, para asegurar.

saludos,

j


Estamos de estreno… si necesitas llevar el control de tus gastos
visita http://www.gastosgem.com !!Es gratis!!

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs