unicode - archivos - utf 8 sin bom c#

¿Qué diferencia hay entre UTF-8 y UTF-8 sin BOM? (20)

¿Qué diferencia hay entre UTF-8 y UTF-8 sin BOM ? ¿Cual es mejor?

¿Qué diferencia hay entre UTF-8 y UTF-8 sin BOM?

Respuesta corta: en UTF-8, una lista de materiales se codifica como los bytes EF BB BF al principio del archivo.

Respuesta larga:

Originalmente, se esperaba que Unicode fuera codificado en UTF-16 / UCS-2. El BOM fue diseñado para esta forma de codificación. Cuando tiene unidades de código de 2 bytes, es necesario indicar en qué orden están esos dos bytes, y una convención común para hacer esto es incluir el carácter U + FEFF como una "Marca de Orden de Byte" al comienzo de los datos. El carácter U + FFFE no está asignado permanentemente, por lo que su presencia se puede usar para detectar el orden de bytes incorrecto.

UTF-8 tiene el mismo orden de bytes independientemente de la endianness de la plataforma, por lo que no se necesita una marca de orden de bytes. Sin embargo, puede ocurrir (como la secuencia de bytes EF BB FF ) en los datos que se convirtieron a UTF-8 desde UTF-16, o como una "firma" para indicar que los datos son UTF-8.

¿Cual es mejor?

Sin. Como Martin Cote respondió, el estándar Unicode no lo recomienda. Causa problemas con software que no es compatible con BOM.

Una mejor manera de detectar si un archivo es UTF-8 es realizar una verificación de validez. UTF-8 tiene reglas estrictas sobre qué secuencias de bytes son válidas, por lo que la probabilidad de un falso positivo es insignificante. Si una secuencia de bytes se parece a UTF-8, probablemente lo sea.

Pregunta: ¿Qué diferencia hay entre UTF-8 y UTF-8 sin una lista de materiales? ¿Cual es mejor?

Aquí hay algunos extractos del artículo de Wikipedia sobre la marca de orden de bytes (BOM) que creo que ofrecen una respuesta sólida a esta pregunta.

Sobre el significado de la lista de materiales y UTF-8:

El estándar de Unicode permite la lista de materiales en UTF-8 , pero no requiere ni recomienda su uso. El orden de bytes no tiene significado en UTF-8, por lo que su único uso en UTF-8 es señalar al comienzo que el flujo de texto está codificado en UTF-8.

Argumento para NO usar una lista de materiales:

La principal motivación para no usar una lista de materiales es la compatibilidad con versiones anteriores de un software que no sea compatible con Unicode ... Otra motivación para no usar una lista de materiales es fomentar UTF-8 como la codificación "predeterminada".

Argumento PARA usar una lista de materiales:

El argumento para usar una lista de materiales es que, sin ella, se requiere un análisis heurístico para determinar qué carácter de codificación está utilizando un archivo. Históricamente, dicho análisis, para distinguir varias codificaciones de 8 bits, es complicado, propenso a errores y, a veces, lento. Hay varias bibliotecas disponibles para facilitar la tarea, como Mozilla Universal Charset Detector y International Components for Unicode.
Los programadores asumen erróneamente que la detección de UTF-8 es igualmente difícil (no es porque la gran mayoría de las secuencias de bytes no son válidas de UTF-8, mientras que las codificaciones que estas bibliotecas intentan distinguir permiten todas las posibles secuencias de bytes). Por lo tanto, no todos los programas compatibles con Unicode realizan dicho análisis y, en cambio, confían en la lista de materiales.
En particular, los compiladores e intérpretes de Microsoft , y muchas piezas de software en Microsoft Windows como el Bloc de notas no leerán correctamente el texto UTF-8 a menos que tenga solo caracteres ASCII o comience con la lista de materiales, y agregará una lista de materiales al inicio cuando se guarde texto como UTF-8. Google Docs agregará una lista de materiales cuando un documento de Microsoft Word se descargue como un archivo de texto sin formato.

Sobre cuál es mejor, CON O SIN LA BOM:

El IETF recomienda que si un protocolo (a) siempre usa UTF-8, o (b) tiene alguna otra forma de indicar qué codificación se está utilizando, entonces "DEBE prohibir el uso de U + FEFF como una firma".

Mi conclusión:

