Codificación de caracteres en JS

Trabajo en MongoDB en el equipo de Herramientas para Desarrolladores, así que la Shell y la GUI y la extensión de VSCode para la base de datos, pero esta charla no tiene absolutamente nada que ver con eso. Así que vamos a empezar.

Hace aproximadamente un mes vi este tweet que se hizo bastante popular en Twitter y ya sabes... Algunas personas se ríen, entienden el chiste. Obviamente, la forma más fácil de obtener la longitud de una cadena de texto en JavaScript es hacer un spread de objeto en ella, luego llamar a object.keyson.object y luego usar el método reduce del prototipo de array para sumar la longitud de ese array. Todos sabemos cuál es el chiste. Pero retrocedamos un poco.

¿Por qué las codificaciones de caracteres a veces son algo de lo que nos preocupamos o con lo que tenemos que lidiar? La situación típica en la que te encuentras es que eres un desarrollador de software y estás escribiendo software. Estás escribiendo un programa. Ese programa no existe de forma aislada. Hay algo más ahí fuera, literalmente cualquier cosa excepto tu programa, como el sistema de archivos, la red, otros programas, otros ordenadores, cualquier cosa así. Y obviamente quieres que tu software pueda comunicarse con ellos. La forma predeterminada de comunicar cualquier cosa es usar cadenas de texto. Puedes poner básicamente cualquier cosa en una cadena de texto. Cualquier dato que tengas puedes serializarlo en una cadena de texto. Así que sería bueno si pudiéramos hablar con estos otros programas usando cadenas de texto. Desafortunadamente, no funciona así.

Tu programa normalmente se ejecuta en un sistema operativo que no tiene idea de lo que es una cadena de texto. Si es un programa de Javascript, que será el caso para muchos de ustedes, una cadena de texto de Javascript es algo que el motor de Javascript entiende, pero tu sistema operativo no tiene idea de qué hacer con eso. No puedes pasarlo directamente a eso. Eso también significa que no puedes pasarlo a otras cosas. Entonces, la solución que la gente ideó es, tienes tu cadena de texto, y para cada carácter en esa cadena de texto le asignas a ese carácter un número, y luego ideas una forma ingeniosa de asignar o convertir esos números en una secuencia de bytes. Y esto parece una discusión muy básica, pero creo que es importante tener esa distinción en mente.

Cuando digo cadenas de texto, me refiero a secuencias de caracteres, como texto. Esta representación intermedia, que en su mayoría no te importa, la voy a llamar puntos de código, porque ese es el lenguaje que Unicode usa para esto, y luego tu salida es una secuencia de bytes. Obviamente, al decodificar se realizan estos pasos en sentido inverso. Si te llevas algo de esta charla, es que las cadenas de texto y las secuencias de bytes son cosas diferentes. Históricamente, la forma en que las personas han abordado esto, en los años 70 cuando los estadounidenses aún no habían descubierto que hay algo más que América en el mundo, se ideó una forma de asignar, una forma estándar de asignar números a los caracteres, y esos eran caracteres del 1 al 128, y eso es suficiente espacio para los alfabetos inglés en minúsculas y mayúsculas y algunos caracteres especiales y, ya sabes, ¿quién necesita más que eso? Luego vino la siguiente iteración, que es un poco más popular alrededor de los años 90, ya sabes, descubres que hay otros idiomas además del inglés, y dices, bueno, ASCII son 128 caracteres, así que 7 bits, los bytes suelen tener 8 bits, así que tenemos otros 128 caracteres disponibles. Y la solución que la gente ideó fue, ya sabes, probablemente vas a tener texto griego, o texto eslavo, o texto árabe, no vas a mezclar estos probablemente. Así que, para cada uno de estos, creas una codificación de caracteres.

Estas codificaciones de caracteres ISO-8859 son como 16 codificaciones de caracteres diferentes cada uno de los caracteres adicionales que no son ASCII tiene un significado adicional. Pero no puedes mezclar, como no puedes tener una secuencia de un solo byte que pueda representar tanto, digamos, texto griego como árabe, y a veces puedes querer eso. Entonces, algo que se hizo popular hacia finales de los años 90 es Unicode.

