Codificación de caracteres en JS

Rate this content
Bookmark

Las codificaciones de caracteres pueden ser confusas para cualquier desarrollador, brindando dificultades incluso para los más experimentados, por lo que muchas veces queremos obtener algo que simplemente funcione sin una comprensión profunda de los conceptos involucrados. En esta charla, Anna dará una visión general de qué son, qué proporciona el lenguaje JavaScript para interactuar con ellas y cómo evitar los errores más comunes en Node.js y en la Web.

33 min
14 Apr, 2023

Video Summary and Transcription

Las codificaciones de caracteres son importantes para convertir caracteres en bytes. UTF-8 es la codificación más comúnmente utilizada en JavaScript. Los motores de JavaScript manejan automáticamente las codificaciones de caracteres. Hay errores en Node.js relacionados con la codificación de caracteres y la manipulación de cadenas. Es importante tener precaución al trabajar con codificaciones de caracteres y elegir el método adecuado para la manipulación de cadenas.

Available in English

1. Introducción a las Codificaciones de Caracteres

Short description:

Trabajo en MongoDB en el equipo de Herramientas para Desarrolladores. Así que vamos a empezar. ¿Por qué son importantes las codificaciones de caracteres? Tu programa normalmente se ejecuta en un sistema operativo que no tiene idea de lo que es una cadena de texto. La solución es asignar números a los caracteres y convertirlos en bytes. Las cadenas de texto y las secuencias de bytes son cosas diferentes. Históricamente, las personas idearon formas de asignar números a los caracteres, como ASCII y las codificaciones de caracteres para diferentes idiomas.

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.

2. Codificaciones de Caracteres y JavaScript

Short description:

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. Unicode resuelve el problema al permitir tantos puntos de código como queramos. UTF-8 es la codificación más comúnmente utilizada y es compatible con ASCII. Por otro lado, UTF-16 utiliza dos bytes por carácter pero puede requerir cuatro bytes para ciertos caracteres. JavaScript te permite interactuar con cadenas como si estuvieran almacenadas utilizando UTF-16.

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.

3. Almacenamiento y Longitud de Cadenas en JavaScript

Short description:

A veces, los motores de JavaScript no utilizan UTF-16 para texto que solo contiene caracteres ASCII, lo cual ahorra espacio de almacenamiento. Al emitir una salida solo en ASCII, se puede reducir el tamaño ejecutable en general. JavaScript proporciona diferentes formas de obtener la longitud de una cadena, pero no hay una forma rápida de obtener el número de caracteres. Considera el propósito de obtener la longitud de la cadena y explora paquetes de npm si es necesario.

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.

4. Codificación y Decodificación en JavaScript

Short description:

Hace muchas cosas que nunca pensarías porque algunos caracteres son invisibles, por lo que no ocupan ningún espacio en absoluto. Lo que queremos hacer en JavaScript es convertir cadenas en secuencias de bytes. Buffer es una API muy antigua en Node, y hay reemplazos estándar de API web. La codificación de cosas es bastante fácil con instancias de codificador de texto, y la decodificación tiene opciones de configuración interesantes como fallos fatales y la bandera de transmisión verdadera.

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.

5. Decodificador de Texto y Errores en Node.js

Short description:

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. La gente se equivoca todo el tiempo en Node. Hay un error en la documentación de Node.js donde los fragmentos pueden no estar alineados correctamente con los límites de los caracteres. Afortunadamente, esto es algo bastante fácil de solucionar. Las transmisiones de Node.js tienen la propiedad setEncoding donde puedes indicarle que decodifique los datos entrantes utilizando esta codificación. Otro error en Node.js es la función hash que a veces produce resultados inesperados.

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.

6. Alias Binario y Pasar Binario a las APIs de Node.js

Short description:

Puedes pasar diferentes cadenas a esta función hash y obtener el mismo resultado. Eso es malo. Binario es un alias heredado para ISO 88591 en Node.js. 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. Siempre trabajan en secuencias de bytes. Así es como están diseñadas todas las cosas de criptografía.

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.

7. Consideraciones Finales

Short description:

Ten en cuenta que las codificaciones de caracteres son importantes, incluso si no estás trabajando directamente con ellas. UTF-8 es popular porque es compatible con ASCII. No asumas que JavaScript está utilizando UTF-16, pero tampoco ignores la posibilidad. Sé cauteloso al copiar código de la documentación.

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.

QnA

Longitud de cadenas y codificación de caracteres

Short description:

La mejor manera de encontrar la longitud de una cadena en JS depende de lo que necesites. Si te importan los caracteres individuales o los elementos de cadena de JavaScript, las respuestas serán diferentes. Al usar un bucle for con notación de indexación de matriz, ten en cuenta los caracteres que se dividen en dos. Puedes manejar esta situación utilizando el método Code Point At. En el ejemplo de colisión, A y L tienen la misma representación de bytes cuando se utiliza la codificación de caracteres ISO-88591 en Node.js.

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.

Codificación de caracteres y motores de JavaScript

Short description:

Los motores de JavaScript convierten automáticamente los caracteres fuera de ASCII. Verifican si los caracteres pueden representarse en la codificación deseada. V8, por ejemplo, puede tener cadenas concatenadas con diferentes codificaciones. No intentes engañar al motor.

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.

Codificación WTF8 y Manipulación de Cadenas

Short description:

Deseas la codificación estándar WTF8 y la validación estándar que proporciona. El formato de codificación más recomendado es WTF8. Para truncar de forma segura una cadena después de 15 caracteres, utiliza la API CodePointAdd para verificar los caracteres de doble byte. Puedes forzar una codificación en JS pasando un parámetro de codificación explícito. La forma más rápida de manejar cadenas largas es confiar en el motor de JavaScript. La longitud de la cadena depende de cómo se mida.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.