Utilice la lista de materiales solo si la compatibilidad con una aplicación de software es absolutamente esencial.

También tenga en cuenta que si bien el artículo de Wikipedia al que se hace referencia indica que muchas aplicaciones de Microsoft se basan en la lista de materiales para detectar correctamente el UTF-8, este no es el caso de todas las aplicaciones de Microsoft. Por ejemplo, como lo señaló @barlop , cuando se usa el Símbolo del sistema de Windows con UTF-8 ^† , los comandos de este type y more no esperan que la lista de materiales esté presente. Si la lista de materiales está presente, puede ser problemático como lo es para otras aplicaciones.

† El comando chcp ofrece soporte para UTF-8 ( sin la lista de materiales) a través de la página de códigos 65001 .

Citado en la parte inferior de la página de Wikipedia en BOM: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"El uso de una lista de materiales no es necesario ni recomendado para UTF-8, pero puede encontrarse en contextos donde los datos de UTF-8 se convierten de otras formas de codificación que usan una lista de materiales o donde la lista de materiales se usa como una firma de UTF-8"

Cuando desee mostrar información codificada en UTF-8, es posible que no tenga problemas. Declare, por ejemplo, un documento HTML como UTF-8 y tendrá todo lo que se muestra en su navegador que está contenido en el cuerpo del documento.

Pero este no es el caso cuando tenemos archivos de texto, CSV y XML, ya sea en Windows o Linux.

Por ejemplo, un archivo de texto en Windows o Linux, una de las cosas más fáciles que se pueda imaginar, no es (generalmente) UTF-8.

Guárdelo como XML y declare como UTF-8:

<?xml version="1.0" encoding="UTF-8"?>

No se mostrará (no se leerá) correctamente, incluso si se declara como UTF-8.

Tenía una cadena de datos que contenían letras en francés, que necesitaba ser guardada como XML para la sindicación. Sin crear un archivo UTF-8 desde el principio (cambiando las opciones en IDE y "Crear nuevo archivo") o agregando la lista de materiales al principio del archivo

$file="/xEF/xBB/xBF".$string;

No pude guardar las letras francesas en un archivo XML.

Debe tenerse en cuenta que para algunos archivos no debe tener la lista de materiales ni siquiera en Windows. Los ejemplos son SQL*plus o archivos VBScript . En el caso de que dichos archivos contengan una lista de materiales, obtendrá un error cuando intente ejecutarlos.

Es una pregunta antigua con muchas respuestas buenas, pero se debe agregar una cosa.

Todas las respuestas son muy generales. Lo que me gustaría agregar son ejemplos del uso de la lista de materiales que realmente causa problemas reales y, sin embargo, muchas personas no lo saben.

BOM rompe guiones

Los scripts de shell, los scripts de Perl, los scripts de Python, los scripts de Ruby, los scripts de Node.js o cualquier otro ejecutable que deba ser ejecutado por un intérprete, todos comienzan con una línea de shebang que se parece a uno de esos:

#!/bin/sh #!/usr/bin/python #!/usr/local/bin/perl #!/usr/bin/env node

Indica al sistema qué intérprete debe ejecutarse al invocar tal script. Si la secuencia de comandos está codificada en UTF-8, uno puede tener la tentación de incluir una lista de materiales al principio. Pero en realidad el "#!" Los personajes no son solo personajes. De hecho, son un número mágico que se compone de dos caracteres ASCII. Si coloca algo (como una lista de materiales) antes de esos caracteres, entonces el archivo se verá como si tuviera un número mágico diferente y eso puede causar problemas.

Ver Wikipedia, artículo: Shebang, sección: Número mágico :

Los caracteres shebang están representados por los mismos dos bytes en las codificaciones ASCII extendidas, incluyendo UTF-8, que se usa comúnmente para scripts y otros archivos de texto en los sistemas actuales similares a Unix. Sin embargo, los archivos UTF-8 pueden comenzar con la marca de orden de bytes (BOM) opcional; si la función "exec" detecta específicamente los bytes 0x23 y 0x21, entonces la presencia de la lista de materiales (0xEF 0xBB 0xBF) antes del shebang evitará que se ejecute el intérprete de script. Algunas autoridades recomiendan no usar la marca de orden de bytes en los scripts POSIX (similares a Unix), [14] por esta razón y para una mayor interoperabilidad y preocupaciones filosóficas. Además, una marca de orden de bytes no es necesaria en UTF-8, ya que la codificación no tiene problemas de endianidad; sólo sirve para identificar la codificación como UTF-8. [énfasis añadido]

