🌐 Punycode / IDN 변환기
국제화 도메인(예: 日本語.jp)과 Punycode(예: xn--wgv71a119e.jp)를 양방향 변환. 전체 URL 붙여넣기 지원, 레이블별 자동 판정.
🔒 개인정보 보호
- ・모든 처리는 브라우저 내에서 완료됩니다
- ・입력 데이터는 서버로 전송되지 않습니다
📖 동작 사양
- 입력에 점이 있으면 각 레이블별로 변환합니다.
- https:// 등 스킴과 경로 포함 URL도 호스트 부분만 변환.
- ASCII만 포함된 라벨은 자동으로 「decode (xn-- → Unicode)」로, ASCII 이외 문자를 포함하면 「encode (Unicode → xn--)」로 판정됩니다.
- Bootstring(RFC 3492)을 순수 JS로 구현.
📖 자주 걸리는 지점
국제화 도메인 (IDN) 과 Punycode 를 RFC 3492 의 Bootstring 알고리즘으로 상호 변환합니다. 점으로 구분된 라벨 단위로 판정하므로 URL 전체를 붙여 넣어도 호스트 부분만 변환됩니다. 처리는 브라우저 안에서 끝나며 입력은 전송되지 않습니다. 다만 이 도구가 하는 일은 부호화뿐입니다 — 그 도메인을 등록할 수 있는지, 안전한지는 판정하지 않습니다. IDNA2008 이나 UTS-46 이 부과하는 문자 종류 제한, 스크립트 혼용 금지, 레지스트리별 고유 규칙은 이 변환의 뒷단에서 따로 적용되는 것들입니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 겉모습은 같은데 다른 도메인 (호모그래프) | 많은 문자 체계에는 라틴 문자와 구별되지 않는 글자가 있습니다. 예를 들어 U+0430 CYRILLIC SMALL LETTER A 는 대부분의 폰트에서 라틴 문자 a 와 똑같이 그려집니다. 이것을 첫 글자로 쓴 도메인은 xn--pple-43d.com 로 부호화되지만 주소창에는 진짜와 같은 철자로 표시될 수 있습니다. 브라우저는 라벨 안에서 스크립트가 섞였다거나 표시 언어와 맞지 않는다는 조건에서 Punycode 표시로 전환하지만 그 기준은 브라우저마다 다르고 사용자의 언어 설정에도 좌우됩니다. 즉 내 화면에서 평범한 철자로 보였다는 사실은 아무것도 보증하지 않습니다. |
xn-- 형태가 유일한 판단 재료입니다. 의심스러운 링크를 여기에 붙여 넣고 출력을 읽으세요. ASCII 로 보이는 도메인인데 xn-- 가 나오면 라틴 문자가 아닌 글자가 섞여 있는 것입니다. 반대 방향도 같아서 xn-- 형태를 붙여 넣으면 실제 문자열을 읽을 수 있습니다. 조직 차원에서 막으려면 눈이 아니라 기계로 걸러내세요 — 메일 게이트웨이나 채팅 수신 측에서 xn-- 가 포함된 URL 에 경고를 띄우고, 업무에 쓰는 도메인을 허용 목록으로 관리하는 방식입니다. 사람의 육안은 원리적으로 뚫립니다. 교육만으로는 대책이 되지 않습니다. |
| 변환된다는 것과 등록·도달 가능한 것은 별개 | 부호화는 기계적인 처리이므로 어떤 문자열이든 변환 자체는 성공합니다. 그러나 DNS 쪽에는 별도의 제한이 있습니다. 라벨 하나 63 자 상한은 「부호화 후」의 길이에 대한 제한이며 xn-- 의 4 자도 여기에 포함됩니다. 가나와 한자는 한 글자가 평균 1.2〜1.5 자로 부풀기 때문에 일본어라면 실질 15〜20 자가 상한입니다. 나아가 이모지 도메인은 IDNA2003 에서는 통과해도 IDNA2008 에서는 금지이며 받아 주는 곳은 일부 TLD 뿐입니다. 원래는 대문자나 전각 영숫자를 UTS-46 으로 정규화한 뒤 부호화하지만 이 도구는 입력된 문자를 그대로 부호화합니다 — 전각 Ａ 는 a 가 되지 않고 비 ASCII 로 부호화됩니다. |
DNS 가 보는 것은 언제나 xn-- 형태뿐입니다. 도달성을 확인하려면 변환 결과를 그대로 dig xn--wgv71a119e.jp 나 whois xn--... 에 넘기세요. Unicode 형태로 조회해서 실패했을 때, 그것이 「미등록」인지 「도구가 IDN 을 못 다루는 것」인지는 구별할 수 없습니다. 길이 확인도 마찬가지로 세어야 할 것은 변환 후의 글자 수입니다 — 출력이 63 자를 넘으면 그 도메인은 어느 등록기관에서도 등록할 수 없습니다. 실제로 취득하기 전에는 등록기관의 검색창이 아니라 레지스트리의 IDN 정책 (사용 가능한 문자표) 을 확인하세요. TLD 마다 허용되는 문자 집합이 다릅니다. |
| 메일·인증서·로그에서 표기가 어긋난다 | DNS 에게 Unicode 형태와 xn-- 형태는 같은 도메인이지만 문자열을 비교하는 모든 구조에게는 서로 다른 값입니다. TLS 인증서의 SAN 에 들어가는 것은 xn-- 형태이므로 Unicode 문자열과 대조하면 일치하지 않습니다. 액세스 로그, 애널리틱스, Search Console 은 구현에 따라 기록하는 형태가 달라 같은 사이트가 두 행으로 갈립니다. 메일은 더 까다로워서 도메인 부분은 xn-- 로 만들 수 있어도 로컬 부분 (@ 의 왼쪽) 을 비 ASCII 로 하려면 SMTPUTF8 (RFC 6531) 이 필요하고, 지원하지 않는 MTA 는 지금도 드물지 않습니다. |
저장과 비교에는 xn-- 형태만 쓰고 Unicode 형태는 화면에 보여 줄 때만 복원한다 — 이것을 한 곳에서 철저히 하는 것이 유일한 답입니다. 데이터베이스에 넣기 직전, 로그에 쓰기 직전, 외부 API 에 넘기기 직전에 xn-- 로 정규화하세요. 「한쪽만 정규화」가 최악이라 리다이렉트나 링크가 무한 루프를 돌거나 같은 사용자가 두 명으로 보입니다. Search Console 은 양쪽 속성을 모두 등록해 합산하는 편이 확실합니다. 메일 주소를 다룬다면 로컬 부분의 비 ASCII 는 당분간 지원하지 않기로 정하고 그 사실을 폼에 적어 두는 편이, 어중간하게 받아 놓고 발송 때 실패하는 것보다 친절합니다. |
Punycode 는 암호도 난독화도 아닙니다. Bootstring 은 가역적인 부호화이며 키도 난수도 없습니다 — 누구나 1 초면 되돌립니다. 「xn-- 라서 못 읽는다」를 전제로 한 설계는 반드시 무너집니다. 라벨 단위로 처리된다는 성질에는 또 하나의 귀결이 있습니다 — 공격 측도 그것을 쓸 수 있다는 점입니다. example.com.xn--.... 같은 형태에서는 진짜 도메인이 서브도메인으로 왼쪽에 놓이고 xn-- 는 맨 오른쪽 라벨에만 나타납니다. 도메인의 소유자를 정하는 것은 언제나 맨 오른쪽 (TLD 옆) 라벨이며 그 왼쪽에 무엇이 적혀 있든 상관없습니다. 판정할 때는 반드시 오른쪽부터 읽으세요.
📖 사용법
-
1
도메인 붙여넣기국제화 도메인 또는 Punycode를 입력합니다. 전체 URL도 가능.
-
2
변환 결과 확인비 ASCII가 있으면 xn--로 인코드, ASCII만 있으면 Unicode로 디코드.
-
3
복사 후 사용복사 버튼으로 클립보드에 저장. WHOIS, DNS, 메일 서버 설정에 그대로 사용.
❓ 자주 묻는 질문
Punycode란?
이모지 도메인도 변환되나요?
브라우저 URL.host와 무엇이 다른가요?
🔗 관련 도구
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.