La tecla de acceso 'n' lleva a la navegación de la página. Ir al inicio del contenido.
Este documento es una traducción. En caso de discrepancias o errores, la única versión normativa es el último original en inglés. Los derechos de autor originales corresponden al W3C, como puede verse al final de la página.
Traductor: Spanish Translation Team, Spanish Translation US.
Audiencia de destino: creadores de contenidos, gerentes de proyectos web y usuarios generales que deseen conocer los puntos fundamentales sin quedar abrumados con detalles altamente técnicos acerca de lo que sucede detrás de escena al utilizar caracteres distintos de ASCII en direcciones web. En este artículo se tratan los nombres de dominio IDN y los identificadores IRI, y se describe de qué manera funcionan en forma combinada.
Una dirección web se utiliza para indicar un recurso en la Web, por ejemplo, una página web. Desarrollos recientes permiten agregar caracteres distintos de ASCII a las direcciones web. En este artículo se proporciona una introducción de nivel avanzado acerca del funcionamiento de estos elementos. Está destinado a creadores de contenidos y usuarios generales que busquen comprender los conceptos básicos sin demasiados detalles técnicos. Por cuestiones de simplicidad, se utilizarán ejemplos basados en HTML y HTTP. También se describirá cómo es el funcionamiento tanto en relación con el nombre de dominio como con la demás información sobre la ruta en una página web.
En la actualidad, las direcciones web habitualmente se expresan mediante un Identificador uniforme de recurso o URI. La sintaxis de los URI, definida en la RFC 3986 STD 66 (Identificador uniforme de recurso, Uniform Resource Identifier, URI: Sintaxis genérica) fundamentalmente limita las direcciones web a una pequeña cantidad de caracteres: básicamente, sólo letras mayúsculas o minúsculas del alfabeto inglés, numerales europeos y una pequeña cantidad de símbolos.
El motivo original de esta limitación era favorecer la capacidad de transcripción y facilitar su uso tanto en sistemas informáticos como en las comunicaciones en las que no interviniera la computadora, evitar conflictos con los caracteres utilizados convencionalmente como delimitadores en torno a los URI y facilitar la carga mediante el empleo de los mecanismos disponibles para la mayoría de los usuarios de Internet.
Tanto las expectativas del usuario como la utilización de Internet han avanzado desde entonces y hoy existe una creciente necesidad de permitir el uso de caracteres de cualquier idioma en las direcciones web. Una dirección web en el propio idioma y alfabeto del usuario es más fácil de crear, memorizar, transcribir, interpretar, acertar y vincular. También es importante en términos de reconocimiento de marca. Esto, a su vez, resulta favorable para el negocio y la comunicación, y facilita la tarea de encontrar lo que uno busca. En definitiva, es mejor para la Web.
Imagine, por ejemplo, que todas las direcciones web estuvieran escritas en japonés katakana, tal como se muestra en el siguiente ejemplo. Si usted no fuera japonés, ¿le resultaría fácil reconocer el contenido del sitio o su propietario, escribir la dirección en el navegador, escribir el URI en un anotador, etc.?
Varios desarrollos recientes comienzan a hacerlo posible.
En este documento, se hará referencia a las direcciones web que permiten el uso de caracteres pertenecientes a una amplia variedad de sistemas de escritura como Identificadores de recursos internacionales o IRI. Existen cuatro requerimientos principales para el funcionamiento de los IRI:
Varias especificaciones y formatos de documentos ya soportan IRI. Entre los ejemplos se incluye HTML 4.0, identificadores de sistema XML 1.0, el atributo href XLink, tipo de dato anyURI de XML Schema, etc. También se mencionará más adelante que los principales navegadores ya cuentan con soporte para el uso de IRI.
Lamentablemente, no tantos protocolos permiten la trasmisión de los IRI sin efectuar modificaciones. Generalmente exigen que se especifique la dirección con los caracteres ASCII definidos por los URI. No obstante, existen cuestiones específicas sobre este tema que se describirán brevemente en este artículo.
El cuarto requerimiento exige la correspondencia de la secuencia de caracteres con el objetivo, ya sea que dichos caracteres estén representados o no por la misma codificación, es decir, bytes. Esto se resuelve mediante el empleo de UTF-8 como broker.
Se empleará la siguiente dirección web ficticia en la mayoría de los ejemplos incluidos en esta página:
Se trata de un IRI simple, compuesto por tres partes.
http:// contiene información acerca del esquema a utilizar. Tenga en cuenta que aquí no se utilizan actualmente caracteres distintos de ASCII.JP納豆.例.jp, es el nombre de dominio.Con respecto a los requerimientos 2 a 4, existe una solución para el nombre del dominio y otra solución diferente para la ruta. Analizaremos cada uno de estos escenarios.
La asignación y administración de los nombres de dominio está a cargo de distintas organizaciones de registro de nombres de dominio distribuidas por todo el mundo.
El IETF acordó en marzo de 2003 un enfoque estándar para el tratamiento de nombres de dominio plurilingües. Este enfoque se define en las siguientes especificaciones RFC: 3490, 3491, 3492 y 3454, y está basado en Unicode 3.2. Se hace referencia a este tema con el término Nombre de dominio internacionalizado o IDN.
El encargado de registrar los nombres de dominio prepara la lista de caracteres que una persona puede solicitar que se utilicen en su país o dominio de nivel superior. Sin embargo, cuando alguien solicita un nombre de dominio con dichos caracteres, en realidad, se les asigna el equivalente al nombre de dominio mediante una representación denominada punycode.
Punycode es una forma de representar puntos de código Unicode únicamente mediante caracteres ASCII.
Se incluye un ejemplo algo más detallado en la siguiente sección, pero, en resumen, la dirección web deseada se almacena en un enlace a un documento o se escribe en la barra de direcciones del cliente con los caracteres nativos correspondientes. Pero cuando un usuario hace clic sobre el enlace o inicia una solicitud de cualquier otra forma, el agente de usuario (es decir, el navegador u otro cliente que solicite el recurso) debe convertir cualquier carácter nativo del sistema de escritura de la dirección web en representaciones punycode.
(Desde ya que si el agente de usuario no puede hacerlo, siempre es posible expresar directamente la ubicación en el punycode, aunque no resulta muy amigable para el usuario).
A continuación se examinan los pasos necesarios para resolver un Nombre de dominio internacionalizado desde el usuario hasta la identificación del recurso. (Tenga en cuenta que aquí se analiza únicamente de qué manera se procesa el nombre de dominio. La información sobre la ruta recibe un tratamiento diferente y se describe más adelante).
El usuario hace clic sobre un hipervínculo o ingresa el identificador IRI en la barra de direcciones de un agente de usuario. En este punto, el IRI contiene caracteres distintos de ASCII que podrían pertenecer a cualquier codificación de caracteres. Este es el nombre de dominio que aparece en el ejemplo anterior.
JP納豆.例.jp
Si la secuencia que representa el nombre de dominio no está en Unicode, el agente de usuario convertirá dicha secuencia a Unicode. Luego realiza algunas funciones de normalización en la secuencia para eliminar cualquier ambigüedad que pudiera existir en el texto codificado en Unicode.
Las tareas de normalización incluyen, entre otras posibilidades, convertir caracteres de mayúscula a minúscula, reducir las representaciones alternativas (por ejemplo, convertir caracteres kana de ancho medio a ancho completo), eliminar caracteres prohibidos (por ejemplo, espacios), etc.
Como paso siguiente, el agente de usuario convierte cada una de las etiquetas (es decir, partes de texto entre puntos) de la secuencia Unicode a una representación punycode. Se agrega un marcador especial ("xn--") al comienzo de cada etiqueta con caracteres distintos de ASCII para mostrar que la etiqueta no era ASCII originalmente. El resultado final no es muy fácil para el usuario, pero representa de manera precisa la secuencia original de caracteres y utiliza únicamente los caracteres permitidos anteriormente para nombres de dominio. El ejemplo anterior ahora se ve así:
xn--jp-cd2fp15c.xn--fsq.jp
Observe que si bien los caracteres ASCII "JP" en mayúscula al comienzo del nombre de dominio aparecen ahora en minúscula, aún es posible reconocerlos. Todo carácter ASCII existente en una etiqueta aparece, en primer lugar, seguido por un guión simple y luego por una representación basada en ASCII de cualquier carácter distinto de ASCII.
Luego el servidor del nombre de dominio convierte el punycode en una dirección IP numérica (tal como se resuelve cualquier otro nombre de dominio).
Por último, el agente de usuario envía la solicitud correspondiente a la página. Debido a que punycode no contiene caracteres fuera de aquellos permitidos habitualmente para protocolos como HTTP, no se presentan inconvenientes en la transmisión de la dirección. Debería simplemente coincidir con un nombre de dominio registrado.
Tenga en cuenta que la mayoría de los códigos de países de dominio de nivel superior, por ejemplo, el .jp al final de JP納豆.例.jp, por el momento se deben escribir en caracteres latinos. Sin embargo, desde 2010 la IANA ha comenzado a incorporar progresivamente códigos de país internacionalizados para dominios de nivel superior, como مصر. para Egipto y .рф para Rusia.
En la práctica, resulta razonable registrar dos nombres para su dominio. Uno en su sistema de escritura nativo y el otro, empleando simplemente caracteres ASCII comunes. El último resultará más fácil de recordar y más sencillo para aquellos que no lean ni escriban en su idioma. Por ejemplo, podría adicionalmente registrar una transcripción del japonés en sistema de escritura latino, como en el siguiente ejemplo:
http://JPnatto.rei.jp/Si bien las autoridades de registro de dominios pueden acordar la aceptación de nombres de dominio en un formato y codificación específicos (punycode basado en ASCII), los nombres de rutas con sistemas de escritura múltiples identifican recursos ubicados en distintos tipos de plataformas cuyos sistemas de archivos utilizan varias codificaciones diferentes y continuarán haciéndolo en el futuro. Esto hace que sea mucho más difícil procesar la ruta que el nombre de dominio.
Luego de tratar el tema del nombre de dominio mediante el uso de punycode, ahora se debe analizar la ruta de un identificador IRI. En el Estándar propuesto por el IETF RFC 3987 (Identificadores de recursos internacionales, Internationalized Resource Identifiers, IRI) se define cómo tratar este tema.
Ya existe un mecanismo en la especificación de identificadores URI para la representación de caracteres distintos de ASCII en URI. Se representan los bytes básicos mediante un mecanismo de escape que se conoce como "percent-escaping" (en la especificación, se utiliza el término no tan común "percent-encoding"). Por lo tanto, en la página que está leyendo en este momento, codificada en UTF-8, podríamos representar el nombre de archivo 引き割り.html del ejemplo anterior como se muestra al final de este párrafo. Lo que se ve son números de dos dígitos en formato hexadecimal precedidos por el signo %. Estos números representan los bytes utilizados para codificar los caracteres japoneses en UTF-8 de la secuencia. Cada uno de estos caracteres está representado por 3 bytes que se transforman en tres escapes "percent-escapes".
%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html
Además de que esto no resulta nada fácil para el usuario, hay una cuestión aún más importante. Otra persona podría querer seguir el mismo enlace desde una página que usa una codificación Shift-JIS en lugar de UTF-8. En ese caso, si se utilizara el método percent-escaping para transformar los (mismos) caracteres de la dirección para que se adecuen a los requerimientos del identificador URI, los escapes deberían estar basados en los bytes que representan 引き割り.html en la codificación Shift-JIS. Existen sólo dos bytes por carácter japonés en Shift-JIS, y son bytes distintos de aquellos que se utilizan en UTF-8. Por lo tanto, se obtendría una secuencia de escape de bytes totalmente diferente, tal como se muestra a continuación.
%88%F8%82%AB%8A%84%82%E8.html
Aquí se muestra que si bien el mecanismo de escape URI permite especificar la dirección en japonés, el resultado real variará de acuerdo con la página de origen. Entonces, ¿cómo es posible saber cómo hacer la conversión a una secuencia de caracteres que coincida con el nombre del recurso tal como lo expresa el sistema en el que reside?
La mayor dificultad aquí consiste en que no existen metadatos relacionados con la codificación que se puedan asociar con las secuencias de URI para indicar qué caracteres representan. Aun si dicha información estuviera disponible, el servidor debería soportar una cantidad total de conversiones extremadamente alta para transformar las secuencias entrantes a la codificación correspondiente.
Y no sólo eso, sino que además el sistema de archivos en el que efectivamente reside el recurso podría exponer el nombre del archivo mediante una codificación completamente diferente, por ejemplo, EUC-JP. Si ese fuera el caso, la secuencia básica de bytes que representa el nombre del archivo tal como lo conoce el sistema sería nuevamente diferente. Entonces, ¿cómo es posible saber que todas estas secuencias de bytes se refieren al mismo recurso?
La especificación IRI emplea Unicode como broker. Indica que, antes de la conversión a escapes, el identificador IRI se debe convertir a UTF-8. Con respecto a los IDN, si el protocolo exige una conversión, será el agente de usuario el responsable de realizar dicha modificación cuando se realiza una solicitud de recurso.
El servidor también deberá reconocer los caracteres Unicode en la dirección web entrante y convertirlos a la codificación efectivamente utilizada para los recursos.
(Recuerde que ya se ha tratado el tema del nombre de dominio del IRI mediante la utilización de IDN. En la especificación IRI, las reglas, en general, se aplican sólo a la ruta de la dirección web plurilingüe.)
Ahora se analizará lo que hace el cliente para enviar la parte de la ruta de una dirección web a un servidor HTTP. Esta es la ruta de la dirección web del ejemplo anterior:
/dir1/引き割り.htmlCuando el usuario hace clic en un hipervínculo o ingresa el identificador IRI en la barra de direcciones de un agente de usuario, la dirección puede estar en cualquier tipo de codificación de caracteres, pero habitualmente se conoce dicha codificación.
Si es el usuario quien ingresa la secuencia o si se almacena en una codificación distinta a Unicode, se convierte a Unicode, se normaliza mediante la Forma C de Normalización Unicode y se codifica en UTF-8.
Luego el agente de usuario convierte los bytes distintos de ASCII en escapes percent-escapes. El ejemplo anterior ahora se ve así:
/dir1/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.htmlLa secuencia ahora se muestra en formato URI y será aceptable para protocolos como HTTP. Observe cómo los caracteres ASCII "dir1" y ".html" simplemente se trasmiten sin cambio alguno, ya que están codificados de la misma manera tanto en ASCII como en UTF-8.
El agente de usuario envía la solicitud correspondiente a la página.
Cuando dicha solicitud llega al servidor, ocurre una de las siguientes alternativas:
Hasta aquí se han descrito los conceptos básicos. Existen secciones adicionales de la especificación en las que se tratan temas más específicos, entre otros, cómo procesar texto bidireccional en identificadores IRI.
Aquí se muestra la primera parte del encabezado HTTP para la solicitud de página generada por el ejemplo anterior. Muestra el nombre deI host como nombre de dominio IDN y la ruta mediante un escape percent-escaping cuando corresponde:
GET /dir1/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html HTTP/1.1 Host: xn--jp-cd2fp15c.xn--fsq.jp User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 …
Distintos organismos de gestión de nombres de dominio ya ofrecen registro de nombres de dominio internacionalizados. Entre ellos se incluyen proveedores de dominio para países de nivel superior como .cn, .jp, .kr, etc., y dominios globales de nivel superior como .info, .org y .museum.
Las últimas versiones de los principales navegadores, como Internet Explorer 7, Firefox, Mozilla, Netscape, Opera y Safari, ofrecen soporte a nivel cliente para nombres de dominio IDN. Únicamente funciona en Internet Explorer 6 si se descarga un plug-in (en las páginas de soporte de Microsoft se muestran algunas sugerencias). Esto significa que se pueden usar los IDN en valores href o en la barra de direcciones, y el navegador convertirá el nombre de dominio IDN a punycode y buscará al host.
Se puede realizar un control básico para asegurarse de que los IDN funcionen correctamente en el sistema mediante esta verificación rápida.
Hasta el día de hoy, ha sido siempre un obstáculo que Internet Explorer no incluyera soporte nativo para IDN en vista de su inmensa participación en el mercado. Si bien existen distintos plug-in disponibles, no todos saben cómo instalarlos o bien no pueden o no desean hacerlo. No obstante, IE7 o sus versiones posteriores, que sí soportan nombres de dominio IDN, con el tiempo remplazarán a la mayoría de las instalaciones IE6.
Se debe tener en cuenta que, a modo de solución alternativa hasta que el soporte para nombres de dominio IDN alcance un desarrollo más amplio, los creadores de contenidos que buscan señalar un recurso mediante un IDN podrían escribir el texto del enlace en caracteres nativos e incluir una representación punycode en el atributo href. De esta forma, se garantiza que el usuario pueda acceder al recurso independientemente de la plataforma que utilice.
En IE7, Firefox y Mozilla, es posible desactivar el soporte para IDN en caso de que el usuario deseara hacerlo.
Uno de los problemas vinculados con el soporte para IDN en navegadores es que puede favorecer la adquisición de información confidencial en forma fraudulenta (phishing) mediante lo que se conoce como "ataque homógrafo". Por lo tanto, la mayoría de los navegadores que cuentan con soporte para IDN también incluyen ciertos resguardos para proteger a los usuarios de dichas actividades ilegales.
Para alertar al usuario acerca de un posible ataque homógrafo, los navegadores generalmente muestran el identificador URI en la barra de direcciones y en la barra de estado mediante punycode en lugar de los caracteres Unicode originales. El usuario debe verificar siempre la barra de direcciones una vez que se carga la página, o la barra de estado antes de hacer clic en un enlace. Sin embargo, se debe tener presente que:
Los distintos navegadores utilizan diferentes estrategias para determinar si el identificador URI se debe mostrar en Unicode o en punycode.
Si se muestra una dirección como punycode, no necesariamente significa que se trata de un sitio falso, simplemente el usuario debe tener cautela. Queda a criterio del usuario decidir probar y descubrir si se debe evitar visitar dicho sitio o no.
La detección de posibles ataques homógrafos, en general, es tan solo una parte del mecanismo general que emplea un navegador para detectar si un sitio es fraudulento o no.
En Internet Explorer 7 se muestra la dirección como punycode cuando se cumple una de las siguientes condiciones:
El nombre de dominio contiene un carácter perteneciente a un sistema de escritura no utilizado en los idiomas incluidos en las preferencias de idioma del usuario. Los idiomas que utilizan el sistema de escritura latino se dividen en inglés (sólo ASCII) y otros (para los que cualquier carácter latino distinto de ASCII resulte válido). Por ejemplo, bäcker.com no funcionará si las preferencias de idioma del usuario incluyen únicamente inglés, pero sí funcionará si se incluye el idioma alemán (incluso francés, por ejemplo, ya que los caracteres acentuados no son específicos de un idioma).
Una etiqueta en el nombre de dominio (es decir, una secuencia de caracteres entre puntos) contiene caracteres de una combinación de sistemas de escritura que no aparecen juntos en un solo idioma. Por ejemplo, el nombre de dominio ελληνικάрyccĸий.org se mostrará como punycode, porque los caracteres griegos no se pueden combinar con cirílicos en una sola etiqueta. Por otro lado, ελληνικά.рyccĸий.org sería correcto. Se debe tener en cuenta que también es aceptable una combinación de japonés kanji y kana, por ejemplo, 全国温泉ガイド.jp.
IE7 permite que un IDN se muestre como Unicode si se combinan caracteres ASCII con un solo sistema de escritura diferente tomado de una lista específica. Se debe tener en cuenta que el cirílico no es uno de dichos sistemas de escritura, por lo que pаypаl.com (donde los caracteres 'a' pertenecen al bloque de caracteres cirílicos y no latinos) se mostraría como punycode.
Vincular el comportamiento a la lista de idiomas incluidos en las preferencias del navegador también implica que un idioma que no figura en la lista estándar provista por IE siempre generará punycode. Por ejemplo, el idioma amhárico en un texto etíope se mostrará como punycode aun si se incorporara am en las preferencias del navegador. (Afortunadamente, hasta el momento no parece haber ningún registro que otorgue nombres IDN en amhárico).
De todas maneras, algunos nombres de dominio fraudulentos pueden colarse a través de esta red de recaudos. En ese caso, la protección normal de IE7 contra este tipo de actividades ilegales intervendría para comparar el dominio con los sitios informados. Sin embargo, IE7 también puede "aplicar heurísticas adicionales para determinar si el nombre de dominio resulta visualmente ambiguo". Esto resulta muy útil cuando dentro del mismo sistema de escritura las letras son visualmente similares.
Además de mostrar los IDN sospechosos en la barra de direcciones como punycode, IE7 también utiliza la Barra de información para advertir al usuario acerca de posibles peligros. También emplea un ícono que se activa mediante un clic ubicado al final de la barra de direcciones para notificar al usuario cuando una URL contiene caracteres distintos de ASCII. Además, muestra la barra de direcciones en todas las ventanas.
Firefox 2.x emplea un enfoque diferente. Únicamente muestra nombres de dominio en Unicode para ciertos dominios de nivel superior incluidos en una lista aprobada o registro. Firefox selecciona Dominios de nivel superior (TLD) para los que existen políticas aplicables a aquellos nombres de dominio autorizados para ser registrados, y luego se basa en el proceso de registro para crear nombres IDN seguros. En el sitio de Mozilla, se muestra una lista de dominios TLD soportados. Si un IDN pertenece a un dominio TLD que no figura en la lista, la dirección web aparecerá en formato punycode en la barra de direcciones y de estado. En algunos casos, la política de dominios TLD incluye reglas acerca de cómo manejar caracteres visualmente similares dentro del set de caracteres autorizados.
Además, los IDN que contienen caracteres particulares (por ejemplo, fracción-barra) se tratan como si fueran sospechosos, aún dentro de dominios TLD confiables, y hacen que la etiqueta se muestre como punycode.
Opera 9.x utiliza un enfoque similar al de Firefox, pero su implementación es ligeramente diferente. Oficialmente, sólo muestra nombres de dominio en Unicode para dominios TLD aprobados que figuren en opera6.ini, un archivo que se actualiza de manera automática.
Para aquellos TLD que no estén en la lista, Opera permite que los nombres de dominio utilicen caracteres Latin 1, es decir, caracteres latinos con acentos soportados por los idiomas de Europa Occidental. Todos los nombres de dominio restantes se muestran como punycode.
En la realidad, las pruebas indican que actualmente Opera muestra muchos caracteres como Unicode, independientemente de si un dominio TLD figura o no en la lista de dominios aprobados. Una excepción es el sistema de escritura Devanagari, que se muestra como punycode en caso de que el dominio TLD no aparezca en la lista.
No obstante, Opera también muestra ciertas combinaciones de sistemas de escritura como punycode. Las pruebas confirmaron este punto para combinaciones de caracteres griegos y cirílicos con caracteres latinos.
Además, la lista de caracteres ilegales de Opera es algo más extensa que la lista oficial IDNA. Algunos IDN, si bien se muestran como punycode en otros navegadores, se consideran completamente ilegales en Opera.
Safari 9.x proporciona una lista de sistemas de escritura que el usuario puede editar y que el sistema permite mostrar de manera nativa en los nombres de dominio. Si un carácter que aparece en un nombre de dominio no pertenece a un sistema de escritura de esta lista, el identificador URI se muestra como punycode.
Al momento de escribir, la lista inicial de elementos aprobados incluye árabe, armenio, bopomofo, índigena_canadiense, devanagari, deseret, gujarati, gurmukhi, hangul, han, hebreo, hiragana, katakana_o_hiragana, katakana, latín, tamil, tai y yi. Los sistemas de escritura como el cirílico, el cheroqui y el griego quedan específicamente excluidos, porque contienen caracteres que se confunden fácilmente con los caracteres latinos.
Si se vacía la lista de elementos aprobados, cualquier carácter distinto de ASCII hace que la dirección se muestre como punycode.
Mozilla 1.7x muestra todos los IDN como punycode.
Ejemplos. Existe una página de prueba que puede utilizar para verificar cómo muestra su navegador los IDN en la barra de estado. Consulte también la página que muestra resultados para distintos navegadores.
Otros temas vinculados con la práctica de phishing y soluciones a nivel de registro. Los organismos de registro deben tratar algunos aspectos potenciales sobre el control de estas prácticas ilegales e incluirlos en sus políticas para el registro de nombres IDN.
Algunos organismos de registro deben evaluar cuidadosamente cómo manejar formas equivalentes de escribir la misma palabra. Por ejemplo, la palabra "hindi" se puede escribir en Devanagari como हिंदी (mediante un anusvara) o हिन्दी (mediante un glifo especial para NA).
Una situación similar se observa respecto del uso de caracteres simplificados o tradicionales en el sistema de escritura chino han.
Se presenta otra cuestión cuando dos caracteres o combinaciones de caracteres dentro de un solo sistema de escritura tienen una apariencia muy similar, como es el caso de la letra KA க y el dígito uno ௧ en idioma tamil que resultan imposibles de distinguir. En otros casos, las marcas diacríticas adheridas a los caracteres pueden ser muy difíciles de distinguir en tamaños de fuente pequeños.
Por otro lado, en un solo registro también se pueden dar situaciones de caracteres similares que posiblemente puedan confundirse entre sí en distintos sistemas de escritura. Por ejemplo, tamil y malayo son dos sistemas de escritura índicos diferentes que se pueden procesar mediante el mismo registro, y la letra KA க (U+0B95) en idioma tamil es muy similar a la letra KA ക (U+0D15) en idioma malayo. Otro ejemplo son las implicancias que reviste registrar la etiqueta ера (que utiliza únicamente caracteres cirílicos) versus epa (que usa únicamente caracteres latinos) para un dominio TLD como .museum en el que es preciso trabajar con múltiples sistemas de escritura. Si más de un solicitante pudiera registrarlas en forma independiente, generaría gran confusión.
En algunos casos estos escenarios se pueden documentar a modo de reglas que pueden tomar y aplicar los agentes de usuario para la detección de phishing. Sin embargo, en general es más recomendable resolver estos temas al momento del registro.
Un enfoque a nivel de registro consiste en decidir qué caracteres (es decir, puntos Unicode) de determinado idioma se permitirán durante el registro. Estas listas se denominan tablas de idiomas y las desarrollan los registros en colaboración con organismos especializados en cuestiones de idiomas. Por ejemplo, el organismo especializado en idioma indio puede autorizar el uso de la letra KA க (U+0B95) del tamil, pero no del dígito uno ௧ (U+0BE7) en nombres de dominio .in, y así evitar el conflicto.
Otro enfoque a nivel de registro consiste en crear tablas de variantes y capacidades de registro de variantes. Dichas tablas de variantes indican qué caracteres se consideran visualmente confusos en determinados idiomas o sistemas de escritura seleccionados. Si un nombre de dominio contiene un carácter de este tipo, entonces la versión del nombre de dominio que contenga el carácter alternativo quedará automáticamente reservada para el registrante. Por ejemplo, si el nombre de dominio solicitado (el “dominio principal”) contiene la letra KA க (U+0BE7) del idioma tamil, el sistema de registro puede generar una variante del nombre de dominio y colocar la letra KA ക (U+0D15) del idioma malayo en lugar de la letra KA del tamil. Es posible prohibir todas las variantes identificadas en forma automática (ya sea prohibir su registro o su creación) como parte de un paquete vinculado con el nombre principal registrado.
El Consorcio Unicode también está desarrollando un informe técnico denominado Cuestiones de seguridad de Unicode en el que se describen temas relacionados con prácticas ilegales utilizando nombres IDN y se incluyen recomendaciones para su tratamiento.
El proceso de conversión para las partes de los IRI vinculados con la ruta ya cuenta con soporte nativo en las últimas versiones de IE7, Firefox, Opera, Safari y Google Chrome.
En Internet Explorer 6 funciona si se encuentra activada la opción Herramientas>Opciones de Internet>Opciones avanzadas>Enviar direcciones URL en UTF-8. Esto significa que los enlaces en HTML o las direcciones escritas en la barra de direcciones del navegador se convertirán correctamente en aquellos agentes de usuario. Esto no funciona automáticamente en Firefox 2 (aunque es posible lograr resultados si el IRI y el nombre del recurso tienen la misma codificación), pero aquellos usuarios con conocimientos técnicos pueden activar una opción para obtener este tipo de soporte (configurar network.standard-url.encode-utf8 como verdadero en about:config).
Sin embargo, que se pueda encontrar al recurso en el servidor, es otra cuestión. Si el archivo del sistema se encuentra en UTF-8, no debería haber problemas. Si este no fuera el caso y no hubiera un mecanismo disponible para convertir direcciones de UTF-8 a la codificación correspondiente, la solicitud fallará.
Servidores como IIS y Apache 2 generalmente exponen los archivos como UTF-8 en Windows y Mac OS X. Los usuarios de Unix y Linux pueden almacenar nombres de archivos en UTF-8 o utilizar el módulo mod_fileiri antes mencionado. La versión 1 del servidor Apache, no expone nombres de archivos como UTF-8.
Se puede realizar un control básico para constatar si funciona para su cliente y recurso mediante esta verificación rápida.
Tenga en cuenta que, mientras que las cuestiones básicas pueden funcionar correctamente, existen ciertos aspectos algo más complicados del soporte para identificadores IRI, como el procesamiento de textos bidireccionales en árabe o hebreo, cuya implementación puede requerir mayor dedicación.
En la actualidad, se están debatiendo algunas mejoras necesarias en materia de especificaciones para nombres IDN e identificadores IRI. Por ejemplo, es necesario ampliar el rango de caracteres Unicode que se pueden utilizar en nombres de dominio para cubrir versiones posteriores de Unicode y permitir la combinación de caracteres al final de las etiquetas en sistemas de escritura de derecha a izquierda.
Dinos qué piensas (en inglés).
Traducido del inglés con fecha 2008-05-09. Traducción modificada por última vez el 2010-10-13 09:17 GMT.
Para ver el historial de cambios del documento, busque article-idn-and-iri en la bitácora de internacionalización.
Copyright © 2005-2010 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
@webi18n
Noticias de la página de inicio