BOM es ilegal en JSON

Ver RFC 7159, Sección 8.1 :

Las implementaciones NO DEBEN agregar una marca de orden de bytes al comienzo de un texto JSON.

BOM es redundante en JSON

No solo es ilegal en JSON, tampoco es necesario para determinar la codificación de caracteres porque hay formas más confiables de determinar sin ambigüedades tanto la codificación de caracteres como la endianness utilizada en cualquier flujo de JSON (consulte esta respuesta para obtener más detalles).

BOM rompe analizadores JSON

No solo es ilegal en JSON y no es necesario , en realidad rompe todo el software que determina la codificación utilizando el método presentado en RFC 4627 :

Determinando la codificación y endianness de JSON, examinando los primeros 4 bytes para el byte NUL:

00 00 00 xx - UTF-32BE 00 xx 00 xx - UTF-16BE xx 00 00 00 - UTF-32LE xx 00 xx 00 - UTF-16LE xx xx xx xx - UTF-8

Ahora, si el archivo comienza con BOM se verá así:

00 00 FE FF - UTF-32BE FE FF 00 xx - UTF-16BE FF FE 00 00 - UTF-32LE FF FE xx 00 - UTF-16LE EF BB BF xx - UTF-8

Tenga en cuenta que:

UTF-32BE no comienza con tres NUL, por lo que no será reconocido
UTF-32LE el primer byte no va seguido de 3 NUL, por lo que no será reconocido
UTF-16BE tiene solo 1 NUL en los primeros 4 bytes por lo que no será reconocido
UTF-16LE solo tiene 1 NUL en los primeros 4 bytes, por lo que no será reconocido

Dependiendo de la implementación, todos ellos pueden interpretarse incorrectamente como UTF-8 y luego interpretarse erróneamente o rechazarse como UTF-8 no válido, o no reconocerse en absoluto.

Además, si la implementación prueba JSON válido como lo recomiendo, rechazará incluso la entrada que de hecho está codificada como UTF-8 porque no comienza con un carácter ASCII <128 como debería de acuerdo con el RFC.

Otros formatos de datos

BOM en JSON no es necesario, es ilegal y rompe el software que funciona correctamente de acuerdo con el RFC. Debería ser un ingenuo no usarlo y, sin embargo, siempre hay personas que insisten en romper JSON mediante el uso de listas de materiales, comentarios, diferentes reglas de cotización o diferentes tipos de datos. Por supuesto, cualquier persona es libre de usar elementos como listas de materiales o cualquier otra cosa si la necesita, simplemente no lo llame JSON en ese momento.

Para otros formatos de datos que no sean JSON, observe cómo se ve realmente. Si las únicas codificaciones son UTF- * y el primer carácter debe ser un carácter ASCII inferior a 128, entonces ya tiene toda la información necesaria para determinar tanto la codificación como la endianidad de sus datos. Agregar listas de materiales incluso como una característica opcional solo lo haría más complicado y propenso a errores.

Otros usos de BOM

En cuanto a los usos fuera de JSON o scripts, creo que ya hay respuestas muy buenas aquí. Quería agregar información más detallada específicamente sobre los scripts y la serialización porque es un ejemplo de caracteres de la lista de materiales que causan problemas reales.

Esta pregunta ya tiene respuestas de un millón y uno y muchas de ellas son bastante buenas, pero quería intentar aclarar cuándo se debe o no usar una lista de materiales.

Como se mencionó, cualquier uso de UTF BOM (marca de orden de bytes) para determinar si una cadena es UTF-8 o no es una conjetura educada. Si hay metadatos adecuados disponibles (como charset="utf-8" ), entonces ya sabe lo que se supone que debe usar, pero de lo contrario deberá probar y hacer algunas suposiciones. Esto implica verificar si el archivo del que proviene una cadena comienza con el código de byte hexadecimal, EF BB BF.

