Validación me advierte sobre el BOM de utf-8

[metacortex]

Una web que hice pasa la prueba de validación, pero me advierte sobre el Byte-Order Mark generado por mi editor de textos. Intenté el "guardar como" a los archivos que edité para limpiarlos de esa codificación pero el validador aún sigue molestando con la advertencia ¿cómo puedo hacer para removerle ese orden de bytes a los archivos? ¿hay alguna forma de ejecutarlo con varios archivos simultáneamente?.

[Mikmoro]

Hola, Metacortex.

A mi me pasa todos los días con los archivos que codificamos en xml y UTF-8.
Yo lo elimino simplemente abriéndolos y grabándolos con XMLSpy. Si no dispones de este programa, creo que también puedes hacerlo con OpenOffice.

Mikel.

[metacortex]

Gracias Mikel, voy a probar lo que sugieres. Utilizaré Dreamweaver -ya vi que tiene la opción desactivada por defecto-. De verdad este problemita me tiene jodido. Aún no he visto caracteres extraños en los navegadores, pero es un trabajo para un cliente y me da coraje entregárselo así. Lo que sí había hecho era "guardar como" pero en el mismo servidor web. Esta vez lo haré desde local y vuelvo a subir los archivos.

Lo que me parece extraño es que es la primera vez que me sale esta advertencia. Siempre trabajo con EditPlus y todo bien. La diferencia es que en este caso estoy implementando un Wordpress al proyecto. Pero el problema no debería ser WP. Tampoco he subido plugins ni nada de terceros.

Algo sí me ocurrió en el proceso. Quizás el cuento sea un poco largo pero ahí va : Hace días tuve la necesidad de bajar la base de datos desde el servidor web hasta el local. En el local mesalieron los caracteres extraños y le di un ALTER TABLE para BINARY. Eso me arruinó la tarde porque -a pesar de que los caracteres se acomodaron- no podía efectuar ninguna búsqueda de texto en MySQL. Sin saberlo aún trabajé en local de esa manera, agregando más y más datos. A la hora de reemplazar los datos en remoto me di cuenta de la burrada.

Menos mal que tengo la costumbre de hacer un respaldo antes de eliminar cualquier cosa, por muy pequeña que ésta sea. Volví a restaurar la BD eliminando de cuajo la porquería binaria esa y grabando nuevamente tablas y datos, etc. ¿Será posible que ese pueda ser la causa problema? No sé, alguna instrucción que haya quedado guardada por ahí.

Si no me funciona lo de los archivos probaré creando una nueva base de datos, grabarla como es debido y subir el SQL limpio. En fin, hay trabajo por hacer. Gracias de nuevo .

[Mikmoro]

¡Más vale que eres precavido, si no, qué marrón!

Veamos. En este caso la cosa creo que es diferente. A mi me ocurre al validar archivos xml con una aplicación basada en Omnimark, que luego serán cargados en Documentum; sencillamente da el error de validación (por cierto, error que no indica y debes descubrirlo a güevo), y no validan.
Pero en tu caso estamos hablando de Wordpress, y sí es posible que tenga algo que ver. No por él mismo, sino por los archivos php. En la configuración por defecto de Apache creo que está establecido que sirva los archivos php como ISO-8859-1, y por eso a veces encuentra problemas al ejecutar php en UTF-8 con los malditos bites.

Dentro de las posibles soluciones está cambiar la configuración de Apache, y también la que hemos comentado, que es eliminar esos caracteres mediante alguna aplicación, que al parecer como dices DW puede hacerlo.

Es curioso, pero si como dices es la primera vez, quizá sea la primera vez que combinas php+UTF-8+EditPlus+(con BOM)+Apache.
Creo que la cosa puede venir por ahí.

Ya contarás.

Mikel.

[metacortex]

Es curioso, pero si como dices es la primera vez, quizá sea la primera vez que combinas php+UTF-8+EditPlus+(con BOM)+Apache.

