Há algum problema técnico em ter um nome de domínio 'internacionalizado'?

No meu idioma, existem vários caracteres que não são permitidos no nome de domínio padrão. No entanto, a maioria destes pode ser facilmente substituídos por equivalentes de seguros (acentos principalmente caindo ítorna ietc.). Portanto, embora muitas vezes registremos os dois formulários (por exemplo, timarit.iso islandês adequado tímarit.is), sempre tornamos o formulário "seguro" o padrão e o outro apenas o redireciona para ele.

No entanto, estamos agora na posição em que a substituição é menos favorável ( ætorna-se ae) e preferimos usar o nome internacionalizado por padrão.

Minha pergunta é simplesmente se há algum problema conhecido com isso? A incompatibilidade do navegador vem à mente, mas estou igualmente preocupada com outras coisas que não vêm à mente.

RECOMPENSA

Comecei uma recompensa por isso, para não precisar postar uma pergunta duplicada. Eu gostaria de saber se existem consequências práticas usando IDNs com (1) FTP e (2) servidores / clientes de email; e (3) quais navegadores lutam com os domínios? (4) E os dispositivos móveis? Também (5) tudo mudou sobre o assunto - faz quase um ano desde que a pergunta foi feita.

Os mecanismos de pesquisa geralmente não têm problemas com os IDNs (não posso falar pelos outros, mas pelo menos é o caso do Google). Além dos problemas do seu lado (manutenção etc.) e do usuário (problemas do navegador - que felizmente desaparecem à medida que mais usuários têm navegadores modernos), não vejo muitos problemas.

Algumas das coisas mais gerais e indiretamente relacionadas a mecanismos de pesquisa que vêm à mente são:

• Alguns usuários podem ter problemas para vincular seu conteúdo, especialmente se eles não tiverem o layout de teclado correto, por isso é geralmente uma boa idéia fornecer uma maneira fácil para os usuários copiarem e colarem um link para reutilização. Se você estiver fornecendo um trecho de código HTML, use a versão punycode do nome de domínio para não ter problemas com as codificações de página.
• Às vezes, você pode querer usar vários nomes de domínio para detectar erros de digitação (por exemplo: timarit.is vs tímarit.is). Se você fizer isso, escolha um nome de domínio preferido e use redirecionamentos 301 em todo o site para esse nome de domínio.
• Se você usar ASCII não de 7 bits nos parâmetros de caminho, arquivo ou consulta, certifique-se de usar UTF-8 para isso. Verifique também se eles estão codificados corretamente para trechos de link (consulte o primeiro ponto).

A codificação de caracteres do seu sistema de gerenciamento de conteúdo é um problema que vem à mente. Além disso, se você estiver promovendo seu site, muitas entradas de validação de URL provavelmente serão quebradas no seu URL.

(1) FTP

Parece que você precisa de um cliente FTP que possa lidar com IDNs, pois requer suporte especial. Com base no que li ao pesquisar isso, esse suporte parece ser amplo e um recurso comum em todos os principais clientes de FTP.

(2) servidores / clientes de email;

Com base no artigo da wikipedia para International Email , parece que o suporte por email não está completo:

Como os padrões tradicionais de email restringem todos os valores de cabeçalho de email a caracteres apenas ASCII, é possível que a presença de caracteres UTF-8 nos cabeçalhos de email diminua a estabilidade e a confiabilidade do transporte desse email. Isso ocorre porque a maioria, se não todos os servidores de email, no momento da redação deste documento, não suportam esses caracteres.

Um método foi proposto, pelos membros da IETF, pelo qual o email pode ser rebaixado para o formato ASCII "legado", todo o qual todos os servidores de email padrão devem suportar. Esse mecanismo de downgrade atende ao requisito de que o transporte de email seja o mais robusto e confiável possível.

.

(3) quais navegadores lutam com os domínios?

Parece que todos os principais navegadores suportam IDNs e o fazem há pelo menos dois anos. O único problema real que você pode ter é com navegadores mais antigos que não suportam IDN. Mas como o IE parece suportá-lo desde que o IE7 e a base de usuários dos outros principais navegadores são atualizados rapidamente, esse número deve ser pequeno.

(4) E os dispositivos móveis‽

Boa pergunta. Parece que o nome de domínio .mobi não suporta IDNs. Eu não consegui encontrar nada específico para os dispositivos em si, mas eu fiz encontrar empresas alegando que eles tinham soluções para IDNs no celular assim que eu estou supondo que o suporte nativo pode não existe ou não está completa.

(5) mudou alguma coisa sobre o assunto - faz quase um ano desde que a pergunta foi feita.

Alguns TLDs específicos de cada país adicionaram suporte e parece que os spammers encontraram uma maneira de explorá-los . Mas isso mudou tanto.

1. Posseiros ou competição * irá * comprar a versão romanizado de seu nome de domínio, eventualmente.

   Portanto, se é de alguma importância (ou isso pode ganhar importância com o tempo), você terá que comprar os dois .

2. Spammers e phishers .
   O Unicode está cheio de caracteres que se parecem muito com os latinos.

   Eles estão começando a usá-los agora, mas em alguns meses, nomes de IDNs desnecessários podem começar a parecer fraudulentos .

3. Visitantes internacionais com um teclado não islandês podem simplesmente odiar você. Mas então, se você não planeja colocar esse nome no cartão de visita, talvez isso não seja um problema.

Enfim ... ☺.com deve ser o estado da arte do uso desnecessário de IDNs

Pós-Scriptum: Adivinhe quem não suporta IDNs como ☺.com ? Stackexchange :)
Tive que procurar o código xn manualmente. : /

Tentamos usar a versão IDN do domínio como padrão, mas acabamos encontrando problemas com alguns navegadores (incluindo Firefox) e Adobe Reader, onde o nome do domínio IDN acabou de ser confundido na transferência para o plug-in do navegador.

Então agora usamos o modo 'seguro' e o IDN simplesmente faz um redirecionamento 301 para ele.