Y así, Unicode resuelve ese problema diciendo, sí, no nos vamos a ceñir a codificaciones de un solo byte, simplemente vamos a tener tantos puntos de código como queramos. Hay una limitación, alrededor de un millón de puntos de código actualmente, pero eso es, quiero decir, actualmente no estamos cerca de alcanzar eso. No creo que vayamos a tener tantos emojis, así que creo que está bien. Lo que a veces es relevante para JavaScript es que los primeros 265 puntos de código coinciden con una de estas codificaciones anteriores, específicamente ISO-8859-1, eso no significa por sí mismo que sea compatible con ASCII, porque eso solo son los puntos de código, no la transformación real a secuencias de bytes. Pero luego tienes múltiples codificaciones para hacer eso, y la que todos conocemos y usamos todos los días es UTF-8, y esta es compatible con ASCII porque, ya sabes, los primeros 127 bytes coinciden exactamente con ASCII, y utiliza todos los otros bytes para, ya sabes, representar otros caracteres que no encajan en ese rango.

Y luego está UTF-16, que a las personas de JavaScript también les puede importar de vez en cuando, donde la idea es más cercana a, ya sabes, dos bytes por carácter. Esto tenía mucho sentido cuando se introdujo Unicode porque en ese momento, ya sabes, nadie esperaba que hubiera más de 65,000 caracteres de los que preocuparse. Entonces, ya sabes, dos bytes era una elección muy natural para eso. Pero con cosas como los emojis que se introducen, vamos a, hemos salido de ese rango. Entonces algunas cosas tienen que ser representadas por pares de dos bytes, por lo que cuatro bytes en total. Así que a veces la gente dice que JavaScript usa UTF-16, y bueno, puede haber algo de verdad en eso. Aquí tengo la salida de la utilidad de línea de comandos Unicode. Si nunca has usado eso, es una herramienta muy útil para obtener información sobre caracteres individuales o buscar caracteres según sus puntos de código, todas esas cosas. Sin embargo, lo escribí, estoy muy agradecido. Aquí hay un ejemplo de cómo se ve esto en UTF-16. Lo he resaltado. Y luego, ¿qué sucede cuando usas Node para imprimir la longitud de una cadena que solo contiene este único carácter de cara de hámster? Dice dos, aunque es un solo carácter. Y luego puedes profundizar y ver que, este único carácter se compara igual a una cadena compuesta por dos secuencias de escape. Y estas secuencias de escape coinciden exactamente con cómo se serializa UTF-16. Y así podrías decir, bueno, JavaScript usa UTF-16. Ya terminé. La realidad es que UTF-16 es una codificación de caracteres. Es una forma de transformar secuencias de caracteres en secuencias de bytes. No hay secuencia de bytes aquí. Esto no es un asunto de codificación. Simplemente sucede que tiene algunas similitudes. Entonces, de alguna manera, JavaScript te permite interactuar con cadenas como si estuvieran almacenadas utilizando UTF-16.

A veces pueden hacerlo. Pero también los motores de JavaScript pueden utilizar el almacenamiento que deseen. Y, hablando prácticamente, no siempre van a utilizar UTF-16 porque si tienes texto que solo contiene caracteres ASCII, no necesitas eso. Si tienes texto que solo contiene caracteres ASCII, estás desperdiciando la mitad de los bytes en tu almacenamiento. Y los motores de JavaScript están diseñados para ser muy eficientes porque a la gente le importa eso.

Entonces, una cosa que hicimos, y esta es la única referencia de trabajo de MongoDB que tengo aquí. Así que tuvimos un proyecto el año pasado para mejorar el rendimiento de inicio de una de nuestras herramientas que mantenemos. Así que enviamos esta herramienta básicamente uniendo node con un paquete Webpack de nuestro código de CLI. Suena bastante fácil, ¿verdad? Y así, Webpack tiene esta bandera para emitir una salida solo en ASCII desde su minificador. Lo hace reemplazando los caracteres no ASCII con secuencias de escape. Y así, cuando hicimos eso, el paquete de Webpack se volvió un poco más grande, y eso es de esperar. Las secuencias de escape son más largas que los caracteres que representan. Pero el ejecutable general que enviamos se redujo un 15%. Y eso es porque no pudimos, ya no necesitábamos iniciar data como UTF-16. Simplemente pudimos pasarla al motor de JavaScript como data ASCII. Eso en realidad aceleró las cosas en un 3.5%, lo cual fue una victoria bastante buena con un solo cambio de línea. Entonces sí, por ejemplo, V8 puede utilizar latin1 o UTF-16 como backend para cadenas de JavaScript. Creo que JS Core puede utilizar UTF-8 como backend. No puedes ver eso. No puedes interactuar con el almacenamiento subyacente de las cadenas. Así que, no utiliza UTF-16.

