unidades - Problemas de codificación HTML-aparece el carácter "Â" en lugar de "& nbsp;"
encoding utf8 vb net (7)
Tengo una aplicación heredada que empieza a portarse mal, por alguna razón no estoy seguro. Genera un montón de HTML que se convierte en informes PDF por ActivePDF.
El proceso funciona así:
- Extraiga una plantilla HTML de un DB con tokens para reemplazarla (por ejemplo, "~ CompanyName ~", "~ CustomerName ~", etc.)
- Reemplaza los tokens con datos reales
- Ponga en orden el HTML con una función de expresión regular simple que la propiedad formatea los valores de atributo de la etiqueta HTML (asegura comillas, etc., ya que el motor de representación de ActivePDF detesta todo menos las comillas simples alrededor de los valores de los atributos)
- Envíe el HTML a un servicio web que crea el PDF.
En algún lugar de ese lío, los espacios sin interrupción de la plantilla HTML (los s) están codificando como ISO-8859-1 para que se muestren incorrectamente como un carácter "Â" cuando se visualiza el documento en un navegador (FireFox) . ActivePDF vomita estos caracteres que no son UTF8.
Mi pregunta: dado que no sé de dónde viene el problema y no tengo tiempo para investigarlo, ¿hay alguna manera fácil de volver a codificar o encontrar y reemplazar los caracteres incorrectos? Intenté enviarlo a través de esta pequeña función que armé , pero todo se convierte en un galimatías que no cambia nada.
Private Shared Function ConvertToUTF8(ByVal html As String) As String
Dim isoEncoding As Encoding = Encoding.GetEncoding("iso-8859-1")
Dim source As Byte() = isoEncoding.GetBytes(html)
Return Encoding.UTF8.GetString(Encoding.Convert(isoEncoding, Encoding.UTF8, source))
End Function
¿Algunas ideas?
EDITAR:
Me estoy saliendo con esto por ahora, aunque no parece una buena solución:
Private Shared Function ReplaceNonASCIIChars(ByVal html As String) As String
Return Regex.Replace(html, "[^/u0000-/u007F]", " ")
End Function
En algún lugar de ese lío, los espacios sin interrupción de la plantilla HTML (la s) están codificando como ISO-8859-1 para que se muestren incorrectamente como un carácter "Â"
Eso estaría codificando para UTF-8 entonces, no ISO-8859-1. El carácter de espacio sin interrupción es byte 0xA0 en ISO-8859-1; cuando está codificado en UTF-8 sería 0xC2, 0xA0, que, si (incorrectamente) lo ve como ISO-8859-1 sale como "Â " . Eso incluye un nbsp final que puede no estar notando; si ese byte no está allí, entonces algo más ha perjudicado su documento y necesitamos ver más arriba para descubrir qué.
¿Cuál es la expresión regular? ¿Cómo funciona la creación de plantillas? Parecería que hay un analizador HTML apropiado involucrado en alguna parte si su las cadenas se convierten (correctamente) en U + 00A0 caracteres que NO ROMPEN el espacio. De ser así, podría simplemente procesar su plantilla de forma nativa en el DOM, y pedirle que serialice utilizando la codificación ASCII para mantener caracteres no ASCII como referencias de caracteres. Eso también evitaría que tuviera que hacer el procesamiento posterior de expresiones regulares en el propio HTML, que siempre es un negocio altamente peligroso.
Bueno, de todos modos, por ahora puede agregar uno de los siguientes al <head> su documento y ver si eso lo hace parecer bien en el navegador:
- para HTML4:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> - para HTML5:
<meta charset="utf-8">
Si lo has hecho, entonces cualquier problema restante es culpa de ActivePDF.
Bueno, tengo este Issue también en mis pocos sitios web y todo lo que tengo que hacer es personalizar el recopilador de contenido para las entidades HTML. antes de eso, más los eliminé más, así que simplemente cambié tu html fiter o función de análisis para la página y funcionó. Se debe principalmente a los editores de HTML en la mayoría de los CMS. la forma en que almacenan analizar los datos causó este problema (en mi caso). Que esto ayudaría en tu caso también
En mi caso, obtuve el signo de la cruz latina en lugar de nbsp, incluso si una página estaba codificada correctamente en el UTF-8. Nada de lo anterior ayudó a resolver el problema y lo intenté todo.
Al final, cambiar la fuente para IE (con css específicos del navegador) me ayudó, estaba usando Helvetica-Nue como una fuente de cuerpo cambiando a Arial que resolvió el problema.
Estaba teniendo el mismo tipo de problema. Aparentemente es simplemente porque PHP no reconoce utf-8.
Me estaba arrancando el pelo al principio cuando un signo ''£'' seguía apareciendo como ''Â £'', a pesar de que estaba bien en DreamWeaver. Eventualmente, recordé que había tenido problemas con los enlaces relativos al archivo de índice, cuando las páginas, si se veían directamente, funcionarían con presentaciones de diapositivas, pero no cuando se utilizaba con una función de inclusión (pero eso está al margen. De todos modos, me preguntaba si esto podría ser problema similar, así que en lugar de ponerlo en la página con la que estaba teniendo problemas, simplemente lo puse en el archivo index.php - problema reparado.
La razón de esto es que PHP no reconoce utf-8.
Aquí puedes consultar todos los caracteres especiales en HTML
Si alguien tenía el mismo problema que yo y el juego de caracteres ya era correcto, simplemente haz esto:
- Copie todo el código dentro del archivo .html.
- Abra el bloc de notas (o cualquier editor de texto básico) y pegue el código.
- Vaya a "Archivo -> Guardar como"
- Ingrese su nombre de archivo "example.html" (Seleccione "Guardar como tipo: Todos los archivos ( . )")
- Seleccione Codificación como UTF-8
- Presione Guardar y ahora puede eliminar su antiguo archivo .html y la codificación debe ser reparada
Problema: Incluso yo estaba enfrentando el problema en el que estábamos enviando ''£'' con una cadena en la solicitud POST al Sistema CRM, pero cuando estábamos haciendo la llamada GET desde CRM, devolvía ''£ £'' con un poco de contenido de cadena. Entonces, lo que hemos analizado es que ''£'' se estaba convirtiendo en ''Â £'' .
Análisis: El error que hemos encontrado después de investigar es que en la llamada POST hemos configurado HttpWebRequest ContentType como "text / xml" mientras que en GET Call era "text / xml; charset: utf-8" .
Solución: Entonces, como parte de la solución, hemos incluido el juego de caracteres: utf-8 en la solicitud POST y funciona.