Codificación de caracteres en JS

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at Node Congress 2023, check out the latest edition of this JavaScript Conference.

FAQ

UTF-8 es una codificación de caracteres que es compatible con ASCII y utiliza bytes adicionales para representar caracteres que no están en el rango ASCII. Es importante porque permite una representación más amplia de caracteres mientras mantiene la compatibilidad con sistemas que soportan ASCII.

UTF-8 y UTF-16 son codificaciones de caracteres Unicode. UTF-8 es variable de 1 a 4 bytes, optimizado para caracteres ASCII que utilizan solo 1 byte. UTF-16 utiliza 2 o 4 bytes para cada carácter, siendo más eficiente para lenguajes con caracteres más complejos pero usando más espacio para caracteres ASCII.

TextEncoder es una API que permite convertir cadenas de texto en JavaScript a una secuencia de bytes, generalmente en UTF-8. Se utiliza principalmente para preparar texto para ser enviado o almacenado, donde se requiere una forma binaria en lugar de texto.

Para medir la longitud de una cadena que incluye caracteres Unicode en JavaScript, es recomendable utilizar protocolos que tengan en cuenta los puntos de código Unicode, como iterar con 'for...of' o usar métodos que reconozcan unidades de código, ya que el método '.length' puede no reflejar la cantidad de caracteres visibles correctamente.

Unicode es un estándar que asigna un código único para cada carácter, independientemente del sistema o lenguaje. Facilita la codificación de caracteres al asignar estos códigos a secuencias de bytes, permitiendo representar y manipular texto de múltiples lenguajes de manera uniforme.

La codificación de caracteres puede afectar el rendimiento, especialmente en términos de almacenamiento y velocidad de procesamiento. Por ejemplo, usar UTF-16 en textos principalmente ASCII desperdicia espacio, mientras que UTF-8 puede ser más eficiente. Los motores de JavaScript optimizan esto internamente, pero la elección de codificación sigue siendo relevante.

Anna Henningsen
Anna Henningsen
33 min
14 Apr, 2023

Comments

Sign in or register to post your comment.
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: JS Character Encodings

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

Escalando con Remix y Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Escalando con Remix y Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Componentes de Full Stack
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Componentes de Full Stack
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Depuración de JS
React Summit 2023React Summit 2023
24 min
Depuración de JS
Top Content
Debugging JavaScript is a crucial skill that is often overlooked in the industry. It is important to understand the problem, reproduce the issue, and identify the root cause. Having a variety of debugging tools and techniques, such as console methods and graphical debuggers, is beneficial. Replay is a time-traveling debugger for JavaScript that allows users to record and inspect bugs. It works with Redux, plain React, and even minified code with the help of source maps.
Haciendo JavaScript en WebAssembly Rápido
JSNation Live 2021JSNation Live 2021
29 min
Haciendo JavaScript en WebAssembly Rápido
Top Content
WebAssembly enables optimizing JavaScript performance for different environments by deploying the JavaScript engine as a portable WebAssembly module. By making JavaScript on WebAssembly fast, instances can be created for each request, reducing latency and security risks. Initialization and runtime phases can be improved with tools like Wiser and snapshotting, resulting in faster startup times. Optimizing JavaScript performance in WebAssembly can be achieved through techniques like ahead-of-time compilation and inline caching. WebAssembly usage is growing outside the web, offering benefits like isolation and portability. Build sizes and snapshotting in WebAssembly depend on the application, and more information can be found on the Mozilla Hacks website and Bike Reliance site.
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Node Congress 2022Node Congress 2022
26 min
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
¿Webpack en 5 años?
JSNation 2022JSNation 2022
26 min
¿Webpack en 5 años?
Top Content
In the last 10 years, Webpack has shaped the way we develop web applications by introducing code splitting, co-locating style sheets and assets with JavaScript modules, and enabling bundling for server-side processing. Webpack's flexibility and large plugin system have also contributed to innovation in the ecosystem. The initial configuration for Webpack can be overwhelming, but it is necessary due to the complexity of modern web applications. In larger scale applications, there are performance problems in Webpack due to issues with garbage collection, leveraging multiple CPUs, and architectural limitations. Fixing problems in Webpack has trade-offs, but a rewrite could optimize architecture and fix performance issues.