Bien, volvamos al ejemplo del principio de esa diapositiva de Twitter. Obviamente esto es lo que usarías para obtener la longitud de una cadena, pero ya sabes, obviamente esto es correcto de alguna manera y no es correcto de otras maneras, porque este es un solo carácter y no debería tener una longitud de dos, o tal vez sí. Afortunadamente, JavaScript es consciente de que estas cosas suceden, y así cuando usas algo que utiliza el protocolo iterable de JavaScript, como for off o erase, puedes obtener la respuesta correcta, cuando respuesta correcta significa que realmente te importa el número de caracteres Unicode. Si haces esto, probablemente dirás, bueno, ¿no es esto terriblemente ineficiente, crear un array temporal solo para obtener la longitud de una cadena, y la respuesta es obviamente sí. Puedes mejorar eso un poco utilizando un bucle y sin asignar un array, pero aún así, esto es varias órdenes de magnitud más lento que simplemente usar .length. ¿Y cuál es la historia aquí? Quiero decir, simplemente tendrás que elegir uno de estos y pensar por qué quieres la longitud de una cadena y por qué eso importa, y tendrás que vivir con el hecho de que no hay una forma rápida de obtener el número de caracteres de una cadena en JavaScript. Una cosa que quería mencionar. Realmente piensa por qué quieres obtener la longitud de una cadena, como qué quieres hacer con eso. Porque te importa, por ejemplo, el número de caracteres que ocupa algo al imprimirlo en la Terminal porque quieres alinear las pestañas o algo así. En ese caso, hay un paquete de npm disponible.

Hace muchas cosas que nunca pensarías porque algunos caracteres son invisibles por lo que no ocupan ningún espacio en absoluto, todas esas cosas. Siempre hay un paquete npm para lo que realmente necesitas.

Muy bien, volvamos a lo básico aquí. Lo que queremos hacer, y lo que queremos hacer en JavaScript, es convertir cadenas en secuencias de bytes. Si estás acostumbrado a Node.js, podrías decir, solo estoy usando Buffer, así es como hago las cosas. Está bien, pero no me importa eso porque en mi opinión, Buffer es una API muy antigua en Node. Hay reemplazos estándar de API web para muchas cosas en la API de Buffer, y por eso no hay una razón real para seguir usándola.

La codificación de cosas es bastante fácil. Puedes crear instancias de codificador de texto, que solo permiten UTF-8. Eso es una limitación hasta cierto punto, pero también en su mayor parte, no quieres usar nada más, así que lo suficientemente fácil. Luego, para la decodificación. Las cosas se complican un poco. Si paso la matriz UN8 que acabo de obtener como salida del paso anterior, la decodifica de nuevo, funciona perfectamente, pero la API tiene algunas opciones de configuración interesantes que quizás quieras conocer. En primer lugar, TextDecoder realmente entiende múltiples codificaciones de caracteres. En su mayor parte, no te importará eso, pero lo hace, y eso puede ser útil a veces.

