Mojibake ( japonés :文字化け; IPA: [mod͡ʑibake] , "transformación de caracteres") es el texto confuso o galimatías que es el resultado de la decodificación del texto utilizando una codificación de caracteres no deseada . [1] El resultado es una sustitución sistemática de símbolos por otros completamente ajenos, a menudo procedentes 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 no válida. Un reemplazo también puede implicar 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 la diferente codificación de longitud constante (como en las codificaciones asiáticas de 16 bits frente a las europeas de 8 bits) o al uso de codificaciones de longitud variable (en particular, UTF-8 y UTF-16 ).
La representación fallida de glifos debido a fuentes faltantes o a 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 correcto manejo de errores por parte del software.
Para reproducir correctamente el texto original 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 de destino deben ser los mismos). Como mojibake es el caso de incumplimiento entre estos, se puede lograr manipulando los datos en sí o simplemente volviéndolos a etiquetar.
Mojibake se ve a menudo con datos de texto que han sido etiquetados con una codificación incorrecta; es posible que ni siquiera esté etiquetado, sino que se mueva entre computadoras con diferentes codificaciones predeterminadas. 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 familias de sistemas operativos y en parte a las especializaciones de codificaciones heredadas para diferentes sistemas de escritura de 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, utiliza 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 hay otras configuraciones regionales involucradas: el mismo texto almacenado como UTF-8 aparece como "譁�蟄怜喧縺�" si se interpreta como Shift-JIS, como "æ–‡å—化ã '" si se interpreta como occidental , o (por ejemplo) como "鏂囧瓧鍖栥亼" si se interpreta como en una configuración regional de GBK (China continental).
Si no se especifica la codificación, le corresponde al software decidirlo por otros medios. Dependiendo del tipo de software, la solución típica es la configuración o la heurística de detección de conjuntos de caracteres . Ambos son propensos a hacer predicciones erróneas.
La codificación de 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 supuesta es sistemáticamente incorrecta para 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 utilizar una marca de orden de bytes , pero para el código fuente y otro texto legible por máquina, muchos analizadores no toleran esto. Otro es almacenar la codificación como metadatos en el sistema de archivos. Los sistemas de archivos que admiten atributos de archivos extendidos pueden almacenarlo como user.charset. [3] Esto también requiere soporte en el software que quiera aprovecharlo, pero no moleste 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 juegos 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 utilizando las metaetiquetas del documento HTML que se utilizan para sustituir por encabezados HTTP faltantes si el servidor no se puede configurar para enviar los encabezados HTTP adecuados; ver codificaciones de caracteres en HTML .
Mojibake también ocurre cuando la codificación se especifica incorrectamente. Esto sucede a menudo entre codificaciones 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 cumple con el estándar ISO; Esto afectó especialmente al software que se ejecutaba bajo otros sistemas operativos como Unix .
De las codificaciones que todavía se usan comúnmente, muchas se originaron al tomar ASCII y agregarlo encima; como resultado, estas codificaciones son parcialmente compatibles entre sí. Ejemplos de esto incluyen Windows-1252 e ISO 8859-1. Por lo tanto, las personas pueden confundir el conjunto de codificación ampliado que están utilizando con ASCII simple.
Cuando hay capas de protocolos, cada uno de los cuales intenta especificar la codificación basándose en información diferente, la información menos segura puede resultar 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 se puede comunicar al cliente de tres formas:
http-equivo charset) o el encodingatributo de una declaración XML . Esta es la codificación en la que el autor pretendía guardar el archivo en particular.El hardware mucho más antiguo suele estar diseñado para admitir solo un juego de caracteres y, por lo general, el juego de caracteres no se puede modificar. La tabla de caracteres contenida en el firmware de la pantalla se adaptará para que tenga caracteres para el país en el que se venderá el dispositivo y, por lo general, la tabla difiere de un país a otro. Como tal, 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 les hace mostrar texto no estándar; las primeras versiones de Microsoft Windows y Palm OS , por ejemplo, se localizan por país y solo admite estándares de codificación relevantes para el país en el que se venderá la versión localizada y mostrará 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 compatibilidad con versiones anteriores de US-ASCII . UTF-8 también tiene la capacidad de ser reconocido directamente mediante un algoritmo simple, por lo que un software bien escrito debería poder evitar mezclar UTF-8 con otras codificaciones.
La dificultad para resolver una instancia de mojibake varía dependiendo de la aplicación dentro de la cual ocurre y las causas del mismo. Dos de las aplicaciones más comunes en las que puede aparecer mojibake son los navegadores web y los procesadores de texto . Los navegadores y procesadores de textos modernos suelen admitir una amplia gama de codificaciones de caracteres. Los navegadores a menudo permiten al usuario cambiar la configuración de codificación de su motor de renderizado sobre la marcha, mientras que los procesadores de texto le permiten al usuario seleccionar la codificación adecuada al abrir un archivo. Es posible que los usuarios necesiten algo de prueba y error para encontrar la codificación correcta.
El problema se complica más cuando ocurre en una aplicación que normalmente no admite una amplia gama de codificación de caracteres, como en un juego de computadora que no es 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 que Mojibake aparezca 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 de cada 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, el usuario tendría que utilizar aplicaciones de representación de fuentes de terceros.
Mojibake en los textos en inglés generalmente aparece en signos de puntuación, como guiones largos (—), guiones cortos (–) y comillas (“,”,','), pero rara vez en textos de caracteres, ya que la mayoría de las codificaciones concuerdan con ASCII en el 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 interpretará como una de las codificaciones de Europa occidental ( CP1252 o ISO 8859-1 ). Si se itera utilizando CP1252, esto puede llevar a £, £, £, £etc.
De manera similar, la comilla simple derecha ('), cuando se codifica en UTF-8 y se decodifica usando Windows-1252, se convierte en ’, ’, ’y así sucesivamente.
En épocas más antiguas, algunas computadoras tenían codificaciones específicas del proveedor, lo que provocaba discrepancias también en el texto en inglés.Las computadoras de 8 bits de la marca Commodore usaban codificación PETSCII , particularmente notable por invertir las mayúsculas y minúsculas en comparación con el ASCII estándar . Las impresoras PETSCII funcionaron bien en otras computadoras de la época, pero invirtieron el formato de todas las letras. Los mainframes IBM utilizan la codificación EBCDIC , que no coincide en absoluto con ASCII.
Los alfabetos de las lenguas germánicas del norte , catalán , finlandés , francés , alemán , italiano , portugués y español, son todos extensiones del alfabeto latino . Los caracteres adicionales suelen ser los que se corrompen, lo que hace que los textos sean ligeramente ilegibles con mojibake:
… y sus homólogos en mayúsculas, si corresponde.
Estos son idiomas para los que se ha utilizado el juego de caracteres ISO 8859-1 (también conocido como Latin 1 u Western ). Sin embargo, ISO 8859-1 ha quedado obsoleto debido a dos estándares en competencia, el Windows-1252 compatible con versiones anteriores y el ISO 8859-15 ligeramente modificado . Ambos añaden el signo 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 signo del euro, que reemplaza al signo de moneda raramente utilizado (¤). Sin embargo, con la llegada de UTF-8 , mojibake se ha vuelto más común en ciertos escenarios, por ejemplo, intercambio de archivos de texto entre computadoras 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 mediante un algoritmo simple, por lo que un software bien escrito debería poder 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 compatibles con 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 obvio 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, que produce "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 finlandés, por otro lado, utiliza con frecuencia vocales repetidas en palabras como hääyö ("noche de bodas"), lo que puede hacer que el texto corrupto sea muy difícil de leer (por ejemplo, hääyö aparece como "hääyö"). El islandés tiene diez caracteres posiblemente confusos 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 usa deformación (literalmente "deformación") y en portugués se usa desformatação (literalmente "deformar").
Algunos usuarios transliteran su escritura cuando usan una computadora, ya sea omitiendo los signos 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 hay diéresis disponibles. 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 están asociados con el danés arcaico y pueden usarse en broma. Sin embargo, los dígrafos son útiles para comunicarse con otras partes del mundo. Por ejemplo, el futbolista noruego Ole Gunnar Solskjær tenía su apellido escrito "SOLSKJAER" en su uniforme cuando jugaba en el Manchester United .
Un artefacto de UTF-8 malinterpretado como ISO 8859-1 , " Ring meg nå " traducido como "Ring meg nÃ¥", se vio en 2014 en una estafa de SMS dirigida a Noruega. [5]
Los usuarios de idiomas de Europa central y oriental también pueden verse afectados. Debido a que la mayoría de las computadoras no estaban conectadas a ninguna red entre mediados y finales de la década de 1980, había 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 "cartas basura". El húngaro ha sido particularmente susceptible ya que contiene las letras acentuadas á, é, í, ó, ú, ö, ü (todas presentes en el conjunto de caracteres Latin-1), además de 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 inundaciones") que contiene todos los caracteres acentuados utilizados en húngaro.
Antes de la creación de 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 (típicamente 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 comenzó a mejorar cuando, después de la presión de grupos académicos y de usuarios, ISO 8859-2 triunfó como el "estándar de Internet" con soporte limitado del software de los proveedores dominantes (hoy reemplazado en gran medida 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] , literalmente "pequeños arbustos").
Mojibake se llama coloquialmente krakozyabry ( кракозя́бры [krɐkɐˈzʲæbrɪ̈] ) en ruso , lo cual fue 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 en cirílico , basado en ASCII pero con caracteres latinos y algunos otros reemplazados por letras cirílicas. Luego vino 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 eliminar el octavo bit, lo que se consideraba una gran ventaja en la era de los sistemas de correo electrónico no conscientes de 8BITMIME . Por ejemplo, las palabras " Школа русского языка " shkola russkogo yazyka , codificadas en KOI8 y luego pasadas por el proceso de eliminación de bits altos, terminan representadas como "[KOLA RUSSKOGO qZYKA". Con el tiempo, KOI8 adquirió diferentes sabores 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 ucraniano y bielorruso , así como ruso/ búlgaro en MS-DOS . Para Microsoft Windows , la página de códigos 1251 agregó soporte para 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 de todos los idiomas del mundo, incluidos todos los caracteres cirílicos.
Antes de Unicode, era necesario hacer coincidir la codificación del texto con una fuente utilizando el mismo sistema de codificación. No hacerlo produjo un galimatías ilegible cuya apariencia específica variaba dependiendo de la combinación exacta de codificación de texto y codificación de fuentes. Por ejemplo, intentar ver texto cirílico no Unicode utilizando una fuente limitada al alfabeto latino, o utilizando la codificación predeterminada ("occidental"), normalmente da como resultado un texto que consta casi exclusivamente de vocales con signos diacríticos (por ejemplo, KOI8 " Библиотека " ( biblioteka , biblioteca) se convierte en "âÉÂÌÉÏÔÅËÁ", mientras que "Школа русского языка" 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 confuso 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 la página de códigos 1251 eran comunes. Casi todos los sitios ahora usan Unicode, pero en noviembre de 2023, [actualizar]se estima que el 0,35% de todas las páginas web en todo el mundo (todos los idiomas incluidos) todavía están codificadas en la página de códigos 1251, mientras que KOI8-R es menos del 0,003%. [7] [8] Aunque el estándar HTML incluye la capacidad de especificar la codificación para cualquier página web determinada 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 , el mojibake a menudo se llama majmunica ( маймуница ), que significa "[alfabeto] del 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 allí 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 usaban su propia codificación MIK , que es superficialmente similar (aunque incompatible con) CP866.
El croata , el bosnio , el serbio (las variedades secesionistas del idioma serbocroata ) y el esloveno añaden al alfabeto latino básico las letras š, đ, č, ć, ž, y sus contrapartes mayúsculas Š, Đ, Č, Ć, Ž (sólo č/Č, š/Š y ž/Ž en esloveno; oficialmente, aunque se utilizan otros cuando es necesario, principalmente también en nombres extranjeros). Todas estas letras están definidas en Latin-2 y Windows-1250 , mientras que solo algunas (š, Š, ž, Ž, Đ) existen en el sistema operativo predeterminado Windows-1252 , y están ahí 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 lo tanto, incluso hoy en día, "šđčćž ŠĐČĆŽ" se muestra a menudo como "šðèæž ŠÐÈÆŽ", aunque ð, È y Æ nunca se usan en lenguas eslavas.
Cuando se limita a ASCII básico (la mayoría de los nombres de usuario, por ejemplo), los reemplazos comunes son: š→s, đ→dj, č→c, ć→c, ž→z (formas mayúsculas análogas, con Đ→Dj o Đ→DJ dependiendo del caso de la palabra). Todos estos reemplazos introducen ambigüedades, por lo que la reconstrucción del original a partir de dicho formulario generalmente se realiza manualmente si es necesario.
La codificación Windows-1252 es importante porque las versiones en inglés del sistema operativo Windows son las más extendidas, no las localizadas. [ cita necesaria ] Las razones de esto incluyen un mercado relativamente pequeño y fragmentado, un 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), que desalienta los esfuerzos de localización, y personas que prefieren las versiones en inglés de Windows y otro software. [ cita necesaria ]
El impulso para diferenciar al croata del serbio, al bosnio del croata y al serbio, y ahora incluso al montenegrino de los otros tres, crea muchos problemas. Hay muchas localizaciones diferentes, que utilizan diferentes estándares y de diferente calidad. No existen traducciones comunes para la gran cantidad de terminología informática que se origina en inglés. Al final, la gente usa préstamos en inglés ("kompjuter" para "computadora", "kompajlirati" para "compilar", etc.), y si no están acostumbrados a los términos traducidos, es posible que no entiendan cuál es alguna opción en un menú. se supone que debe hacer según la frase traducida. Por lo tanto, las personas que entienden inglés, así como aquellos que están acostumbrados 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 escritura cirílica (para macedonio y parcialmente serbio ), el problema es similar al de otras escrituras basadas en cirílico.
Las versiones más recientes de Windows en inglés permiten cambiar la página de códigos (las versiones anteriores requieren versiones especiales en inglés con este soporte), pero esta configuración puede estar configurada incorrectamente, y a menudo lo estaba. Por ejemplo, Windows 98 y Windows Me se pueden configurar para la mayoría de las páginas de códigos de un solo byte que no son de derecha a izquierda , incluido 1250, pero sólo 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 el armenio , pueden producir mojibake. Este problema es particularmente grave 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 utiliza mucho 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 los idiomas de Asia oriental . Con este tipo de mojibake, más de un personaje (normalmente dos) se corrompe a la vez. Por ejemplo, si la palabra sueca kärlek está codificada en Windows-1252 pero se decodifica 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 no relacionadas con las problemáticas å, ä o ö, y es especialmente problemático para palabras cortas que comienzan con å, ä o ö (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 raros, una cadena de texto completa que incluye un patrón de longitudes de palabras determinadas, como la frase " Bush ocultó los hechos ", puede malinterpretarse.
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, el chữ ma se veía comúnmente en computadoras que ejecutaban versiones de Windows anteriores a Vista o en 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 hasta el día de hoy, tanto japoneses como no japoneses suelen encontrar 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 un texto computarizado está codificado en una codificación de caracteres chinos pero se muestra usando una 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 se complica 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 utilizando la codificación japonesa.
Es relativamente fácil identificar la codificación original cuando luànmǎ aparece en las codificaciones Guobiao:
Un problema adicional en chino ocurre cuando caracteres raros o anticuados, muchos de los cuales todavía se usan en nombres personales o de lugares, no existen en algunas codificaciones. Ejemplos de esto son:
Los periódicos han abordado los caracteres faltantes de diversas maneras, incluido el uso de software de edición de imágenes para sintetizarlos combinando otros radicales y personajes; usando una imagen de las personalidades (en el caso de los nombres de las personas), o simplemente sustituyendo homófonos con la esperanza de que los lectores puedan hacer la inferencia correcta.
Un efecto similar puede ocurrir en las escrituras brahmicas o índicas del sur de Asia , utilizadas en lenguas indo-arias o índicas como el indostaní (hindi-urdu), el bengalí , el punjabi , el marathi y otros, incluso si el conjunto de caracteres empleado es reconocido adecuadamente por la aplicación. Esto se debe a que, en muchas escrituras índicas, las reglas mediante las cuales los símbolos de letras individuales se combinan para crear símbolos para sílabas pueden no ser entendidas correctamente por una computadora que carece del software apropiado, incluso si los glifos para las formas de 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 en mayo de 2010 [árbitro]ha solucionado estos errores.
La idea del texto sin formato requiere que el sistema operativo proporcione una fuente para mostrar códigos Unicode. Esta fuente es diferente de un sistema operativo a otro para Singhala y genera glifos ortográficamente incorrectos para algunas letras (sílabas) en todos los sistemas operativos. Por ejemplo, 'reph', la forma abreviada de 'r', es un signo diacrítico que normalmente va encima de una letra simple. Sin embargo, está mal ir encima de algunas letras como 'ya' o 'la' en contextos específicos. Para palabras o nombres sánscritos heredados de lenguas modernas, como कार्य, IAST: kārya , o आर्या, IAST: āryā , es conveniente ponerlo encima de estas letras. Por el contrario, para sonidos similares en lenguas modernas que resultan de sus reglas específicas, no se coloca en la parte superior, como la palabra करणाऱ्या, IAST: karaṇāryā , una forma raíz de la palabra común करणारा/री, IAST: karaṇārā/rī , en el idioma marathi . [12] Pero sucede en la mayoría de los sistemas operativos. Esto parece ser un fallo de programación interna de las fuentes. En Mac OS e iOS, la combinación muurdhaja l (l oscura) y 'u' y su forma larga producen formas incorrectas. [ cita necesaria ]
Algunas secuencias de comandos índicas y derivadas de índicas, sobre todo Lao , no fueron admitidas oficialmente por Windows XP hasta el lanzamiento de Vista . [13] Sin embargo, varios sitios han creado fuentes de descarga 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 inicial del birmano 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 se creó como fuente Unicode pero que en realidad 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 de dispositivos 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 los usuarios de Zawgyi y Unicode se mostrarían como texto confuso. Para solucionar este problema, los productores de contenido realizarían publicaciones tanto en Zawgyi como en Unicode. [19] El gobierno de Myanmar designó el 1 de octubre de 2019 como "Día U" para cambiar oficialmente a Unicode. [14] Se estimó que la transición completa tardarí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 aquellos 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 mandombe se creó para la República Democrática del Congo , pero generalmente no son compatibles. Varios otros sistemas de escritura nativos de África occidental presentan problemas similares, como el alfabeto N'Ko , utilizado para las lenguas mandingas 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 otra cosa como UTF-8.
"se convierten en ", "y "así sucesivamente.El 1 de octubre es el "Día U", cuando Myanmar adoptará oficialmente el nuevo sistema... Microsoft y Apple ayudaron a otros países a estandarizar hace años, pero las sanciones occidentales significaron que Myanmar salió perdiendo.
Con el lanzamiento del service pack 2 de Windows XP, se admitieron secuencias de comandos complejas, lo que hizo posible que Windows representara una fuente birmana compatible con Unicode, como Myanmar1 (lanzada en 2005).
... Myazedi, BIT y más tarde Zawgyi, circunscribieron el problema de representación agregando puntos de código adicionales que estaban reservados para las lenguas étnicas de Myanmar.
La nueva asignación no sólo impide el soporte futuro de idiomas étnicos, sino que también da como resultado un sistema de mecanografía que puede resultar confuso e ineficiente, incluso para usuarios experimentados.
... Huawei y Samsung, las dos marcas de teléfonos inteligentes más populares en Myanmar, están motivados únicamente por capturar la mayor cuota de mercado, lo que significa que apoyan a Zawgyi desde el primer momento.
Las fuentes Unicode estándar de Myanmar nunca se incorporaron a la corriente principal, 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.
Dificulta la comunicación en plataformas digitales, ya que el contenido escrito en Unicode aparece confuso 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