Mojibake ( en japonés :文字化け; IPA: [mod͡ʑibake] , "transformación de caracteres") es el texto confuso o incoherente que es el resultado de la decodificación de un texto mediante una codificación de caracteres no intencionada . [1] El resultado es un reemplazo sistemático de símbolos por otros completamente no relacionados, a menudo de un sistema de escritura diferente .
Esta visualización puede incluir el carácter de reemplazo genérico ("�") en lugares donde la representación binaria se considera inválida. Un reemplazo también puede involucrar múltiples símbolos consecutivos, como se ve en una codificación, cuando el mismo código binario constituye un símbolo en la otra codificación. Esto se debe a una codificación de longitud constante diferente (como en las codificaciones asiáticas de 16 bits frente a las codificaciones europeas de 8 bits) o al uso de codificaciones de longitud variable (especialmente UTF-8 y UTF-16 ).
La representación fallida de glifos debido a fuentes faltantes o glifos faltantes en una fuente es un problema diferente que no debe confundirse con mojibake. Los síntomas de esta representación fallida incluyen bloques con el punto de código mostrado en hexadecimal o utilizando el carácter de reemplazo genérico. Es importante destacar que estos reemplazos son válidos y son el resultado de un manejo correcto de errores por parte del software.
Para reproducir correctamente el texto original que fue codificado, se debe preservar la correspondencia entre los datos codificados y la noción de su codificación (es decir, los estándares de codificación de origen y destino deben ser los mismos). Como mojibake es el ejemplo de incumplimiento entre estos, se puede lograr manipulando los datos en sí o simplemente cambiándoles el nombre.
A menudo, Mojibake se ve con datos de texto que han sido etiquetados con una codificación incorrecta; es posible que ni siquiera estén etiquetados, sino que se hayan transferido entre computadoras con codificaciones predeterminadas diferentes. Una fuente importante de problemas son los protocolos de comunicación que dependen de la configuración de cada computadora en lugar de enviar o almacenar metadatos junto con los datos.
Las diferentes configuraciones predeterminadas entre computadoras se deben en parte a las diferentes implementaciones de Unicode entre las familias de sistemas operativos y en parte a las especializaciones de las codificaciones heredadas para los diferentes sistemas de escritura de los lenguajes humanos. Mientras que las distribuciones de Linux cambiaron principalmente a UTF-8 en 2004, [2] Microsoft Windows generalmente usa UTF-16 y, a veces, usa páginas de códigos de 8 bits para archivos de texto en diferentes idiomas.
Para algunos sistemas de escritura , como el japonés , históricamente se han empleado varias codificaciones, lo que hace que los usuarios vean mojibake con relativa frecuencia. Por ejemplo, la propia palabra mojibake ("文字化け") almacenada como EUC-JP podría mostrarse incorrectamente como "ﾊｸｻ�ｽ､ｱ", "ﾊｸｻ嵂ｽ､ｱ" ( MS-932 ) o "ﾊｸｻ郾ｽ". ､ｱ" si se interpreta como Shift-JIS, o como "ʸ»ú²½¤±" en software que asume que el texto está en las codificaciones Windows-1252 o ISO 8859-1 , generalmente etiquetado como occidental o europeo occidental . Esto se agrava aún más si se involucran otras configuraciones regionales: el mismo texto almacenado como UTF-8 aparece como "譁�蟄怜喧縺�" si se interpreta como Shift-JIS, como "æ–‡å—化ã '" si se interpreta como Western , o (por ejemplo) como "鏂囧瓧鍖栥亼" si se interpreta como que está en una configuración regional de GBK (China continental).
Si no se especifica la codificación, el software debe decidirla por otros medios. Según el tipo de software, la solución típica es la configuración o la detección heurística de conjuntos de caracteres. Ambas son propensas a realizar predicciones erróneas.
La codificación de los archivos de texto se ve afectada por la configuración regional , que depende del idioma del usuario, la marca del sistema operativo y muchas otras condiciones. Por lo tanto, la codificación asumida es sistemáticamente incorrecta para los archivos que provienen de una computadora con una configuración diferente, o incluso de un software localizado de manera diferente dentro del mismo sistema. Para Unicode, una solución es usar una marca de orden de bytes , pero para el código fuente y otro texto legible por máquina, muchos analizadores no lo toleran. Otra es almacenar la codificación como metadatos en el sistema de archivos. Los sistemas de archivos que admiten atributos de archivo extendidos pueden almacenar esto como user.charset. [3] Esto también requiere soporte en el software que desea aprovecharlo, pero no perturba a otro software.
Si bien algunas codificaciones son fáciles de detectar, como UTF-8, hay muchas que son difíciles de distinguir (consulte detección de conjuntos de caracteres ). Es posible que un navegador web no pueda distinguir una página codificada en EUC-JP y otra en Shift-JIS si la codificación no se asigna explícitamente mediante encabezados HTTP enviados junto con los documentos, o mediante las metaetiquetas del documento HTML que se utilizan para sustituir los encabezados HTTP faltantes si el servidor no se puede configurar para enviar los encabezados HTTP adecuados; consulte codificaciones de caracteres en HTML .
Mojibake también ocurre cuando la codificación se especifica incorrectamente. Esto sucede a menudo entre codificaciones que son similares. Por ejemplo, se sabía que el cliente de correo electrónico Eudora para Windows enviaba correos electrónicos etiquetados como ISO 8859-1 que en realidad eran Windows-1252 . [4] Windows-1252 contiene caracteres imprimibles adicionales en el rango C1 (los más frecuentes son comillas curvas y guiones adicionales ), que no se mostraban correctamente en el software que cumplía con el estándar ISO; esto afectaba especialmente al software que se ejecutaba en otros sistemas operativos como Unix .
De las codificaciones que todavía se utilizan habitualmente, muchas se originaron a partir de la adición de ASCII ; como resultado, estas codificaciones son parcialmente compatibles entre sí. Algunos ejemplos de esto incluyen Windows-1252 e ISO 8859-1. Por lo tanto, las personas pueden confundir el conjunto de codificaciones expandidas que están utilizando con ASCII simple.
Cuando existen capas de protocolos, cada una de las cuales intenta especificar la codificación basándose en información diferente, la información menos segura puede ser engañosa para el destinatario. Por ejemplo, considere un servidor web que sirve un archivo HTML estático a través de HTTP. El conjunto de caracteres puede comunicarse al cliente de tres maneras:
http-equivo charset) o el encodingatributo de una declaración XML . Esta es la codificación en la que el autor quiso guardar el archivo en particular.El hardware mucho más antiguo está diseñado para admitir un solo conjunto de caracteres y, por lo general, este conjunto de caracteres no se puede modificar. La tabla de caracteres incluida en el firmware de la pantalla se localizará para tener caracteres correspondientes al país en el que se venderá el dispositivo y, por lo general, la tabla difiere de un país a otro. Por lo tanto, estos sistemas potencialmente mostrarán mojibake al cargar texto generado en un sistema de un país diferente. Del mismo modo, muchos de los primeros sistemas operativos no admiten múltiples formatos de codificación y, por lo tanto, terminarán mostrando mojibake si se configuran para mostrar texto no estándar; las primeras versiones de Microsoft Windows y Palm OS , por ejemplo, se localizan por país y solo admitirán estándares de codificación relevantes para el país en el que se venderá la versión localizada, y mostrarán mojibake si se abre un archivo que contiene un texto en un formato de codificación diferente de la versión que el sistema operativo está diseñado para admitir.
Las aplicaciones que utilizan UTF-8 como codificación predeterminada pueden lograr un mayor grado de interoperabilidad debido a su uso generalizado y a su compatibilidad con versiones anteriores de US-ASCII . UTF-8 también tiene la capacidad de ser reconocido directamente por un algoritmo simple, de modo que un software bien escrito debería poder evitar mezclar UTF-8 con otras codificaciones.
La dificultad de resolver una instancia de mojibake varía según la aplicación en la que se produce y las causas de la misma. Dos de las aplicaciones más comunes en las que puede producirse mojibake son los navegadores web y los procesadores de texto . Los navegadores y procesadores de texto modernos suelen admitir una amplia gama de codificaciones de caracteres. Los navegadores suelen permitir al usuario cambiar la configuración de codificación de su motor de renderizado sobre la marcha, mientras que los procesadores de texto permiten al usuario seleccionar la codificación adecuada al abrir un archivo. Es posible que los usuarios deban realizar algunas pruebas y errores para encontrar la codificación correcta.
El problema se complica cuando se produce en una aplicación que normalmente no admite una amplia gama de codificaciones de caracteres, como en un juego de ordenador que no sea Unicode. En este caso, el usuario debe cambiar la configuración de codificación del sistema operativo para que coincida con la del juego. Sin embargo, cambiar la configuración de codificación de todo el sistema también puede provocar Mojibake en aplicaciones preexistentes. En Windows XP o posterior, un usuario también tiene la opción de utilizar Microsoft AppLocale , una aplicación que permite cambiar la configuración regional por aplicación. Aun así, no es posible cambiar la configuración de codificación del sistema operativo en sistemas operativos anteriores como Windows 98 ; para resolver este problema en sistemas operativos anteriores, un usuario tendría que utilizar aplicaciones de representación de fuentes de terceros.
En los textos en inglés, el mojibake aparece generalmente en signos de puntuación, como guiones largos (— ), guiones cortos (– ) y comillas tipográficas (“,”,','), pero rara vez en textos con caracteres, ya que la mayoría de las codificaciones coinciden con ASCII en la codificación del alfabeto inglés . Por ejemplo, el signo de almohadilla £ aparecerá como £si el remitente lo hubiera codificado como UTF-8, pero el destinatario lo interpretara como una de las codificaciones de Europa occidental ( CP1252 o ISO 8859-1 ). Si se itera utilizando CP1252, esto puede dar lugar a £, £, £, £, y así sucesivamente.
De manera similar, la comilla simple derecha ('), cuando se codifica en UTF-8 y se decodifica utilizando Windows-1252, se convierte en ’, ’, ’, y así sucesivamente.
En épocas anteriores, algunas computadoras tenían codificaciones específicas del fabricante que causaban desajustes también en el caso del texto en inglés. Las computadoras de 8 bits de la marca Commodore usaban la codificación PETSCII , que se destacaba particularmente por invertir las mayúsculas y minúsculas en comparación con el ASCII estándar . Las impresoras PETSCII funcionaban bien en otras computadoras de la época, pero invertían las mayúsculas y minúsculas de todas las letras. Los mainframes de IBM usan la codificación EBCDIC que no coincide en absoluto con el ASCII.
Los alfabetos de las lenguas germánicas del norte , catalán , rumano , finlandés , francés , alemán , italiano , portugués y español son extensiones del alfabeto latino . Los caracteres adicionales son normalmente los que se corrompen, haciendo que los textos sean apenas ilegibles con mojibake:
...y sus contrapartes en mayúsculas, si corresponde.
Estos son idiomas para los que se ha utilizado el conjunto de caracteres ISO 8859-1 (también conocido como Latin 1 o Western ). Sin embargo, ISO 8859-1 ha quedado obsoleto por dos estándares competidores, el compatible con versiones anteriores Windows-1252 y el ligeramente modificado ISO 8859-15 . Ambos añaden el símbolo del euro € y el francés œ, pero por lo demás cualquier confusión de estos tres conjuntos de caracteres no crea mojibake en estos idiomas. Además, siempre es seguro interpretar ISO 8859-1 como Windows-1252, y bastante seguro interpretarlo como ISO 8859-15, en particular con respecto al símbolo del euro, que sustituye al raramente utilizado signo monetario (¤). Sin embargo, con la llegada de UTF-8 , mojibake se ha vuelto más común en ciertos escenarios, por ejemplo, el intercambio de archivos de texto entre ordenadores UNIX y Windows , debido a la incompatibilidad de UTF-8 con Latin-1 y Windows-1252. Pero UTF-8 tiene la capacidad de ser reconocido directamente por un algoritmo simple, de modo que un software bien escrito debería ser capaz de evitar mezclar UTF-8 con otras codificaciones, por lo que esto era más común cuando muchos tenían software que no soportaba UTF-8. La mayoría de estos idiomas eran soportados por el CP437 predeterminado de MS-DOS y otras codificaciones predeterminadas de la máquina, excepto ASCII, por lo que los problemas al comprar una versión del sistema operativo eran menos comunes. Sin embargo, Windows y MS-DOS no son compatibles.
En sueco, noruego, danés y alemán, las vocales rara vez se repiten y suele ser evidente cuando un carácter se corrompe, por ejemplo, la segunda letra de la palabra sueca kärlek ("amor") cuando está codificada en UTF-8 pero decodificada en occidental, produciendo "kärlek", o für en alemán, que se convierte en "für". De esta manera, aunque el lector tenga que adivinar cuál es la letra original, casi todos los textos siguen siendo legibles. El finés, por otro lado, utiliza con frecuencia vocales repetidas en palabras como hääyö ("noche de bodas"), lo que puede hacer que el texto dañado sea muy difícil de leer (por ejemplo, hääyö aparece como "hääyö"). El islandés tiene diez caracteres que pueden causar confusión, y el feroés tiene ocho, lo que hace que muchas palabras sean casi completamente ininteligibles cuando se corrompen (por ejemplo, el islandés þjóðlöð , "hospitalidad excepcional", aparece como "þjóóðlöð").
En alemán, Buchstabensalat ("ensalada de letras") es un término común para este fenómeno, en español se utiliza deformación (literalmente "deformación") y en portugués, desformatação (literalmente "desformatear").
Algunos usuarios transliteran sus escritos cuando usan una computadora, ya sea omitiendo los diacríticos problemáticos o usando reemplazos de dígrafos (å → aa, ä/æ → ae, ö/ø → oe, ü → ue, etc.). Por lo tanto, un autor podría escribir "ueber" en lugar de "über", que es una práctica estándar en alemán cuando no se dispone de diéresis . Esta última práctica parece ser mejor tolerada en el ámbito de la lengua alemana que en los países nórdicos . Por ejemplo, en noruego, los dígrafos se asocian con el danés arcaico y pueden usarse en broma. Sin embargo, los dígrafos son útiles en la comunicación con otras partes del mundo. Como ejemplo, el futbolista noruego Ole Gunnar Solskjær tenía su apellido escrito "SOLSKJAER" en su uniforme cuando jugaba para el Manchester United .
En 2014, se observó un artefacto de UTF-8 malinterpretado como ISO 8859-1 , " Ring meg nå " que se representaba como "Ring meg nÃ¥", en una estafa por SMS dirigida a Noruega. [5]
El mismo problema ocurre también en rumano, vea estos ejemplos:
Los usuarios de idiomas de Europa central y oriental también pueden verse afectados. Como la mayoría de las computadoras no estaban conectadas a ninguna red a mediados y fines de la década de 1980, existían diferentes codificaciones de caracteres para cada idioma con caracteres diacríticos (consulte ISO/IEC 8859 y KOI-8 ), que a menudo también variaban según el sistema operativo.
En húngaro , el fenómeno se conoce como betűszemét , que significa "basura de letras". El húngaro ha sido particularmente susceptible ya que contiene las letras acentuadas á, é, í, ó, ú, ö, ü (todas presentes en el conjunto de caracteres Latin-1), más los dos caracteres ő y ű que no están en Latin-1. Estos dos caracteres se pueden codificar correctamente en Latin-2, Windows-1250 y Unicode. Sin embargo, antes de que Unicode se volviera común en los clientes de correo electrónico, los correos electrónicos que contenían texto en húngaro a menudo tenían las letras ő y ű corruptas, a veces hasta el punto de ser irreconocibles. Es común responder a un correo electrónico corrupto con la frase sin sentido "Árvíztűrő tükörfúrógép" (literalmente "Máquina perforadora de espejos resistente a las inundaciones") que contiene todos los caracteres acentuados utilizados en húngaro.
Antes de la creación de la norma ISO 8859-2 en 1987, los usuarios de varias plataformas informáticas utilizaban sus propias codificaciones de caracteres , como AmigaPL en Amiga, Atari Club en Atari ST y Masovia, IBM CP852 , Mazovia y Windows CP1250 en IBM PC. Las empresas polacas que vendían las primeras computadoras DOS crearon sus propias formas mutuamente incompatibles de codificar caracteres polacos y simplemente reprogramaron las EPROM de las tarjetas de video (normalmente CGA , EGA o Hercules ) para proporcionar páginas de códigos de hardware con los glifos necesarios para el polaco, ubicados arbitrariamente sin referencia a dónde los habían colocado otros vendedores de computadoras.
La situación empezó a mejorar cuando, tras la presión de grupos académicos y de usuarios, la ISO 8859-2 se impuso como "estándar de Internet" con un apoyo limitado al software de los proveedores dominantes (hoy en día, en gran medida reemplazado por Unicode). Con los numerosos problemas causados por la variedad de codificaciones, incluso hoy en día algunos usuarios tienden a referirse a los caracteres diacríticos polacos como krzaczki ( [ˈkʂät͜ʂ.ki] , lit. "arbustos pequeños").
Mojibake se llama coloquialmente krakozyabry ( кракозя́бры [krɐkɐˈzʲæbrɪ̈] ) en ruso , que era y sigue siendo complicado por varios sistemas de codificación cirílico . [6] La Unión Soviética y la antigua Federación Rusa desarrollaron codificaciones KOI ( Kod Obmena Informatsiey , Код Обмена Информацией , que se traduce como "Código para el intercambio de información"). Esto comenzó con KOI7 de 7 bits solo cirílico , basado en ASCII pero con el latín y algunos otros caracteres reemplazados por letras cirílicas. Luego llegó la codificación KOI8 de 8 bits , que es una extensión ASCII que codifica letras cirílicas solo con octetos de bits altos correspondientes a códigos de 7 bits de KOI7. Es por esta razón que el texto KOI8, incluso en ruso, sigue siendo parcialmente legible después de quitar el octavo bit, lo que se consideró una gran ventaja en la era de los sistemas de correo electrónico que no son compatibles con 8BITMIME . Por ejemplo, las palabras " Школа русского языка " ( shkola russkogo yazyka ), cuando se codifican en KOI8 y pasan por el proceso de eliminación de bits altos, terminan siendo representadas como "[KOLA RUSSKOGO qZYKA". Con el tiempo, KOI8 adquirió diferentes versiones para ruso y búlgaro ( KOI8-R ), ucraniano ( KOI8-U ), bielorruso (KOI8-RU) e incluso tayiko (KOI8-T).
Mientras tanto, en Occidente, la página de códigos 866 admitía el ucraniano y el bielorruso , así como el ruso y el búlgaro en MS-DOS . Para Microsoft Windows , la página de códigos 1251 agregó compatibilidad con el serbio y otras variantes eslavas del cirílico .
Más recientemente, la codificación Unicode incluye puntos de código para prácticamente todos los caracteres en todos los idiomas, incluidos todos los caracteres cirílicos.
Antes de Unicode, era necesario hacer coincidir la codificación del texto con una fuente que usara el mismo sistema de codificación; no hacerlo producía un galimatías ilegible cuya apariencia específica variaba dependiendo de la combinación exacta de texto y codificación de fuente. Por ejemplo, intentar ver texto cirílico no Unicode usando una fuente limitada al alfabeto latino, o usando la codificación predeterminada ("occidental"), generalmente da como resultado un texto que consiste casi en su totalidad en vocales en mayúsculas con marcas diacríticas (por ejemplo, KOI8 " Библиотека " ( biblioteka , biblioteca) se convierte en "âÉÂÌÉÏÔÅËÁ", mientras que "Школа русского языка" ( shkola russkogo yazyka , escuela de idioma ruso) se convierte en "ûËÏÌÁ ÒÕÓÓËÏÇÏ ÑÚÙËÁ"). El uso de la página de códigos 1251 para ver texto en KOI8, o viceversa, da como resultado un texto ilegible que consta principalmente de letras mayúsculas (KOI8 y la página de códigos 1251 comparten la misma región ASCII, pero KOI8 tiene letras mayúsculas en la región donde la página de códigos 1251 tiene minúsculas, y viceversa).
Durante los primeros años del sector ruso de la World Wide Web, tanto KOI8 como Code Page 1251 eran comunes. Casi todos los sitios web ahora usan Unicode, pero a partir de noviembre de 2023, [update]se estima que el 0,35% de todas las páginas web en todo el mundo (incluidos todos los idiomas) todavía están codificadas en Code Page 1251, mientras que menos del 0,003% de los sitios todavía están codificados en KOI8-R. [7] [8] Aunque el estándar HTML incluye la capacidad de especificar la codificación para cualquier página web dada en su fuente, [9] esto a veces se descuida, lo que obliga al usuario a cambiar las codificaciones en el navegador manualmente.
En búlgaro, mojibake se suele llamar majmunica ( маймуница ), que significa "alfabeto de mono". En serbio , se llama đubre ( ђубре ), que significa " basura ". A diferencia de la antigua URSS, los eslavos del sur nunca usaron algo como KOI8, y la página de códigos 1251 era la codificación cirílica dominante antes de Unicode; por lo tanto, estos idiomas experimentaron menos problemas de incompatibilidad de codificación que el ruso. En la década de 1980, las computadoras búlgaras usaron su propia codificación MIK , que es superficialmente similar a (aunque incompatible con) CP866.
El croata , el bosnio , el serbio (las variedades que se separan del idioma serbocroata ) y el esloveno añaden al alfabeto latino básico las letras š, đ, č, ć, ž y sus contrapartes mayúsculas Š, Đ, Č, Ć, Ž (solo č/Č, š/Š y ž/Ž en esloveno; oficialmente, aunque se usan otras cuando es necesario, principalmente en nombres extranjeros, también). Todas estas letras están definidas en Latin-2 y Windows-1250 , mientras que solo algunas (š, Š, ž, Ž, Đ) existen en el sistema operativo predeterminado habitual Windows-1252 , y están allí debido a algunos otros idiomas.
Aunque Mojibake puede aparecer con cualquiera de estos caracteres, las letras que no están incluidas en Windows-1252 son mucho más propensas a errores. Por ello, incluso hoy en día, "šđčćž ŠĐČĆŽ" se suele mostrar como "šðèæž ŠÐÈÆŽ", aunque ð, È y Æ nunca se utilizan en los idiomas eslavos.
Cuando se limitan a ASCII básico (la mayoría de los nombres de usuario, por ejemplo), los reemplazos comunes son: š→s, đ→dj, č→c, ć→c, ž→z (las mayúsculas se escriben de forma análoga, con Đ→Dj o Đ→DJ según el uso de mayúsculas y minúsculas). Todos estos reemplazos introducen ambigüedades, por lo que la reconstrucción del original a partir de esa forma suele hacerse de forma manual si es necesario.
La codificación Windows-1252 es importante porque las versiones en inglés del sistema operativo Windows son las más difundidas, no las localizadas. [ cita requerida ] Las razones para esto incluyen un mercado relativamente pequeño y fragmentado, el aumento del precio de la localización de alta calidad, un alto grado de piratería de software (a su vez causado por el alto precio del software en comparación con los ingresos), lo que desalienta los esfuerzos de localización, y la gente que prefiere las versiones en inglés de Windows y otro software. [ cita requerida ]
El afán de diferenciar el croata del serbio, el bosnio del croata y el serbio, y ahora incluso el montenegrino de los otros tres, genera muchos problemas. Existen muchas localizaciones diferentes, que utilizan diferentes estándares y son de diferente calidad. No existen traducciones comunes para la gran cantidad de terminología informática que tiene su origen en el inglés. Al final, la gente utiliza préstamos lingüísticos ("kompjuter" para "ordenador", "kompajlirati" para "compilar", etc.) y, si no están acostumbrados a los términos traducidos, es posible que no entiendan lo que se supone que debe hacer alguna opción de un menú en función de la frase traducida. Por lo tanto, las personas que entienden inglés, así como las que están acostumbradas a la terminología inglesa (que son la mayoría, porque la terminología inglesa también se enseña principalmente en las escuelas debido a estos problemas) eligen regularmente las versiones originales en inglés de software no especializado.
Cuando se utiliza el alfabeto cirílico (para el macedonio y parcialmente para el serbio ), el problema es similar al de otros alfabetos basados en el alfabeto cirílico.
Las versiones más nuevas de Windows en inglés permiten cambiar la página de códigos (las versiones anteriores requieren versiones en inglés especiales con esta compatibilidad), pero esta configuración puede configurarse de forma incorrecta (y a menudo lo hacía). Por ejemplo, Windows 98 y Windows Me pueden configurarse con la mayoría de las páginas de códigos de un solo byte que no se escriben de derecha a izquierda , incluida la 1250, pero solo en el momento de la instalación.
Los sistemas de escritura de ciertas lenguas de la región del Cáucaso, incluidas las escrituras del georgiano y del armenio , pueden producir mojibake. Este problema es particularmente agudo en el caso de ArmSCII o ARMSCII, un conjunto de codificaciones de caracteres obsoletas para el alfabeto armenio que han sido reemplazadas por los estándares Unicode. ArmSCII no se usa ampliamente debido a la falta de soporte en la industria informática. Por ejemplo, Microsoft Windows no lo admite.
Otro tipo de mojibake ocurre cuando el texto codificado en una codificación de un solo byte se analiza erróneamente en una codificación de varios bytes, como una de las codificaciones para idiomas del este de Asia . Con este tipo de mojibake, se corrompen más de un carácter (normalmente dos) a la vez. Por ejemplo, si la palabra sueca kärlek está codificada en Windows-1252 pero decodificada usando GBK, aparecerá como "k鋜lek", donde " är " se analiza como "鋜". En comparación con el mojibake anterior, este es más difícil de leer, ya que faltan letras que no están relacionadas con las problemáticas å, ä u ö, y es especialmente problemático para palabras cortas que comienzan con å, ä u ö (por ejemplo, "än" se convierte en "鋘"). Dado que se combinan dos letras, el mojibake también parece más aleatorio (más de 50 variantes en comparación con las tres normales, sin contar las mayúsculas más raras). En algunos casos excepcionales, una cadena de texto completa que incluya un patrón de longitudes de palabras particulares, como la oración " Bush ocultó los hechos ", puede ser malinterpretada.
En vietnamita , el fenómeno se llama chữ ma ( Hán–Nôm : 𡨸魔, "caracteres fantasma") o loạn mã (del chino 乱码, luànmǎ ). Puede ocurrir cuando una computadora intenta decodificar texto codificado en UTF-8 como Windows-1258 , TCVN3 o VNI. En Vietnam, chữ ma se veía comúnmente en computadoras que ejecutaban versiones anteriores a Vista de Windows o teléfonos móviles baratos.
En Japón , mojibake es especialmente problemático, ya que existen muchas codificaciones de texto japonesas diferentes. Además de las codificaciones Unicode (UTF-8 y UTF-16), existen otras codificaciones estándar, como Shift-JIS (máquinas Windows) y EUC-JP (sistemas UNIX). Incluso hoy en día, tanto los japoneses como los extranjeros se encuentran con mojibake cuando intentan ejecutar software escrito para el mercado japonés.
En chino , el mismo fenómeno se llama Luàn mǎ ( Pinyin , Chino simplificado 乱码, Chino tradicional 亂碼, que significa 'código caótico'), y puede ocurrir cuando el texto computarizado está codificado en una codificación de caracteres chinos pero se muestra usando la codificación incorrecta. Cuando esto ocurre, a menudo es posible solucionar el problema cambiando la codificación de caracteres sin pérdida de datos. La situación es complicada debido a la existencia de varios sistemas de codificación de caracteres chinos en uso, siendo los más comunes: Unicode , Big5 y Guobiao (con varias versiones compatibles con versiones anteriores), y la posibilidad de que los caracteres chinos se codifiquen usando codificación japonesa.
Es relativamente fácil identificar la codificación original cuando luànmǎ aparece en las codificaciones Guobiao:
Otro problema en chino es que algunos caracteres raros o anticuados, muchos de los cuales todavía se utilizan en nombres de personas o lugares, no existen en algunas codificaciones. Algunos ejemplos son:
Los periódicos han abordado los caracteres faltantes de diversas maneras, incluyendo el uso de software de edición de imágenes para sintetizarlos mediante la combinación de otros radicales y caracteres, el uso de una imagen de las personalidades (en el caso de los nombres de las personas) o simplemente la sustitución de homófonos con la esperanza de que los lectores pudieran hacer la inferencia correcta.
Un efecto similar puede ocurrir en las escrituras brahmicas o índicas del sur de Asia , utilizadas en lenguas indoarias o índicas como el indostánico (hindi-urdu), el bengalí , el panyabí , el maratí y otras, incluso si la aplicación reconoce correctamente el conjunto de caracteres empleado. Esto se debe a que, en muchas escrituras índicas, las reglas por las que los símbolos de letras individuales se combinan para crear símbolos para sílabas pueden no ser entendidas correctamente por una computadora que no tenga el software apropiado, incluso si los glifos para las formas de las letras individuales están disponibles.
Un ejemplo de esto es el antiguo logotipo de Wikipedia , que intenta mostrar el carácter análogo a "wi" (la primera sílaba de "Wikipedia") en cada una de las muchas piezas del rompecabezas. La pieza del rompecabezas que debía llevar el carácter devanagari para "wi" solía mostrar el carácter "wa" seguido de una vocal modificadora "i" no emparejada , fácilmente reconocible como mojibake generado por una computadora no configurada para mostrar texto índico. [11] El logotipo rediseñado a partir de mayo de 2010 [ref]ha corregido estos errores.
La idea del texto simple requiere que el sistema operativo proporcione una fuente para mostrar los códigos Unicode. Esta fuente es diferente de un sistema operativo a otro para el cingalés y produce glifos ortográficamente incorrectos para algunas letras (sílabas) en todos los sistemas operativos. Por ejemplo, "reph", la forma corta de "r", es un diacrítico que normalmente va encima de una letra simple. Sin embargo, es incorrecto colocarlo encima de algunas letras como "ya" o "la" en contextos específicos. Para las palabras o nombres sánscritos heredados por los idiomas modernos, como कार्य, IAST: kārya , o आर्या, IAST: āryā , es adecuado colocarlo encima de estas letras. Por el contrario, en el caso de sonidos similares en idiomas modernos que resultan de sus reglas específicas, no se coloca en la parte superior, como en el caso de la palabra करणाऱ्या, IAST: karaṇāryā , una forma radical de la palabra común करणारा/री, IAST: karaṇārā/rī , en el idioma maratí . [12] Pero sucede en la mayoría de los sistemas operativos. Esto parece ser un fallo de la programación interna de las fuentes. En Mac OS e iOS, la combinación de muurdhaja l (l oscura) y 'u' y su forma larga producen formas incorrectas. [ cita requerida ]
Algunas escrituras índicas y derivadas de índicas, especialmente lao , no fueron admitidas oficialmente por Windows XP hasta el lanzamiento de Vista . [13] Sin embargo, varios sitios han creado fuentes que se pueden descargar de forma gratuita.
Debido a las sanciones occidentales [14] y la llegada tardía del soporte del idioma birmano a las computadoras, [15] [16] gran parte de la localización birmana temprana fue de cosecha propia sin cooperación internacional. El medio predominante de soporte birmano es a través de la fuente Zawgyi , una fuente que fue creada como una fuente Unicode pero que de hecho solo era parcialmente compatible con Unicode. [16] En la fuente Zawgyi, algunos puntos de código para la escritura birmana se implementaron como se especifica en Unicode , pero otros no. [17] El Consorcio Unicode se refiere a esto como codificaciones de fuentes ad hoc . [18] Con la llegada de los teléfonos móviles, los proveedores móviles como Samsung y Huawei simplemente reemplazaron las fuentes del sistema compatibles con Unicode con versiones Zawgyi. [15]
Debido a estas codificaciones ad hoc , las comunicaciones entre usuarios de Zawgyi y Unicode se verían como texto ilegible. Para solucionar este problema, los productores de contenido publicarían tanto en Zawgyi como en Unicode. [19] El gobierno de Myanmar designó el 1 de octubre de 2019 como el "Día de la Unión" para cambiar oficialmente a Unicode. [14] Se estimó que la transición completa demoraría dos años. [20]
En ciertos sistemas de escritura de África , el texto no codificado es ilegible. Los textos que pueden producir mojibake incluyen los del Cuerno de África , como la escritura ge'ez en Etiopía y Eritrea , utilizada para el amárico , el tigre y otros idiomas, y el idioma somalí , que emplea el alfabeto osmanya . En el sur de África , el alfabeto mwangwego se utiliza para escribir los idiomas de Malawi y el alfabeto mandombé se creó para la República Democrática del Congo , pero estos no son generalmente compatibles. Varios otros sistemas de escritura nativos de África occidental presentan problemas similares, como el alfabeto n'ko , utilizado para las lenguas mandinga en Guinea , y el silabario vai , utilizado en Liberia .
Otro idioma afectado es el árabe (ver más abajo), en el que el texto se vuelve completamente ilegible cuando las codificaciones no coinciden.
Los ejemplos de este artículo no tienen UTF-8 como configuración del navegador, porque UTF-8 es fácilmente reconocible, por lo que si un navegador admite UTF-8 debería reconocerlo automáticamente y no intentar interpretar algo más como UTF-8.
"se convierten en ", ", "y así sucesivamente.El 1 de octubre es el "Día de la Unión", cuando Myanmar adoptará oficialmente el nuevo sistema.... Microsoft y Apple ayudaron a otros países a estandarizar hace años, pero las sanciones occidentales hicieron que Myanmar saliera perdiendo.
Con el lanzamiento del Service Pack 2 de Windows XP, se admitieron scripts complejos, lo que hizo posible que Windows renderizara una fuente birmana compatible con Unicode como Myanmar1 (lanzada en 2005). ... Myazedi, BIT y, más tarde, Zawgyi, circunscribieron el problema de renderizado agregando puntos de código adicionales que estaban reservados para los idiomas étnicos de Myanmar. La reasignación no solo impide la compatibilidad futura con idiomas étnicos, sino que también da como resultado un sistema de mecanografía que puede ser confuso e ineficiente, incluso para usuarios experimentados. ... Huawei y Samsung, las dos marcas de teléfonos inteligentes más populares en Myanmar, están motivadas solo por capturar la mayor participación de mercado, lo que significa que admiten Zawgyi de fábrica.
Las fuentes Unicode estándar de Myanmar nunca se generalizaron a diferencia de la fuente Zawgyi, privada y parcialmente compatible con Unicode. ... Unicode mejorará el procesamiento del lenguaje natural
"UTF-8" técnicamente no se aplica a codificaciones de fuentes ad hoc como Zawgyi.
Esto dificulta la comunicación en plataformas digitales, ya que el contenido escrito en Unicode aparece ilegible para los usuarios de Zawgyi y viceversa. ... Para llegar mejor a sus audiencias, los productores de contenido en Myanmar suelen publicar tanto en Zawgyi como en Unicode en una sola publicación, sin mencionar el inglés u otros idiomas.
La definición del diccionario de mojibake en Wikcionario
Medios relacionados con Mojibake en Wikimedia Commons