¿Hay algún problema técnico con tener un nombre de dominio 'internacionalizado'?

En mi idioma hay numerosos caracteres que no están permitidos en el nombre de dominio estándar. Sin embargo, la mayoría de estos se pueden reemplazar fácilmente con equivalentes seguros (en su mayoría, dejar caer acentos se íconvierte en ietc.). Entonces, aunque a menudo hemos registrado ambos formularios (por ejemplo, timarit.isy el islandés apropiado tímarit.is), siempre hemos hecho que el formulario 'seguro' sea el predeterminado y el otro simplemente lo redirige a él.

Sin embargo, ahora estamos en la posición en que la sustitución es menos favorable (se æconvierte ae) y preferiríamos usar el nombre internacionalizado por defecto.

Mi pregunta es simplemente si hay algún problema conocido con esto. La incompatibilidad del navegador es lo primero que me viene a la mente, pero me preocupa igualmente que haya otras cosas que no me vienen a la mente.

GENEROSIDAD

Empecé una recompensa por esto para no tener que publicar una pregunta duplicada. Me gustaría saber si existen consecuencias prácticas al usar IDN con (1) FTP y (2) servidores / clientes de correo electrónico; y (3) ¿qué navegadores luchan con los dominios? (4) ¿Qué pasa con los dispositivos móviles? También (5) ha cambiado algo sobre el tema: hace casi un año desde que se hizo la pregunta.

Los motores de búsqueda generalmente no tienen ningún problema con los IDN (no puedo hablar por los demás, pero al menos ese es el caso de Google). Además de los problemas de su lado (mantenimiento, etc.) y del lado del usuario (problemas del navegador, que afortunadamente desaparecen a medida que más usuarios tienen navegadores modernos), no veo mucho problema.

Algunas de las cosas más generales y solo indirectamente relacionadas con los motores de búsqueda que vienen a la mente son:

• Algunos usuarios pueden tener problemas para vincularse a su contenido, especialmente si no tienen la distribución correcta del teclado, por lo que generalmente es una buena idea proporcionar una manera fácil para que los usuarios copien y peguen un enlace para su reutilización. Si proporciona un fragmento de HTML, asegúrese de utilizar la versión punycode del nombre de dominio para que no tenga problemas con las codificaciones de página.
• A veces es posible que desee utilizar varios nombres de dominio para detectar errores tipográficos (por ejemplo, timarit.is vs tímarit.is). Si hace eso, asegúrese de elegir un nombre de dominio preferido y use redirecciones 301 en todo el sitio a ese nombre de dominio.
• Si usa ASCII que no sea de 7 bits en parámetros de ruta, archivo o consulta, asegúrese de usar UTF-8 para eso. También asegúrese de que estén codificados correctamente para fragmentos de enlace (consulte el primer punto).

La codificación de caracteres de su sistema de gestión de contenido es un problema que viene a la mente. Además, si está promocionando su sitio web, muchas entradas de validación de URL probablemente se romperán en su URL.

(1) FTP

Parece que necesita un cliente FTP que pueda manejar IDN, ya que requiere un soporte especial. Según lo que he leído mientras investigaba esto, ese soporte parece ser generalizado y una característica común en todos los principales clientes FTP.

(2) servidores / clientes de correo electrónico;

Según el artículo de Wikipedia para Correo electrónico internacional , parece que el soporte de correo electrónico no está completo:

Dado que los estándares tradicionales de correo electrónico limitan todos los valores de encabezado de correo electrónico a caracteres ASCII solamente, es posible que la presencia de caracteres UTF-8 en los encabezados de correo electrónico disminuya la estabilidad y la fiabilidad del transporte de dicho correo electrónico. Esto se debe a que la mayoría, si no todos, los servidores de correo electrónico, al momento de escribir esto, no admiten estos caracteres.

Los miembros del IETF han propuesto un método mediante el cual el correo electrónico puede degradarse al "legado" de todos los formatos ASCII que todos los servidores de correo electrónico estándar deberían admitir. Este mecanismo de degradación cumple con el requisito de que el transporte de correo electrónico sea lo más robusto y confiable posible.

.

(3) ¿qué navegadores luchan con los dominios?

Parece que todos los principales navegadores admiten IDN y lo han hecho durante al menos dos años. El único problema real que puede tener es con navegadores antiguos que no admiten IDN. Pero dado que IE parece haberlo soportado desde que IE7 y la actualización de la base de usuarios de otros navegadores importantes rápidamente, esto debería ser un pequeño número de usuarios.

(4) ¿Qué pasa con los dispositivos móviles?

Buena pregunta. Parece que el nombre de dominio .mobi no admite IDN. No pude encontrar nada específico a los propios dispositivos pero encontré empresas alegando que tenían soluciones para los IDN en el móvil, así que estoy adivinando que el apoyo nativo no puede existir o no es completa.

(5) ha cambiado algo sobre el tema: ha pasado casi un año desde que se hizo la pregunta.

Algunos TLD específicos de cada país han agregado soporte y parece que los spammers han encontrado una manera de explotarlos . Pero eso es lo mismo que ha cambiado.

1. Precaristas o la competencia * se * comprar la versión latinizada de su nombre de dominio, con el tiempo.

   Entonces, si es de alguna importancia (o eso puede cobrar importancia con el tiempo), tendrá que comprar ambos .

2. Spammers y phishers .
   Unicode está lleno de personajes que se parecen mucho a los latinos.

   Solo están comenzando a usarlos en este momento, pero en algunos meses, los nombres innecesarios de IDN pueden comenzar a parecer falsos .

3. Los visitantes internacionales con un diseño de teclado no islandés podrían odiarte. Pero entonces, si no está planeando poner ese nombre en la tarjeta de presentación, puede que no sea tan importante.

De todos modos ... ☺.com debe ser el estado del arte del uso innecesario de IDN

Post-Scriptum: ¿ Adivina quién no admite IDN como ☺.com ? Stackexchange :)
Tuve que buscar el código xn a mano. : /

Intentamos usar la versión IDN del dominio como predeterminada, pero finalmente tuvimos problemas con algunos navegadores (incluido Firefox) y Adobe Reader, donde el nombre de dominio IDN acaba de ser destruido en la transferencia al complemento del navegador.

Así que ahora usamos el modo 'seguro' y el IDN simplemente hace una redirección 301 a él.