Si se encuentra un código de byte correspondiente a la lista de materiales UTF-8, la probabilidad es lo suficientemente alta como para suponer que es UTF-8 y puede ir desde allí. Sin embargo, cuando se le obliga a hacer esta suposición, la verificación de errores adicionales durante la lectura sería una buena idea en caso de que algo salga confuso. Solo debe asumir que una lista de materiales no es UTF-8 (es decir, latin-1 o ANSI) si la entrada definitivamente no debería ser UTF-8 según su origen. Sin embargo, si no hay una lista de materiales, simplemente puede determinar si se supone que es UTF-8 mediante la validación de la codificación.

¿Por qué no se recomienda una lista de materiales?

El software que no es compatible con Unicode o que no cumple con las normas puede asumir que es latin-1 o ANSI y no eliminará la lista de materiales de la cadena, lo que obviamente puede causar problemas.
No es realmente necesario (solo compruebe si el contenido es compatible y use siempre UTF-8 como alternativa cuando no se pueda encontrar una codificación compatible)

¿Cuándo debería codificar con una lista de materiales?

Si no puede registrar los metadatos de otra manera (a través de una etiqueta de juego de caracteres o un meta del sistema de archivos) y los programas que se utilizan como BOM, debe codificar con una lista de materiales. Esto es especialmente cierto en Windows, donde generalmente se asume que cualquier cosa sin una lista de materiales utiliza una página de códigos heredada.La lista de materiales le dice a programas como Office que, sí, el texto de este archivo es Unicode; Aquí está la codificación utilizada.

Cuando se trata de eso, los únicos archivos con los que realmente tengo problemas son CSV. Dependiendo del programa, debe o no debe tener una lista de materiales. Por ejemplo, si está utilizando Excel 2007+ en Windows, debe codificarse con una lista de materiales si desea abrirlo sin problemas y no tener que recurrir a la importación de datos.

Hay al menos tres problemas al colocar una lista de materiales en archivos codificados en UTF-8.

Los archivos que no contienen texto ya no están vacíos porque siempre contienen la lista de materiales.
Los archivos que contienen texto que está dentro del subconjunto ASCII de UTF-8 ya no son ASCII porque la lista de materiales no es ASCII, lo que hace que algunas herramientas existentes se descompongan, y puede ser imposible para los usuarios reemplazar dichas herramientas heredadas.
No es posible concatenar varios archivos juntos porque ahora cada archivo tiene una lista de materiales al principio.

Y, como han mencionado otros, no es suficiente ni necesario tener una lista de materiales para detectar que algo es UTF-8:

No es suficiente porque puede suceder que una secuencia de bytes arbitraria comience con la secuencia exacta que constituye la lista de materiales.
No es necesario porque solo puede leer los bytes como si fueran UTF-8; si eso tiene éxito, es, por definición, válido UTF-8.

La lista de materiales de UTF-8 es una secuencia de bytes al comienzo de una secuencia de texto (EF BB BF) que permite al lector adivinar de manera más confiable que un archivo está codificado en UTF-8.

Normalmente, la lista de materiales se utiliza para señalar la endianness de una codificación, pero como la endianness es irrelevante para UTF-8, la lista de materiales es innecesaria.

De acuerdo con el estándar de Unicode , no se recomienda la lista de materiales para archivos UTF-8 :

2.6 Esquemas de codificación
... El uso de una lista de materiales no es necesario ni recomendado para UTF-8, pero puede encontrarse en contextos donde los datos de UTF-8 se convierten de otras formas de codificación que usan una lista de materiales o donde la lista de materiales se usa como una firma UTF-8 . Consulte la subsección "Marca de orden de bytes" en la Sección 16.8, Especiales , para obtener más información.

La lista de materiales tiende a boom (sin juego de palabras (sic)) en algún lugar, en algún lugar. Y cuando suena (por ejemplo, no es reconocido por los navegadores, editores, etc.), aparece como los caracteres extraños ï»¿ al inicio del documento (por ejemplo, archivo HTML, respuesta JSON , RSS , etc.) y causa el tipo de vergüenza como el reciente problema de codificación experimentado durante la charla de Obama en Twitter .

Es muy molesto cuando aparece en lugares difíciles de depurar o cuando se descuidan las pruebas. Así que es mejor evitarlo a menos que lo uses.

Las otras excelentes respuestas ya respondieron que:

