Foros del Web » Programación para mayores de 30 ;) » Bases de Datos General » Mysql »

Otra de problemas con caracteres especiales

Estas en el tema de Otra de problemas con caracteres especiales en el foro de Mysql en Foros del Web. No sé muy bien en qué subforo plantear este problema, así que empiezo por aquí y si alguien me recomienda postear en otro lado, así ...
  #1 (permalink)  
Antiguo 21/07/2009, 07:35
 
Fecha de Ingreso: septiembre-2007
Mensajes: 99
Antigüedad: 16 años, 7 meses
Puntos: 0
Otra de problemas con caracteres especiales

No sé muy bien en qué subforo plantear este problema, así que empiezo por aquí y si alguien me recomienda postear en otro lado, así lo haré.

El tema es que tengo un enredo curioso con el tema del charset en la web. Lo primero es decir que la web está servida desde un IIS 6 en Windows 2003, y que la codificación de la mayor parte de ella es ISO-8859-1. Por ahí, todo perfecto. Las Mysql asociadas a estas páginas está en charset Latin1, collate Latin1-swedish.ci, lo típico.

El problema viene con un blog wordpress que he metido dentro de la web, como un apartado más, y he puesto en utf8. La Mysql asociada con él está en charset utf8, collate utf8_spanish2_ci. Pues bien, todos los caracteres especiales que llegan desde la Mysql son mostrados por los navegadores correctamente (por supuesto el charset declarado de todas las páginas es utf8), pero los que escribo a mano en las páginas no. Tengo que usar codificación html para ellos. Si subo páginas de prueba al servidor (uso para ello DW) sin los caracteres especiales codificados, en puro estilo utf8, los navegadores las leen perfecto. Pero si mezclo en las páginas datos llegados desde la Mysql y escritos directamente, estos últimos los tengo que codificar.

Me he fijado en la base de datos cómo está guardando los caracteres y los guarda codificados. No en la codificación habitual 'á', sino con símbolos muy raros.

En fin, para resumir, lo que ocurre es esto:

-La Mysql está guardando codificados los caracteres especiales que le llegan desde el wordpress, estando todo, el blog y la base, perfectamente seteado a utf8.
-Las páginas subidas en utf8 que no importan datos desde la BD se leen sin problemas sin codificar ni tildes ni eñes.
-Las páginas que mezclan caracteres especiales escritos a mano con los llegados desde la BD, precisan codificar los primeros.
-El código fuente de los datos procedentes desde la BD que muestran los navegadores carece de caracteres codificados. Aunque estén en la BD codificados, el código fuente los escupe sin codificar, o sea, á, ñ, etc. Son mostrados al público correctamente.
-Sin embargo, si no codifico los otros caracteres, los que están metidos a mano, en las páginas, el texto que llega desde la BD se ve, en vista de código fuente, con los caracteres especiales codificados, exactamente como se ven guardados en la BD. Los navegadores sin embargo los muestran al público también en este caso correctamente.

Perdón por el tostón y espero que se comprenda lo que quiero decir.
Gracias por alguna luz que me ayude a resolver este galimatías...

Última edición por vega22; 21/07/2009 a las 07:41
  #2 (permalink)  
Antiguo 21/07/2009, 07:46
 
Fecha de Ingreso: septiembre-2007
Mensajes: 99
Antigüedad: 16 años, 7 meses
Puntos: 0
Respuesta: Otra de problemas con caracteres especiales

Mmmmm... Me parece que me voy a responder yo mismo. Por un tutorial que acabo de leer, me parece que lo que ocurre es todo normal y que así pasa cuando mezclas en utf8 caracteres estáticos ('escritos a mano') con caracteres dinámicos llegados desde la BD (que no me está guardando los caracteres especiales con 'símbolos raros', sino con su correspondiente notación utf8 para BD)

A ver si alguien me lo confirma (o no)
  #3 (permalink)  
Antiguo 21/07/2009, 16:13
 
Fecha de Ingreso: septiembre-2007
Mensajes: 99
Antigüedad: 16 años, 7 meses
Puntos: 0
Respuesta: Otra de problemas con caracteres especiales

Ahora sí. Lo arreglé forzando el salvado de las páginas del theme en utf-8. De alguna manera la codificación utf-8 que traen se pierde al trabajar con DW en un windows server, y de ahí todo el cacao.

Listo papeles.
  #4 (permalink)  
Antiguo 22/07/2009, 02:57
Avatar de Fierce  
Fecha de Ingreso: marzo-2008
Mensajes: 216
Antigüedad: 16 años, 1 mes
Puntos: 3
Respuesta: Otra de problemas con caracteres especiales

yo la verdad me canse de esos pinches caracteres y como no encontraba nunca la solucion cree un adgoritmo que los cambiara en todas las tablas de la Mysql
  #5 (permalink)  
Antiguo 22/07/2009, 04:22
 
Fecha de Ingreso: septiembre-2007
Mensajes: 99
Antigüedad: 16 años, 7 meses
Puntos: 0
Respuesta: Otra de problemas con caracteres especiales

Yéndome a lo más general, el principal problema que tenemos con los caracteres especiales es que en el desarrollo web la referencia son los anglosajones, y como este tema les importa a ellos un pito, los hispanos estamos con esto solos ante el peligro y bastante despistados.

Yo llevo desde ayer buscando un programa decente que haga las conversiones de archivos por batchs y aún no he encontrado ninguno. Si fuera un tema de interés vital para los yanquis estaría el mercado a rebosar de software para esto, como lo está para cualquier cosa.

De los molestos caracteres en la Mysql no me preocuparía mucho porque cuando están las páginas bien codificadas en utf-8 los navegadores muestran esos caracteres en el código fuente correctamente: las tildes como tildes, las eñes como eñes, etc.

A mi ahora me funciona todo bien pero no dejo de pensar en un problema que se me puede dar mañana mismo: las páginas dinámicas que no tienen caracteres especiales estáticos en ellas no se pueden codificar a utf-8. Al menos DW me las deja en ASCII. Pero ¿qué ocurre si les llega texto dinámico con caracteres especiales que por alguna razón no ha sido convertido a utf-8? Pues que según el navegador, se armará un lío pequeño o grande...
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 10:13.