도메인, 이메일 또는 URL
국제화 도메인 이름(IDN)을 ñandú.com.ar 같은 Unicode 형식과 DNS에서 사용하는 xn--and-6ma2c.com.ar 같은 Punycode ASCII 형식 사이에서 변환합니다. 변환 방향을 자동으로 감지하고, 이메일과 전체 URL도 처리하며, 도메인이 여러 문자 체계를 섞어 다른 도메인을 사칭하는 경우 경고합니다.
최대 500줄. 이메일은 도메인만, URL은 호스트만 변환됩니다.
결과
Unicode → ASCII
Unicodeñandú.com.ar
ASCIIxn--and-6ma2c.com.ar
ñandúxn--and-6ma2c13 · Latin
ASCII → Unicode
Unicodemünchen.de
ASCIIxn--mnchen-3ya.de
münchenxn--mnchen-3ya14 · Latin
Unicode → ASCII이메일
Unicodecontacto@correo.españa.es
ASCIIcontacto@correo.xn--espaa-rta.es
españaxn--espaa-rta13 · Latin
Unicode → ASCIIURL
Unicodehttps://日本語.jp/ページ
ASCIIhttps://xn--wgv71a119e.jp/%E3%83%9A%E3%83%BC%E3%82%B8
日本語xn--wgv71a119e14 · Han
Unicode → ASCII
Unicodeаррӏе.com
ASCIIxn--80ak6aa92e.com
аррӏеxn--80ak6aa92e14 · Cyrillic

레이블 전체가 라틴 문자와 똑같아 보이는 키릴 문자나 그리스 문자로 작성되어 있습니다. 잘 알려진 도메인을 사칭할 수 있으니 링크를 신뢰하기 전에 xn-- 형식을 확인하세요.

접두사 없는 Punycode(RFC 3492)

xn-- 접두사나 도메인 정규화 없이 순수 Punycode 알고리즘으로 임의의 텍스트를 인코딩하거나 디코딩합니다. 직접 구현한 코드를 디버깅할 때 유용합니다.

결과maana-pta

작동 방식

DNS는 ASCII 영문자, 숫자, 하이픈만 허용하므로 ñandú.com.ar 같은 도메인은 그대로 전달될 수 없습니다. 국제화 도메인 이름(IDN)은 Punycode(RFC 3492)로 이 문제를 해결합니다. ASCII 이외의 문자가 포함된 각 레이블은 일반 문자는 그대로 두고 특수 문자의 위치를 끝에 덧붙이는 알고리즘으로 인코딩되며, 앞에 xn-- 접두사가 붙습니다. 그래서 ñandú는 xn--and-6ma2c가 됩니다.

인코딩하기 전에 IDNA는 이름을 정규화합니다. 소문자로 바꾸고, Unicode 형식을 통일하며, 일본어 。 같은 대체 마침표를 변환합니다. 이 도구는 브라우저가 주소를 열 때 적용하는 것과 동일한 매핑(UTS #46)을 사용하므로, 결과는 최종적으로 DNS에 질의되는 값과 일치합니다. 이메일은 도메인만, URL은 호스트만 변환합니다.

또한 각 레이블을 길이와 사용된 문자 체계별로 분석하고, 도메인이 여러 문자 체계를 섞거나 라틴 문자와 동일해 보이는 키릴 문자나 그리스 문자로 작성된 경우 경고합니다. 이는 링크를 잘 알려진 사이트의 것처럼 보이게 하는 호모그래프 공격의 기본 원리입니다.

예시

ñandú.com.arxn--and-6ma2c.com.ar특수 문자가 포함된 레이블만 바뀌고 com과 ar은 그대로입니다. DNS와 인증서의 SAN에 등록해야 하는 형식이 바로 이것입니다.
faß.dexn--fa-hia.deIDNA2008에서는 독일어 ß가 유효한 문자이므로 인코딩됩니다. 이전 표준에서는 ss로 변환되어 다른 도메인인 fass.de를 가리켰기 때문에, 일부 오래된 시스템은 다른 곳으로 해석합니다.
аррӏе.comxn--80ak6aa92e.comXudong Zheng이 2017년에 공개한 호모그래프로, apple과 똑같아 보이는 키릴 문자 다섯 개로 이루어져 있습니다. 그 이후 Chrome과 Firefox는 이런 도메인을 xn-- 형식으로 표시합니다.
пример.рфxn--e1afmkfd.xn--p1ai최상위 도메인도 국제화될 수 있습니다: .рф는 키릴 문자로 된 러시아의 도메인이며 DNS에서는 xn--p1ai로 표기됩니다.

활용 사례

  • 한글이나 악센트가 포함된 도메인의 xn-- 형식을 구해 DNS 레코드, nginx 또는 Apache 설정, 인증서의 SAN에 등록합니다.
  • 로그, 피싱 신고, 브라우저 주소창에 나타난 xn-- 뒤에 있는 실제 도메인을 파악합니다.
  • 의심스러운 링크를 검사해 라틴 문자를 흉내 낸 키릴 문자나 그리스 문자를 찾아냅니다.
  • SMTPUTF8을 지원하지 않는 서버를 위해 국제화 이메일 주소의 도메인을 변환합니다.
  • 국제화 도메인을 인코딩한 뒤 레이블당 63자를 넘지 않는지 확인합니다.

자주 묻는 질문

xn-- 접두사는 무슨 뜻인가요?

레이블이 Punycode임을 나타내는 ACE(ASCII Compatible Encoding) 접두사입니다. 세 번째와 네 번째 자리에 하이픈이 있는 레이블은 이러한 접두사용으로 예약되어 있으므로, 유효한 IDN이 아니면 레지스트리에서 xn--로 시작하는 도메인을 만들 수 없습니다.

DNS, 웹 서버, 인증서에는 어떤 형식을 사용해야 하나요?

모든 기술적인 위치에는 xn--가 붙은 ASCII 형식을 사용합니다: DNS 레코드, nginx의 server_name, Apache의 ServerName, 인증서의 SAN, Host 헤더. Unicode 형식은 사람에게 보여 주기 위한 것일 뿐이며, 브라우저는 질의하기 전에 이를 변환합니다.

호모그래프 공격이란 무엇인가요?

다른 문자 체계의 글자(예: 라틴 문자 a 대신 키릴 문자 a)를 사용해 다른 도메인과 똑같아 보이는 도메인을 등록하는 공격입니다. 브라우저는 레이블이 여러 문자 체계를 섞거나 잘 알려진 도메인과 비슷해 보이면 xn-- 형식으로 표시합니다. 링크가 평범해 보이는데 ASCII 형식이 xn--로 시작한다면 의심하세요.

이메일 주소에 ASCII 이외의 문자를 사용할 수 있나요?

도메인은 사용할 수 있으며, 어떤 서버를 위해서든 xn--로 변환할 수 있습니다. @ 앞부분은 사정이 다릅니다. ASCII 이외의 문자가 있으면 경로상의 모든 서버가 SMTPUTF8(RFC 6531)을 지원해야 하며, 이에 대응하는 Punycode 형식도 없습니다.

대문자가 포함된 도메인이 왜 바뀌었나요?

도메인 이름은 대소문자를 구분하지 않으며, IDNA는 인코딩 전에 모두 소문자로 바꿉니다: MÜNCHEN.de와 münchen.de는 같은 도메인인 xn--mnchen-3ya.de입니다. 반면 순수 Punycode는 대문자를 유지하므로, 접두사 없는 변환기는 다른 결과를 냅니다.

관련 항목