Hay una opción booleana fatal al crear uno. La semántica de eso es que estás decodificando data, y esa data puede ser o no válida. Y tienes que manejar los errores de alguna manera. Tienes que pensar en lo que haces. Aquí se presentan dos opciones bastante estándar. Una es hacer fallos fatales, lo que significa que solo tienes en cuenta los caracteres de reemplazo como el que está en la diapositiva de título de la charla que desafortunadamente no se incluyó en el programa porque alguien pensó que era un error de codificación. Creo que eso es bastante divertido. Si usas fatal true, los errores de codificación realmente resultarán en una excepción cuando llames a decode. A veces eso es lo que quieres porque realmente quieres una entrada válida y no quieres aceptar el hecho de que estás, bueno, perdiendo data porque podría estar corrupta. Y luego está la bandera de transmisión verdadera, que se explica mejor con un ejemplo. Así que espero que sea lo suficientemente grande en la pantalla. Tienes dos fragmentos de data que lógicamente provienen de la misma fuente y quieres decodificarlos desde UTF-8. Y lo que sucede es que no puedes porque este resulta ser un carácter que está dividido en dos fragmentos. Eso sucede a veces, por ejemplo, cuando estás haciendo E/S de red, es posible que no obtengas fragmentos de data de la red que estén perfectamente alineados con tus caracteres porque es solo un flujo de bytes, TCP no se preocupa por dónde están los límites de tus fragmentos. Simplemente te da bytes a medida que llegan.

Y ahí es donde entra en juego esta bandera. La pasas en cada llamada excepto en la última si estás decodificando un flujo de datos y la instancia del decodificador de texto recuerda qué caracteres parciales ya ha visto. Así que tiene una ventana de cuáles son los últimos bytes que vi, y simplemente es inteligente y recuerda lo que ya le has pasado.

Y esto es una de mis grandes frustraciones. La gente se equivoca todo el tiempo en Node. Y entiendo por qué. Esto es de la documentación oficial de Node.js. Y hay un error allí, muy similar a lo que acabo de describir, que es que, sabes, tienes este patrón común donde defines datos como una cadena. Y luego tienes una pantalla, y adjuntas un listener onData. Y ese listener, agrega el fragmento a esa cadena de datos. Y lo que hace en el fondo es que hay muchos detalles implícitos aquí. Agregar algo a una cadena lo convierte en una cadena. En este caso, el fragmento es un búfer de Node.js. Llamar a toString en un búfer de Node.js lo transforma, lo decodifica de forma predeterminada desde UTF-8. Todo esto sucede implícitamente aquí. Pero sufre del problema que acabo de describir, donde los fragmentos pueden no estar alineados correctamente con los límites de los caracteres.

Afortunadamente, esto es algo bastante fácil de solucionar. Así que vamos a la documentación de Node.js y abrimos una solicitud de extracción. Es una solución bastante sencilla de una línea. Las transmisiones de Node.js tienen la propiedad setEncoding donde puedes indicarle que, sabes, decodifique los datos entrantes utilizando esta codificación. Y luego hará exactamente lo mismo que acabo de describir usando TextDecoder, donde recuerda qué caracteres ya ha visto. Y eso es una solicitud de extracción en vivo. Muy bien. Y utiliza lo mismo en el fondo en Node.js, de hecho, como TextDecoder y esta propiedad setEncoding.

Otro error en Node.js del que quería hablar y que a veces se ve por ahí y siempre me hace querer decir, vamos. Alguien escribió una función hash aquí. Y simplemente hace un módulo 256 de una cadena. Toma la cadena como argumento, devuelve la cadena como una cadena hexadecimal como su salida. Y lo hace creando un objeto hash de la API de criptografía, llama a update con una cadena, lo interpreta como datos binarios y luego llama a just para obtener el resultado en hexadecimal. Y obviamente, eso puede no parecer tan malo a simple vista.

Lo que realmente puede suceder es que puedes pasar diferentes cadenas a esta función hash y obtener el mismo resultado. Y eso es malo. Eso es exactamente lo contrario de para qué se utilizan las funciones hash. Entonces, ¿qué sucede aquí? Binario es en realidad un alias heredado para ISO 88591 en Node.js. Esto es así porque hace mucho, mucho tiempo, antes de que existieran UN8Array y los búferes en JavaScript, aún querías lidiar con los datos binarios a veces. Y una forma de hacerlo era usar cadenas y fingir que, tus primeros 256 bytes corresponden a tus primeros 256 puntos de código Unicode, que resulta ser ISO 8591. Y eso se llamaba una cadena binaria. No he escuchado que se use ese término en uso del mundo real en 20 años o algo así. Pero sí, por eso está ese alias. A veces, las personas aún pasan binario a las API de Node.js porque piensan que le indica a Node que interprete algo como datos binarios o lo que sea. No hace eso. Casi siempre es un error cuando pasas binario como una cadena a la API de Node.js y especialmente con las API de criptografía, piensa en lo que sucede. Como eso. Siempre trabajan en secuencias de bytes. Así es como están diseñadas todas las cosas de criptografía. Entonces, si simplemente envías ese parámetro, en realidad hace lo correcto. Utiliza UTF-8 de forma predeterminada.

