Hace veinte años, Joel Spolsky escribió: «No existe el texto plano. No tiene sentido tener una cadena de caracteres sin saber qué codificación utiliza. Ya no puedes esconder la cabeza en la arena y pretender que el texto “plano” es ASCII». Mucho ha cambiado en 20 años. En 2003 la pregunta principal era: ¿qué codificación es esta? En 2023 ya no es esa la cuestión: con un 98% de probabilidad la codificación será UTF-8. ¡Ya podemos volver a esconder la cabeza en la arena!
|
etiquetas: unicode , joel spolsky , mínimo absoluto , utf-8 , desarrollador , texto plano
PD: mare mía, qué puto viejo me he hecho
Me refiero justamente a algo que dice el artículo:
And a couple of important consequences:
You CAN’T determine the length of the string by counting bytes.
You CAN’T randomly jump into the middle of the string and start reading.
You CAN’T get a substring by cutting at arbitrary byte offsets. You might cut off part of the character.
Del EBCDIC no digo ná porque los mainframes lo deben seguir usando.
Señores de Microsoft, ¿tan complicado es poner por defecto como codificación UTF-8 cuando se exporta a CSV? Es más, ¿podéis hacer que por favor los decimales aparezcan en los CSV como un jodido punto y quitar de una maldita vez el separador de miles?
Es decir “ ”.strlen() no es 4.
Dicho sea de paso, la cosa llega al extremo de que en python hay cadenas "normales", y cadenas utf8, que van precedidas por una letra u.
Pero bueno, con el tiempo he aprendido a convivir con utf8.
P.D.: El modo lectura es tu amigo.
3.1.2 :021 > " ".length
=> 5
en mi trabajo actual he estado convirtiendo software legacy que no era unicode a unicode y es practicamente automatico, he teneido que ensuciarme las manos por que se uso mucho string como buffer de cosas binarias en vez de usar arrays de bytes y claro al cambiar a unicode el puntero saltaba de dos en dos y no de en uno en uno, pero si el codigo no tuviera esas guarradas la conversion es automatica practicamente.
En desarrollo no puede ser excusa tener recursos de sobra para no optimizar, y en este caso, es mejor utilizar más memoria que no CPU para tener accesos O(1).
De hecho, MySQL recomienda utilizar utf8mb4 como character encoding, y una cosa que no sabía es que el encoding utf8 es un alias a utf8mb3, así que siempre almacena 3 bytes por carácter
stackoverflow.com/questions/30074492/what-is-the-difference-between-ut
Por cierto que en pleno 2023 UTF-8 todavía NO es el encoding por defecto del SQL Server de Microsoft, y hay que dar saltos como un mono para usarlo. Lamentable.
Nada, pero los terminales serie que usábamos hacian una cosa muy rara (ahora, para ellos sería de lo mas normal) Se codificaban en 7 bit pero si cambiabas el idioma (en el terminal) se cambiaba la representación de los símbolos. Por ejemplo la Ñ aparecía en un código por debajo de 127 (eliminando el simbolo correspondiente, claro)
Por ese motivo yo aprendí a codificar usando un teclado serigrafiado en español pero usando el layout inglés (de aquella el UNIX no tenía los caracteres españoles, al menos nuestra versión) Con el tiempo eso me vino bien cuando se descojonaba alguna máquina UNIX y se ponía solo el layout inglés. Yo podía teclear comandos unix sin problemas porque sabía de memoria donde estaban el guión, los slash, ...
También me suena que nos la armaban con los RS-232 porque por encima del 127 se enviaban caracteres de control (hace 30 años de aquello, tampoco me hagas mucho caso)
Claro, pero por un lado el standard hoy en día es utf-8. Por otro lado si me decantara por algo sería por ascii, no por algo tan ineficiente como utf-32.
Esto es lo que se usa internamente en memoria, para poder trabajar cómodamente con cadenas
Claro, como la memoria sobra, abusemos de ella. Total que la gente se compre un ordenador nuevo si hace falta.
Debe ser mis viejas costumbres de hacer programas que entraran en 64kb (en realidad 8K si era posible). Después se preguntan como un ordenador 1000 veces más lento arrancaba 100 veces más rápido.
Es lo usual hoy en día. Bueno, en realidad la excusa para no optimizar es que "time is money", y si haciendo una chapuza terminas rápido, que el cliente compre más memoria. Total, con lo que cuesta 1 día de trabajo se pagan muchos gigabytes de ram. Y así hemos llegado a donde estamos ahora.
Pero es que no basta con tener la longitud. ¿Qué pasa si quiero extraer solamente la tercera letra? Claro, almaceno internamente en utf16 o utf32. Así gasto memoria pero puedo hacer búsquedas rápido. Pero... ¿y si en el 99% de los casos nadie saca substrings? estoy usando un formato de almacenamiento innecesario.
Claro, está la posibilidad de que el usuario decida lo que quiere. O incluso que el compilador lo decida.
Pero nos olvidamos de cuando vamos a trabajar a nivel más bajo. ¿Qué pasa si quiero extraer texto de un paquete recibido por un socket tcp/ip? ¿Y si quiero armar un paquete de datos para grabar directo a disco en un formato específico? Claro. Toca convertir.
Obviamente hay soluciones. Pero no deja de ser una complicación extra.
Hace muchos años, cuando unicode no estaba tan extendido, tuve que lidiar con una base de datos que guardaba muchos nombres de personas con procedencias del este y a veces alfabeto ruso y fue un auténtico infierno conseguir que todo (BD, Backend, frontend, excels, etc..) funcionase en unicode. Hoy es mucho más fácil.
Todo tiene ventajas e inconvenientes.
Pues sí. Total se compra un ordenador más potente y listo
En cambio, el capullo ese ha puesto lo de los cursores única y exclusivamente para tocar los cojones y dificultar la lectura. Que le den.
Otro problema gordo es que se actualice año tras año... ¿Y si quiero distribuir mi aplicación en CD-ROM o como sea? ¿Y si no puedo actualizar mi aplicación año tras año porque no soy programador y tengo mejores cosas que hacer? ¿Y si quiero que los bytes de un texto no cambien para que un hash generado desde ellos tampoco cambie? Las actualizaciones deberían ser siempre para añadir cosas, NUNCA para modificar retroactivamente lo que se ha implementado.
Y otro problema: añadir emojiconos a símbolos que son antiguos, como por ejemplo, una flecha, porque te está forzando un aspecto estético, mientras que la representación en texto (o sea un contorno) permite elegir el color de la fuente, si es cursiva o negrita... Los emojiconos deberían ser siempre en caracteres exclusivos, y como antes, no convertir en emojicono un símbolo que nunca lo ha sido.
Se tendría que haber buscado otra forma de hacerlo en mi opinión. El BBcode yo creo que estaba bien, con llaves, alguna palabra clave y listo. En aplicaciones de mensajería se puede implementar de forma transparente para el usuario, pulsando un botón y sacando la carita o dibujo correspondiente.
A mí lo de que hay que actualizar ha sido lo que más claro me ha dejado que está mal implementado. No siempre se puede actualizar, no siempre hay una persona que se hace cargo de ello... o sea, imaginad un artículo de la Wikipedia, no hay problema en actualizarlo, pero... ¿Quién lo hace? ¿Quién se percata de que un símbolo raro que aparece es un Unicode antiguo que han cambiado? ¿Se pone un robot rastreador? ¿Quién lo programa y corre con el gasto de funcionamiento, si bastante cuestan los servidores?
Pues hay varias alternativas. Puedes usar por ejemplo iso8859-17 o simplemente poner ~ en lugar de la ñ o algo así.
Y que en algunos foros es como se copiaban en el portapapeles.
github.com/ocaml/ocaml/issues/10749
Puto w_char_t
Supongo que los programas usan indices para orientar donde letras completas.
No se si hay algoritmos para entender una cadena que desconoces el comienzo.
Con los retornos de carro pasa lo mismo en Ascii, no puedes ir directo a la linea tal,porque tienes que ir buscando todos los saltos de linea para saber donde esta el tuyo.
#17 Creo que a partir de python3 todo es UTF, en rust tambiien es todo UTF.
No se si en la implementacion de la cadena. Tienen metadatos para no recorrer la cadena entera. Ya de paso se podrian poner para detectar los saltos de carro o los espacios y poder ir directo a la lineas o palabra x.
En C la cadena era bytes brutos y al final un Null. Para saber la longitud enteidno que tambien habria que buscar el NULL. En Rust No se hace asi porque es una fuente de corrupcion de sofware y entiendo un problema de rendimiento.
En python creo que tamiben hay implmentaciones no standar de Arrays y cadenas de texto, mas eficientes y optimas para quien necesite mas rendimiento. Modulo array y Bstrings o algo asi.
Mejor explicado en #27 de cosas qu me he imaginado.
#40 Mucho mas eficiente que usar el UTF-32 como dicen arriba.