No hay diferencia oficial entre UTF-8 y UTF-8 de BOM-ed.
Una cadena BOM-ed UTF-8 comenzará con los tres bytes siguientes. EF BB BF
Esos bytes, si están presentes, deben ignorarse al extraer la cadena del archivo / flujo.

Pero, como información adicional a esto, la lista de materiales para UTF-8 podría ser una buena manera de "oler" si una cadena se codificó en UTF-8 ... O podría ser una cadena legítima en cualquier otra codificación ...

Por ejemplo, los datos [EF BB BF 41 42 43] podrían ser:

La cadena legítima ISO-8859-1 "ï» ¿ABC "
La cadena legítima de UTF-8 "ABC"

Por lo tanto, si bien puede ser divertido reconocer la codificación de un contenido de un archivo mirando los primeros bytes, no debe confiar en esto, como se muestra en el ejemplo anterior.

Las codificaciones deben ser conocidas, no adivinadas.

Lo veo desde una perspectiva diferente. Creo que UTF-8 con BOM es mejor, ya que proporciona más información sobre el archivo. Uso UTF-8 sin BOM solo si tengo problemas.

Estoy usando varios idiomas (incluso Cyrillic ) en mis páginas durante mucho tiempo y cuando los archivos se guardan sin BOM y los vuelvo a abrir para editarlos con un editor (como también mencionó cherouvim ), algunos caracteres están dañados.

Tenga en cuenta que el Notepad clásico de Windows guarda automáticamente los archivos con una lista de materiales cuando intenta guardar un archivo recién creado con codificación UTF-8.

Personalmente guardo los archivos de scripts del lado del servidor (.asp, .ini, .aspx) con archivos BOM y .html sin BOM .

UTF-8 con BOM está mejor identificado. He llegado a esta conclusión por el camino difícil. Estoy trabajando en un proyecto donde uno de los resultados es un archivo CSV , incluidos los caracteres Unicode.

Si el archivo CSV se guarda sin una lista de materiales, Excel cree que es ANSI y que muestra un alboroto. Una vez que agrega "EF BB BF" al frente (por ejemplo, volviéndolo a guardar con el Bloc de notas con UTF-8; o el Bloc de notas ++ con UTF-8 con la lista de materiales), Excel lo abre bien.

El RFC 3629 recomienda la prefijación del carácter de la lista de materiales a los archivos de texto Unicode: "UTF-8, un formato de transformación de ISO 10646", noviembre de 2003 en http://tools.ietf.org/html/rfc3629 (esta última información se encuentra en: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )

UTF-8 con BOM solo ayuda si el archivo realmente contiene algunos caracteres que no son ASCII. Si está incluido y no hay ninguno, entonces posiblemente romperá las aplicaciones antiguas que de otra manera habrían interpretado el archivo como ASCII simple. Estas aplicaciones definitivamente fallarán cuando se encuentren con un carácter que no sea ASCII, por lo que, en mi opinión, la lista de materiales solo debe agregarse cuando el archivo puede, y ya no debe interpretarse como ASCII simple.

Edición: Solo quiero dejar en claro que prefiero no tener la lista de materiales, agregarla si se rompe alguna basura vieja y no es posible reemplazar esa aplicación heredada.

No hagas nada, espera un BOM para UTF8.

UTF-8 sin BOM no tiene BOM, lo que no lo hace mejor que UTF-8 con BOM, excepto cuando el consumidor del archivo necesita saber (o se beneficiaría de saber) si el archivo está codificado en UTF-8 o no.

La lista de materiales suele ser útil para determinar el carácter endian de la codificación, que no es necesario para la mayoría de los casos de uso.

Además, la lista de materiales puede ser un ruido / dolor innecesario para aquellos consumidores que no lo saben o no les importa, y pueden generar confusión en el usuario.

Una diferencia práctica es que si escribe un script de shell para Mac OS X y lo guarda como UTF-8, obtendrá la respuesta:

#!/bin/bash: No such file or directory

en respuesta a la línea shebang especificando qué shell desea usar:

#!/bin/bash

Si guarda como UTF-8, ningún BOM (por ejemplo, en BBEdit ) estará bien.

Como se mencionó anteriormente, UTF-8 con BOM puede causar problemas con software que no es compatible con BOM (o compatible). Una vez edité archivos HTML codificados como UTF-8 + BOM con el KompoZer basado en Mozilla , ya que un cliente requería el programa WYSIWYG .