Nopes. EditPlus es mi editor principal (por cierto ya deberían enviarme un cheque por la propaganda =P). Nunca me ha dado problemas de este tipo. Hasta lo he usado con pruebas de Wordpress. En un rato voy a hacer lo de los archivos y BD. Creo que la cosa va por éste último.

[Mikmoro]

Ah, pues entonces no sé.

Volví a restaurar la BD eliminando de cuajo la porquería binaria esa y grabando nuevamente tablas y datos, etc. ¿Será posible que ese pueda ser la causa problema? No sé, alguna instrucción que haya quedado guardada por ahí.

Pero si restauraste la BD por completo de la copia de respaldo, no debería haber quedado nada de lo que hiciste en local, y por lo tanto no debería dar ese error, ¿no?

¿Seguro que es de los datos que te arroja la BD, y no del propio PHP? Me suena extraño. Buen misterio para enredar (en mi caso, no en el tuyo, que tienes que entregar el trabajo )

Cuando puedas pasas un enlace con el problema para echar un vistazo.

Ya dirás si se arregla y te valida.

Mikel.

[metacortex]

Pero si restauraste la BD por completo de la copia de respaldo, no debería haber quedado nada de lo que hiciste en local, y por lo tanto no debería dar ese error, ¿no?

Imagino que quizás haya quedado alguna oscura y podrida secuela que va más allá de las tablas . No soy muy ducho en MySQL, así que pienso cortar por lo sano y crearme otra, aunque sea para ir descartando.

[Mikmoro]

¿Y cómo ha quedado el asunto?

Mikel.

[metacortex]

Pendiente de abordarlo esta madrugada. Estos días he estado adelantando en local y en un rato comienzo a tocar el tema de la BD para la transferencia a remoto (A ver cómo embiste ese toro). Gracias por estar pendiente amigo .

[feral]

De la ayuda del DW igual te puede valer los textos de abajo. A la hora de guardar un documento utf-8 la opcion del formulario C (Descomposicion de compatibilidad seguida por composicion canonica) suele ser la que arregla todos esos problemas con el dreamweaver. Simplemente con el nombre que tiene esa opcion se deben acojonar los bytes.

--------

Incluir firma Unicode (BOM) Permite incluir en el documento una marca de orden de bytes (BOM, en sus siglas en inglés). Una BOM está formada por entre 2 y 4 bytes situados al comienzo de un archivo de texto que identifican a un archivo como Unicode y, en este caso, el orden de los bytes siguientes. Dado que UTF‑8 carece de orden de bytes, la adición de una BOM UTF‑8 es opcional. Es obligatoria en el caso de UTF‑16 y UTF‑32.

--------

Formulario de normas Unicode Sólo está activado si selecciona UTF‑8 como codificación del documento. Existen cuatro formularios de normas Unicode. El más importante es el formulario de normalización C porque es el formulario más utilizado en el modelo de caracteres para la Web. Adobe ofrece los otros tres formularios de normas Unicode con el fin de proporcionar el conjunto completo.
En Unicode, algunos caracteres son visualmente iguales pero pueden almacenarse en el documento de diferentes formas. Por ejemplo, "ë" (e con diéresis) puede representarse como un carácter sencillo, "e con diéresis", o como dos caracteres, "la e latina normal" + "diéresis de combinación". Un carácter Unicode de combinación es aquél que se utiliza con el carácter anterior, por lo que la diéresis aparecerá sobre la "e latina". Ambas formas dan como resultado la misma tipografía visual, pero se almacenan en el archivo de forma diferente.

Normalización es el proceso mediante el cual se verifica que todos los caracteres que se pueden guardar de formas diferentes se guardan de la misma forma. Es decir, que todos los caracteres "ë" de un documento se guarden como "e con diéresis" sencilla o como "e" + "diéresis de combinación" y no ambas formas en un documento.