Así que llegamos al final de mi charla. Algunas cosas a tener en cuenta, como si estás utilizando codificaciones por debajo o no, o si lo sabes o no. A veces hemos construido algunas extracciones para que funcione de la manera más fluida posible, pero eso no significa que puedas olvidarte de ello. Aún es algo cuando conviertes entre secuencias de bytes y secuencias de caracteres. Tienes que pensarlo. Una lección que no es tan sorprendente, pero ¿por qué es tan popular UTF-8? Es porque es compatible con ASCII. Esa es la razón. Así que siempre es algo a tener en cuenta cuando estás construyendo algo nuevo, si es compatible con los grandes actores existentes, entonces esa es la mejor manera de que tu trabajo sea adoptado. Voy a omitir eso porque se me está acabando el tiempo. Pero no asumas que JavaScript está utilizando UTF-16. Puede que no lo esté haciendo. No sabes qué sucede bajo el capó. Pero tampoco finjas que no lo hace porque a veces actúa como si lo hiciera. Y finalmente, no copies simplemente código de la documentación, podría estar equivocado.

Muy bien, ese fui yo. Gracias Ana por esta gran charla. Ahora tenemos una pregunta, pero por favor hagan más preguntas. Entonces la pregunta es, volviendo a la pregunta de moda, ¿cuál es la mejor manera de encontrar la longitud de una cadena en JS? Bueno, la mejor manera es primero pensar, ¿qué significa la longitud de una cadena para ti? Por ejemplo, si te importa el número de caracteres individuales, ¿por qué te importa eso? Si te importa el número de elementos de cadena de JavaScript, que son como unidades de código UTF16, ¿por qué te importa eso? O si usas el ancho de la cadena, ¿por qué quieres el ancho de una cadena cuando la imprimes en la terminal? Diferentes semánticas, diferentes respuestas. Genial. Buena pregunta.

Entonces la segunda pregunta es, si .length devuelve la longitud real de un carácter múltiple, ¿cómo se comporta cuando se usa en un bucle for tradicional con notación de indexación de matriz? Si entiendo bien la pregunta, es complicado. Porque vas a tener situaciones donde, ya sabes, si tienes un carácter que se divide en dos. Ya sabes, pares sustitutos es como se les llama en UTF 16. Entonces, si iteras sobre una cadena utilizando el bucle estándar, ya sabes, for con un índice, vas a ver que estas dos cosas aparecen por separado. No incluí esto en mi charla, pero es algo en lo que generalmente debes pensar. Como, um, eso puede suceder. Si quieres saber cómo manejar eso bien, hay, um, puede que sepas que hay una API de código de carácter de JavaScript en las cadenas. También hay algo llamado Code Point At. Y hay una diferencia sutil para estos caracteres múltiples donde, donde Code Point At realmente te da el punto de código Unicode completo, uh, de este carácter y el siguiente juntos en ese caso. Um, esa es una buena manera de manejar eso si te encuentras con esa situación. Pero, um, sí. Bien.

La siguiente pregunta es, el ejemplo de colisión es increíble. ¿Puedes explicar qué sucede desde un punto de vista técnico? ¿A x L tienen la misma representación de bytes? Puedo dar la vuelta y hacer la pregunta? Uh, sí, no, eso es correcto. Entonces, um, lo que sucede es que A es como, uh, 65 en ASCII, como A mayúscula. Y la L mayúscula polaca que uso es 65 más 256. Uh, entonces lo que sucede es que cuando le dices a Node.js que use ISO-88591 para convertir estos dos bytes, um, ese segundo carácter no se puede representar utilizando esa codificación de caracteres. Y Node.js no lanza un error ni nada. Simplemente trunca silenciosamente el punto de código para ese carácter. Y como truncar significa truncar a un solo byte, um, lo que obtienes es como, ya sabes, más 256 desaparece y obtienes el mismo valor para ese byte. Um, es cierto que los motores de JavaScript realmente usan, como, uh, nunca sé cómo pronunciar eso. Pero sí. Yo tampoco lo sé. ASCII en la backend la mayor parte del tiempo.

