Punycode / IDN 변환기

Punycode란?#

도메인 이름 시스템은 ASCII를 바탕으로 만들어졌습니다. 알파벳 A-Z, 숫자, 하이픈만 씁니다. 그렇다면 브라우저는 中文.com 이나 münchen.de 처럼 그 알파벳에 없는 문자가 섞인 도메인을 어떻게 해석할까요? 답이 Punycode(그리고 이를 둘러싼 IDN 체계)입니다. 비-ASCII 레이블 각각을 xn-- 접두어로 시작하는 ASCII 안전 형태로 바꾸는 가역 인코딩입니다. DNS는 오직 xn--fiq228c.com 만을 보고, 브라우저는 여러분에게 中文.com 을 보여줍니다.

이 도구는 양방향으로 변환합니다.

• Unicode → Punycode 는 Unicode 도메인이나 이메일을 받아 DNS와 인증서가 실제로 담는 xn-- 형태를 만듭니다. 각 레이블은 독립적으로 변환됩니다. münchen.中文.com 은 xn--mnchen-3ya.xn--fiq228c.com 이 되고, 뒤의 .com 은 이미 ASCII이므로 그대로 남습니다.
• Punycode → Unicode 는 그 반대로, xn-- 레이블을 사람이 읽을 수 있는 문자로 되돌립니다.

이메일도 처리합니다. 도구는 @ 를 감지하고 도메인 부분만 변환하며, 로컬 부분(사서함 이름)은 그대로 둡니다. 그래서 Büchner@中文.com 은 Bü[email protected] 이 되지, 문자열 전체가 잘못 변환되는 일은 없습니다.

사용 방법#

1. 왼쪽 위 토글에서 Unicode → Punycode 또는 Punycode → Unicode 를 고르세요. 입력에 xn-- 레이블이 보이면 도구가 방향을 추천해 줍니다.
2. 입력 패널에 도메인 또는 이메일을 붙여넣으세요. 헤더는 이를 도메인 으로 인식했는지 이메일 로 인식했는지 보여줍니다.
3. 변환 결과가 출력 패널을 채웁니다. 복사 로 가져가세요.
4. 패널 아래의 레이블별 세부 내역 표는 각 레이블과 그것이 무엇으로 바뀌었는지 보여줍니다. 긴 도메인에 비-ASCII 레이블이 여럿 있고 일부만 바뀌었을 때 요긴합니다.
5. 출력 → 입력 은 출력을 다시 입력으로 옮기고 방향을 뒤집습니다(빠른 왕복 확인). 예제 는 münchen.中文.com 을 불러오고, 지우기 는 초기화합니다.

주요 기능#

• 양방향, 각 레이블은 독립적으로. 모든 레이블은 독립적으로 변환되며, 세부 내역 표는 어느 레이블이 바뀌고 어느 레이블이 ASCII로 남았는지 정확히 보여줍니다.
• 이메일 인식. 단일 @ 를 감지하고 사서함 이름을 보존하며, 도메인 쪽만 인코딩합니다. @ 가 여러 개인 입력은 결과를 조용히 망가뜨리는 대신 명확한 메시지와 함께 거부됩니다.
• 구분자 정규화. 전각 마침표 ．, 표의 마침표 。, 반각 ｡ 는 모두 IDN에서 실제로 그런 것처럼 ASCII . 로 취급하므로, 붙여넣은 텍스트가 깨지지 않습니다.
• 잘못된 입력에 엄격. 잘못된 xn-- 레이블(예: xn--!!)은 잘못된 도메인을 만들어내는 대신, 문제가 된 레이블을 짚어주는 명확한 오류를 일으킵니다.
• 범위에 대해 정직. 도구 아래의 규정 준수 안내문은 이 도구가 Punycode 인코딩과 매핑 단계를 구현할 뿐, 완전한 IDNA2008 유효성 검사기는 아니라고 솔직하게 밝힙니다. 그래서 기술적으로 유효하지 않은 ACE 레이블도 여기서는 디코딩될 수 있습니다.

실전 예시#

Unicode → Punycode 로 변환하면, 예제의 münchen.中文.com 은 이렇게 됩니다.

xn--mnchen-3ya.xn--fiq228c.com

세부 내역은 세 개의 레이블을 보여주고, 그중 둘이 변환되었습니다. münchen → xn--mnchen-3ya, 中文 → xn--fiq228c, 그리고 .com 은 이미 ASCII이므로 그대로입니다. Punycode → Unicode 로 전환하고 결과를 다시 붙여넣으면 münchen.中文.com 이 정확히 복원됩니다.

눈에 두고 갈 만한 실제 변환 몇 가지를 더 보여 드리겠습니다.

中文.com           → xn--fiq228c.com
münchen.de        → xn--mnchen-3ya.de
😂.com             → xn--g28h.com
café.fr           → xn--caf-dma.fr
日本語.jp          → xn--wgv71a119e.jp
Büchner@中文.com   → Bü[email protected]   (이메일: 사서함 보존)

마지막 것이 사람들을 자주 낚는 사례입니다. 단순한 도구는 문자열 전체를 인코딩하며 주소를 망가뜨립니다. 여기서는 @ 뒤의 도메인 부분만 바뀝니다.

FAQ#

왜 제 이모지 도메인이 그렇게 짧은 xn-- 레이블로 변환되나요?#

😂.com 같은 한 글자 이모지 도메인이 xn--g28h.com 이 되는 것은, Punycode가 ASCII가 뒤따르는 단일 비-ASCII 문자로 이루어진 레이블에서 비정상적으로 간결하기 때문입니다. 비-ASCII 문자의 위치와 코드 포인트를 ASCII 문자를 기준으로 인코딩하므로, 한 글자짜리 레이블은 아주 적은 바이트만 필요합니다. 더 길거나 다양한 비-ASCII 레이블은 더 긴 ACE 문자열을 만듭니다.

출력이 입력과 같아 보입니다. 무슨 일이 일어난 건가요?#

입력의 모든 레이블이 이미 순수 ASCII(예: example.com)라면 인코딩할 것이 없고, 출력은 입력과 같습니다. 세부 내역 표가 믿을 수 있는 지표입니다. 출력 이 입력 과 같은 레이블은 변환되지 않은 것인데, 변환할 필요가 없었기 때문입니다.

이메일을 붙여넣었는데 로컬 부분이 변환되지 않았습니다. 맞는 건가요?#

네, 의도된 동작입니다. 국제화 이메일(SMTPUTF8)은 사서함 이름에 UTF-8을 허용하지만, 흔한 사례에서 이를 xn-- 로 바꾸는 것은 틀립니다. 로컬 부분은 DNS 이름이 아니며 Punycode로 해석되지 않습니다. 이 도구는 DNS-안전해야 하는 도메인 쪽만 변환합니다. @ 가 여러 개인 입력이 거부되는 이유이기도 합니다. “도메인 쪽”이 모호해지기 때문입니다.

ASCII 형태로 어떤 도메인이든 등록하거나 해석할 수 있나요?#

최신 브라우저나 리졸버로 해석하는 것이라면 네. 등록의 경우 규칙이 더 엄격합니다. IDNA2008은 오래된 매핑(IDNA2003)이 허용하던 일부 문자와 정규화를 금지합니다. 이 도구는 인코딩은 충실히 수행하지만 완전한 IDNA2008 유효성 검사까지는 실행하지 않으므로, 여기서는 깨끗하게 인코딩되는 문자열이라도 등록 기관에서 거부될 수 있습니다. 의심스러울 때는 등록 기관의 조회 도구로 확인하세요.