Decodificar entidades HTML

La forma obvia de resolver entidades es escribir el texto en un elemento y leer su `textContent`. Es también la forma en que la mitad de las herramientas de este género se abren un agujero: un `<img src=x onerror=...>` dentro del texto se convierte en un elemento real, y según el método eso provoca una petición de red o ejecuta código.

Aquí no pasa, porque no se genera HTML en ningún momento. Las referencias se resuelven contra una tabla y las numéricas se calculan: no hay punto alguno en el que tu texto se interprete como marcado. Por eso mismo esta página no puede ofrecer una vista previa — sería volver justo a lo que se está evitando.

Una referencia empieza por `&` y termina en `;`. En medio va un nombre como `amp` o `nbsp`, una almohadilla con un número decimal como `#241`, o una almohadilla con `x` y un hexadecimal como `#xF1`. Las dos últimas designan el mismo punto de código en dos bases.

En la práctica aparecen las tres en el mismo archivo, porque las han producido piezas distintas: los gestores de contenido tienden a las de nombre, las exportaciones a las decimales, las herramientas de XML a las hexadecimales. Aquí se tratan igual, así que no necesitas saber qué parte de tu cadena tenía cada preferencia.

Los navegadores son generosos: un `&amp` sin punto y coma lo resuelven igual en muchos contextos, porque las páginas antiguas lo escribían así y ganó la compatibilidad. Esa indulgencia está incluso recogida en el estándar de HTML, pero solo para una lista limitada de nombres y no dentro de valores de atributo.

Para ti significa que un `&amp` sin punto y coma en tus datos es una bomba de relojería, porque distintos procesadores lo tratan distinto. Esta herramienta exige el punto y coma y deja las referencias incompletas donde están: lo que queda visible es justo el sitio donde algo se generó mal.

Si en el resultado sigue habiendo un `&lt;`, la entrada estaba doblemente codificada: contenía `&amp;lt;`, y una pasada produce correctamente `&lt;`. No es un resultado a medias, es el correcto — un decodificador que siguiera hasta que nada pareciera una entidad destrozaría también el texto donde `&lt;` estaba escrito a propósito.

Lo limpio es volver a pasar el texto sabiendo que lo estás haciendo. Si te hacen falta dos pasadas de forma habitual, la tarea real es encontrar la doble codificación en la cadena que lo genera, no pulsar dos veces aquí.

Casi siempre de un valor que se guardó escapado y que el motor de plantillas volvió a escapar al mostrarlo. Las dos etapas son correctas por separado; lo incorrecto es que sean dos. Solo se ve en la página final, donde las usuarias leen `&nbsp;` como texto.

La segunda fuente son las importaciones y migraciones: los datos de un sistema antiguo llegan ya escapados y la rutina nueva los trata como si vinieran en crudo. También se reconoce por el `&amp;` delante de otros nombres de entidad — es la firma de dos capas superpuestas.

HTML5 define más de 2.200 referencias con nombre, desde `&amp;` y `&copy;` hasta símbolos matemáticos que casi nadie escribe. La lista está congelada a propósito: no se añaden nuevas, porque cada añadido cambiaría documentos que ya existen.

En la práctica: si un nombre no se resuelve aquí, o está mal escrito o nunca existió. Los caracteres nuevos ya no reciben nombre; para todo lo que Unicode ha añadido desde 2014 solo existe la forma numérica. Un `&emoji;` no ha existido nunca y no va a existir.

Los puntos de código por encima de `FFFF` — emoji, escrituras poco frecuentes, algunos símbolos matemáticos — necesitan internamente dos unidades en JavaScript, un par sustituto. Un decodificador que no lo tenga en cuenta produce dos medios caracteres rotos en lugar de uno completo.

A veces también aparecen referencias que escriben cada mitad del par por separado, porque una herramienta antigua codificó así. Esos valores son Unicode inválido en sentido estricto; aquí no se convierten en silencio a un carácter de sustitución, para que se vea que el problema está en el origen y no en la visualización.

Un `&nbsp;` se convierte en un carácter que parece un espacio y no lo es: tiene el punto de código `A0` en lugar de `20`. Por eso después falla una comparación, un buscar y reemplazar o un `trim()`, sin que en pantalla haya nada sospechoso.

Es el fallo más pesado de esta familia precisamente porque es invisible. Quien procese texto copiado de un gestor de contenidos o de un procesador de textos debe contar con ello: Word y la mayoría de los editores visuales ponen espacios duros con generosidad. Si dos valores «obviamente iguales» no se comparan como iguales, ese es el primer sitio donde mirar.

A este campo llega con frecuencia texto de terceros: un extracto de base de datos, un ticket de soporte, una entrada de un feed con nombres y direcciones dentro. Como la resolución ocurre en la página, nada de eso se nos comunica ni genera un encargo de tratamiento.

Conviene además recordar que el texto decodificado es, por definición, menos inofensivo que el escapado — el escape era la protección. Quien vaya a devolverlo a una página tiene que escaparlo otra vez para el sitio donde acabe; esta es una herramienta de lectura y no el último paso de una cadena que sirve HTML.