Luego se convierten automáticamente tan pronto como uses el carácter fuera de ASCII. Sí, claro. Obviamente, los motores de JavaScript hacen el trabajo de verificar si pueden representar los caracteres en su entrada en la codificación con la que desean comenzar. Nuevamente, los motores de JavaScript son muy, muy inteligentes en este tipo de cosas. Entonces, como, hay una gran representación interna de Spring. Estoy más familiarizado con V8, porque soy una persona de Node, diferentes motores pueden hacer cosas diferentes. Pero, por ejemplo, en V8, puedes encontrarte con situaciones donde, por ejemplo, tienes una cadena y la creaste concatenando otras dos cadenas. Y en realidad comienza como una representación concatenada de estas dos cadenas. Y una de ellas puede ser ASCII y la otra no ASCII. Sí, pero no intentes engañar al motor. Ese siempre es un buen consejo para Javascript.

Buen consejo. Entonces, ¿qué opinas de WTF8? Um, okay. Voy a asumir que no todos aquí están familiarizados con eso. Si quieres saber qué es, búscalo. Creo que, típicamente, quieres WTF8 estándar, y quieres la validación estándar que, por ejemplo, un decodificador de texto te proporciona. Y simplemente quédate con eso porque es lo más estandarizado que puedes obtener. Obviamente, es una variante de WTF8 que maneja estos puntos de código fuera del rango de 65,000 de manera un poco diferente. No mejor, sino diferente. Y no sé. Hay casos de uso para ello, pero si no tienes una buena razón para usarlo, entonces no lo hagas.

¿Y cuál es el formato de codificación más recomendado en este momento? WTF8. Eso es muy simple. Lo siento. No, sí. Hay una buena razón por la cual es la codificación predeterminada para, como, básicamente todas las API de JavaScript que existen. Genial.

Um, ¿cuál es la forma más segura de truncar una cadena después de 15 caracteres, agregando ...al final? Sí, la forma más segura también es la más laboriosa de hacer esto, supongo. Lo que haría, lo que he hecho en el pasado cuando me he encontrado con este problema, es usar la API CodePointAdd que mencioné en una pregunta anterior para verificar si el carácter 14, en ese caso de la cadena, es un carácter de doble byte, y luego ajustar el índice donde cortas, dependiendo de si es uno de esos, en el 14 o 15. Y luego puedes usar StringPrototype, Slice o Substring, o cualquier API que quieras usar. Pero sí, no es bonito pero es correcto y, ya sabes, la gente podría darse cuenta de que simplemente estás cortando en medio de un emoji o algo así. Genial. En todo Python, Versus forzará la codificación UTF-8 en la parte superior del archivo. ¿Hay alguna forma de forzar una codificación en JS? Forzar, forzar. Quiero decir, puedes pasar un parámetro de codificación explícito a la mayoría de las API de JavaScript que hacen codificación o decodificación. TextEncoder, como mencioné, es una de las excepciones a eso porque solo admite UTF-8 porque se supone que debes usar UTF-8 a menos que tengas una muy buena razón para no hacerlo. Pero en otros casos, quiero decir, las API de Node.js que hacen codificación o decodificación toman un parámetro explícito y otras codificaciones también lo hacen, sí.

¿Y cuál es la forma más rápida de manejar cadenas largas? ¿Hacer qué? Quiero decir, simplemente haz lo que harías normalmente. Y luego, si te encuentras con problemas de rendimiento, puedes echar un vistazo más detallado. Pero en general, quiero decir, escribe en tu meta JavaScript y, ya sabes, confía en el motor para que tome decisiones inteligentes por ti, en su mayor parte. Genial. Bueno. Y la última pregunta será, ¿cuál es la longitud de esta cadena? Y, ¿cómo defines la longitud? Creo que si pasas esto a esta cadena con los paquetes que mencioné antes, podría decir simplemente que eso es el ancho. Y obviamente, los otros casos, no puedo responder realmente. Bueno, muchas gracias, Anna. Esta fue una gran charla.