UTF-8 es un diseño brillante [ENG]

La primera vez que aprendí sobre la codificación de UTF-8 me fascinó lo bien pensado y brillantemente diseñado para representar a millones de caracteres de diferentes idiomas y aún así ser compatible con ASCII. Básicamente, UTF-8 usa 32 bits y el antiguo ASCII usa 7 bits, pero UTF-8 está diseñado de tal manera que cada archivo codificado ASCII es un archivo UTF-8 válido, y cada archivo codificado UTF-8 que solo tiene caracteres ASCII es un archivo ASCII válido. Diseñar un sistema que escala a millones de caracteres y que aún sea compatible con los sistemas antiguos que usan solo 128 caracteres es un diseño brillante.

[#3 hrundil]

El tribunal de la Haya ya está tardando en procesar a los que han creado UTF-8 y los 48574833 simbolos absurdos de Unicode.

Edit: vaya mientras escribía el mensaje han añadido 737 emojis nuevos incluyendo 35 variantes para el acto de mear de pie.

[#4 pip]

#3 lo de añadir emojis se nos va de las manos. Tiene que ser una puta locura ser el pringao que actualiza las fuentes de letra.

[#7 OCLuis]

#4 Hasta que no podamos comunicarnos completamente con ellos, como hacen los chinos con sus ideogramas, no van a parar.

[#6 PerritaPiloto]

#3 Pero aún no han añadido la polla con orejas.

[#9 Toponotomalasuerte]

#6 deja la política en paz, coño!!! A ver qué tiene que ver Almeida en una noticia sobre utf8. Malditos güokes.

[#12 PerritaPiloto]

#9 Eres tú el que ha visto política en mi comentario. Yo solo he visto un dibujito grotesco.

[#5 Torrezzno]

Está muy bien explicado, es una pasada que sea retrocompatible con ascii.

Como curiosidad, en Go un string es una cadena de bytes y puedes acceder mediante un índice como en cualquier lenguaje. El problema está cuando usas caracteres UTF-8 de más de un byte, como explica el artículo. Para poder trabajar con eso inventan el concepto de "runa" que no es más que un int32, 4 bytes, para representar un punto de unicode

goplay.tools/snippet/8uX-j1pmJHj

[#2 jjmf]

Si escribes inglés pues sí, pero para eso ya tenías el ascii. Si no, te jodes.

[#19 HeilHynkel]

#13

Es posible .. ya ni me acuerdo de los cambios en concreto, te hablo de principios de los 90, pero es posible que el backslash fuera uno de ellos.

[#11 HeilHynkel]

Pa los jovenzuelos ... hace muchos años teníamos ASCII (7 y 8 bits) EBCDIC y poco más. Para poner EÑES y vocales acentuadas había una versión española del ASCII donde esos caracteres estaban por encima del 127 que funcionaba en los PC con MSDOS.

Pero claro, eso era en los PCs, nosotros currabamos en XENIX/UNIX de SCO y con terminales series RS-232 que solo iban con 7 bits y si configurabas el terminal en español lo que hacía era cambiar los gráficos de ciertos caracteres por la Ñ y los acentos (no me acuerdo cuales eran, posiblemente las llaves, corchetes y similares) Total, que en pantalla veías las cosas en español y por la impresora te salían cosas raras como Espa;a o Salchich}n.

[#13 pip]

#11 la barra "/" o quizás "\" es lo que yo recuerdo que se ponía en sustitución de la Ñ en sistemas posiblemente UNIX. Lo recuerdo de listados en papel continuo del año la pera.

[#17 jjmf]

#11 Yo sigo usando el ebdic en el trabajo aunque tiene ya los días contados.

[#20 HeilHynkel]

#17

El COBOL nos va a enterrar a los dos y a casi todo menéame.

[#21 pip]

#20 #17 ¿seguís programando en COBOL? mis respetos y os deseo que estéis bien de salud.

[#22 HeilHynkel]

#21

Yo no, pero ahí sigue el jodío.

[#16 euacca]

#15 pues que quien quiera use UTF-32 que para eso está. Y quien quiera usar UTF-8 ahí lo tiene.

[#1 pip]

La verdad no lo veo tan brillante, es la solución lógica si quieres ser compatible con ASCII de 7bit. No hay muchas más maneras de hacerlo que usar el bit sobrante para ir encadenando información extra.

Personalmente yo hubiese preferido mandar los 8bit a tomar por culo y hacerlo todo UNICODE 32bit y listos. El espacio del texto ya no es un problema y el UTF8 complica algunas cosas. Y para los idiomas orientales como el chino, el UTF-8 no va bien, básicamente porque está todo el rato "encadenando".

[#10 reivaj01]

#1 UTF-8 está bien para el mundo occidental, pero para los idiomas orientales, es mejor UTF-16.
UTF-32 está bien conceptualmente, pero se desperdicia demasiado espacio.
UTF-8 tiene longitud variable, es decir si escribes en inglés, ocupará lo mismo que hacerlo en ASCII, pero es que, por ejemplo, en español, como mucho va a ocupar, un 10% más.
Por lo tanto, se puede deducir que UTF-8 es lo mejor para América, Oceanía, África y Europa (quizás no para los idiomas que usan caracteres cirílicos).

[#14 euacca]

#1 No, claro, solo multiplicas por 4 el uso de datos de todas las web del mundo (salvo el empleado en imágenes, videos y otros ficheros).

[#15 pip]

#14 para web sí. A nivel de sistema operativo los 32bit son más limpios y cómodos.

[#18 euacca]

#14 Veo que #1 ha editado después de que yo comenzara a responder. El resto del mundo se sigue beneficiando de que UTF-8 sea en estándar en JSON salvo que las cadenas de texto sean muchas y muy largas, que en ese caso se soluciona con compresión, pero en UTF-16 o 32 sucede lo mismo, si quieres no abusar del ancho de banda es mejor usar compresión, a costa de CPU y latencia.

[#8 Robe7064]

Me gusta UTF-8 desde el primer momento que supe de su existencia, pero me molesta que todavía no hayan agregado el alfabeto de Ellis de 1845 (ideado para escribir "fonéticamente" el inglés antes de que existiera una teoría fonética sólida) para poder transcribir los textos en yagán que escribió Bridges archive.org/details/gospelofsluketra00brid/page/5/mode/1up