Workshops on related topic

Domina los Patrones de JavaScript
JSNation 2024JSNation 2024
145 min
Domina los Patrones de JavaScript
Top Content
Featured Workshop
Adrian Hajdin
Adrian Hajdin
Durante esta masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debería conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final de la masterclass, los participantes ganarán una nueva confianza en su capacidad para escribir código JavaScript de alta calidad que resista el paso del tiempo.
Puntos Cubiertos:
1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso
Cómo Ayudará a los Desarrolladores:
- Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y la comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento de la carrera y las oportunidades de avance en la industria del software
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
React Day Berlin 2022React Day Berlin 2022
86 min
Uso de CodeMirror para construir un editor de JavaScript con Linting y AutoCompletado
Top Content
Workshop
Hussien Khayoon
Kahvi Patel
2 authors
Usar una biblioteca puede parecer fácil a primera vista, pero ¿cómo eliges la biblioteca correcta? ¿Cómo actualizas una existente? ¿Y cómo te abres camino a través de la documentación para encontrar lo que quieres?
En esta masterclass, discutiremos todos estos puntos finos mientras pasamos por un ejemplo general de construcción de un editor de código usando CodeMirror en React. Todo mientras compartimos algunas de las sutilezas que nuestro equipo aprendió sobre el uso de esta biblioteca y algunos problemas que encontramos.
Masterclass de Node.js
Node Congress 2023Node Congress 2023
109 min
Masterclass de Node.js
Top Content
Workshop
Matteo Collina
Matteo Collina
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.

Nivel: intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Construir y Desplegar un Backend Con Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Construir y Desplegar un Backend Con Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic te permite desarrollar rápidamente GraphQL y REST APIs con un esfuerzo mínimo. La mejor parte es que también te permite desatar todo el potencial de Node.js y Fastify siempre que lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y plugins adicionales. En la masterclass, cubriremos tanto nuestros módulos de Open Source como nuestra oferta en la Nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). 
En esta masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la Platformatic Cloud.
Desatando los Componentes del Servidor React: Una Inmersión Profunda en el Desarrollo Web de la Próxima Generación
React Day Berlin 2023React Day Berlin 2023
149 min
Desatando los Componentes del Servidor React: Una Inmersión Profunda en el Desarrollo Web de la Próxima Generación
Workshop
Maurice de Beijer
Maurice de Beijer
¡Prepárate para potenciar tus habilidades de desarrollo web con los Componentes del Servidor React! En esta inmersiva masterclass de 3 horas, desbloquearemos el potencial completo de esta tecnología revolucionaria y exploraremos cómo está transformando la forma en que los desarrolladores construyen aplicaciones web rápidas y eficientes.
Únete a nosotros mientras nos adentramos en el emocionante mundo de los Componentes del Servidor React, que combinan sin problemas el renderizado del lado del servidor con la interactividad del lado del cliente para un rendimiento y una experiencia de usuario inigualables. Obtendrás experiencia práctica a través de ejercicios prácticos, ejemplos del mundo real y orientación experta sobre cómo aprovechar el poder de los Componentes del Servidor en tus propios proyectos.
A lo largo de la masterclass, cubriremos temas esenciales, incluyendo:- Entender las diferencias entre los Componentes del Servidor y del Cliente- Implementar Componentes del Servidor para optimizar la obtención de datos y reducir el tamaño del paquete JavaScript- Integrar Componentes del Servidor y del Cliente para una experiencia de usuario fluida- Estrategias para pasar datos efectivamente entre componentes y gestionar el estado- Consejos y mejores prácticas para maximizar los beneficios de rendimiento de los Componentes del Servidor React