Invariablemente, el diseño se destruiría al guardar. Me tomó un tiempo para juguetear con esto. Estos archivos luego funcionaron bien en Firefox, pero mostraron una peculiaridad de CSS en Internet Explorer destruyendo el diseño, nuevamente. Después de juguetear con los archivos CSS vinculados durante horas, descubrí que a Internet Explorer no le gustaba el archivo HTML de BOMfed. Nunca más.

Además, acabo de encontrar esto en Wikipedia:

Los caracteres shebang están representados por los mismos dos bytes en las codificaciones ASCII extendidas, incluyendo UTF-8, que se usa comúnmente para scripts y otros archivos de texto en los sistemas actuales similares a Unix. Sin embargo, los archivos UTF-8 pueden comenzar con la marca de orden de bytes (BOM) opcional; si la función "exec" detecta específicamente los bytes 0x23 0x21, entonces la presencia de la lista de materiales (0xEF 0xBB 0xBF) antes del shebang evitará que se ejecute el intérprete de script. Algunas autoridades recomiendan no usar la marca de orden de bytes en los scripts POSIX (similares a Unix), [15] por este motivo y para una mayor interoperabilidad y preocupaciones filosóficas

De http://en.wikipedia.org/wiki/Byte-order_mark :

La marca de orden de bytes (BOM) es un carácter Unicode que se utiliza para indicar la endianidad (orden de bytes) de un archivo de texto o flujo. Su punto de código es U + FEFF. El uso de la lista de materiales es opcional y, si se usa, debe aparecer al comienzo de la secuencia de texto. Más allá de su uso específico como indicador de orden de bytes, el carácter de la lista de materiales también puede indicar en cuál de las varias representaciones de Unicode se codifica el texto.

Siempre utilizando una lista de materiales en su archivo se asegurará de que siempre se abra correctamente en un editor que admita UTF-8 y BOM.

Mi verdadero problema con la ausencia de BOM es el siguiente. Supongamos que tenemos un archivo que contiene:

abc

Sin BOM, esto se abre como ANSI en la mayoría de los editores. Entonces, otro usuario de este archivo lo abre y agrega algunos caracteres nativos, por ejemplo:

abg-αβγ

Vaya, ahora el archivo aún está en ANSI y adivina qué, "αβγ" no ocupa 6 bytes, sino 3. Esto no es UTF-8 y esto causa otros problemas más adelante en la cadena de desarrollo.

Las preguntas frecuentes de la marca de orden de bytes (BOM) de Unicode proporcionan una respuesta concisa:

P: ¿Cómo debo tratar con las listas de materiales?
R: Aquí hay algunas pautas a seguir:
Un protocolo particular (por ejemplo, las convenciones de Microsoft para archivos .txt) puede requerir el uso de la lista de materiales en ciertas secuencias de datos Unicode, como los archivos. Cuando necesite cumplir con dicho protocolo, utilice una lista de materiales.
Algunos protocolos permiten listas de materiales opcionales en el caso de texto sin etiquetar. En esos casos,
Cuando se sabe que un flujo de datos de texto es texto simple, pero de codificación desconocida, la lista de materiales se puede usar como una firma. Si no hay una lista de materiales, la codificación podría ser cualquier cosa.
Cuando se sabe que un flujo de datos de texto es texto Unicode simple (pero no qué endian), la lista de materiales se puede usar como una firma. Si no hay una lista de materiales, el texto debe interpretarse como big-endian.
Algunos protocolos orientados a bytes esperan caracteres ASCII al principio de un archivo. Si se utiliza UTF-8 con estos protocolos, debe evitarse el uso de la lista de materiales como la firma de la forma de codificación.
Cuando se conoce el tipo preciso de flujo de datos (por ejemplo, Unicode big-endian o Unicode little-endian), no se debe utilizar la lista de materiales. En particular, cuando se declara que un flujo de datos es UTF-16BE, UTF-16LE, UTF-32BE o UTF-32LE, no debe utilizarse una lista de materiales.

UTF con BOM es mejor si usa UTF-8 en archivos HTML, si usa cirílico serbio, latín serbio, alemán, húngaro o algún otro idioma exótico en la misma página. Esa es mi opinión (30 años de informática e industria de TI).