문서 작업 가이드
국제 도메인을 퓨니코드로 변환해 DNS 확인하기
URL에서 호스트명을 분리하고 유니코드 라벨을 검증된 ASCII로 변환한 뒤, 라벨별 결과를 DNS와 애플리케이션 설정에 비교합니다.
작성 및 검수 SimpleWebUtils게시일: 검토일:
이 작업 흐름을 검증한 방법
IDN 변환기: 유니코드와 퓨니코드 도메인 변환로 “일본어 점 구분자를 매핑하고 루트 점 유지하기” 샘플 입력을 정확히 재현했습니다. 결과 비교에는 “원본 비교값 보관하기”, “엄격한 IDNA 규칙으로 변환하기” 단계를 포함했습니다. 이어서 연결된 테스트 근거에서 “표시된 유니코드만 비교하기”, “변환되면 등록 가능하다고 생각하기” 조건을 점검했습니다.
일본어 전각 구분자가 정상화되고 두 국제화 label이 portal.xn--r8jz45g.xn--zckzah.example.로 바뀌었으며, 왕복 뒤에도 마지막 root dot이 유지됐습니다.
문제 상황
브라우저는 유니코드 호스트명을 표시할 수 있지만 DNS 레코드, 인증서, 허용 목록, 로그, 호스팅 패널은 ASCII 호환 인코딩을 사용할 수 있습니다. URL 전체를 퓨니코드로 인코딩하거나 눈에 보이는 철자만 비교하거나 변환 성공을 등록·안전성 증명으로 받아들이면 잘못된 호스트명을 만들거나 혼합 문자 라벨을 놓칠 수 있습니다.
공식 출처와 표준
다음 공식 문서는 이 작업 흐름에서 다루는 형식과 보안 경계의 기준입니다. 도구별 실행 검증은 위에 별도로 기록합니다.
- URL Living Standard
WHATWG
- RFC 3492: Punycode
RFC Editor / IETF
이럴 때 사용하세요
- 유니코드 호스트명과 xn-- 호스트명이 같은 사이트처럼 보이지만 문자열로 일치하지 않을 때
- DNS 또는 호스팅 제공업체가 국제 도메인에 ASCII 라벨만 받을 때
- 리디렉션, 인증서, 허용 목록, 쿠키 도메인, 애플리케이션 로그의 퓨니코드를 검토할 때
- 호스트명에 비라틴 문자나 여러 문자 체계가 있어 라벨별 확인이 필요할 때
- 루트 점으로 끝나는 완전한 도메인 이름을 설정에서 그대로 비교해야 할 때
단계
- 1단계
호스트명만 분리하기
`https://`, 인증 정보, 포트, 경로, 쿼리, 프래그먼트에서 호스트를 분리합니다. 원본이 전체 URL이면 먼저 `URL 파서`를 사용하세요. IDNA는 도메인 라벨을 변환하며 URL의 나머지 부분이나 이메일 로컬 파트를 변환하지 않습니다.
- 2단계
원본 비교값 보관하기
브라우저, 로그, 인증서, 제공업체에서 보인 정확한 호스트명을 수정 전에 기록합니다. 끝에 루트 점이 있었는지 보존하고 비슷해 보이는 문자를 눈으로 바꾸지 마세요.
- 3단계
엄격한 IDNA 규칙으로 변환하기
유니코드 입력은 `ASCII로 변환(퓨니코드)`, ASCII 또는 xn-- 도메인은 `유니코드로 변환`을 선택합니다. IDN 변환기는 비전이형 UTS #46 검사를 적용하고 알려진 유니코드 점 구분자를 매핑하며 빈 라벨, 잘못된 퓨니코드, 공백, URL 구분자, DNS 길이 위반을 거부합니다.
- 4단계
모든 라벨 확인하기
각 라벨의 유니코드와 ASCII 값을 비교합니다. 혼합 문자 경고가 있으면 직접 검토하세요. 경고는 유용한 단서지만 경고가 없다고 해서 도메인이 정상적이거나 시각적 혼동에서 안전하다는 뜻은 아닙니다.
- 5단계
DNS 경계에서는 ASCII 형식 비교하기
DNS 레코드, 인증서 이름, 허용 목록, 리디렉션, 쿠키 Domain 속성, 호스팅 설정, 로그를 비교할 때 정확한 ASCII 결과를 사용합니다. 끝의 루트 점은 대상 구문이 완전한 도메인 이름을 허용하거나 요구할 때만 유지합니다.
- 6단계
실제 서비스는 별도로 검증하기
등록하려는 곳에서 레지스트리 정책과 등록 가능 여부를 확인하고, 대상 환경에서 DNS 해석, TLS 범위, HTTP 리디렉션, 쿠키 동작, 이메일 지원을 검증합니다. 로컬 변환은 이러한 네트워크·정책 검사를 수행하지 않습니다.
예시
일본어 점 구분자를 매핑하고 루트 점 유지하기
입력
portal.例え。テスト.example.출력
portal.xn--r8jz45g.xn--zckzah.example.흔한 실수
URL 전체를 인코딩하기
퓨니코드는 호스트명 라벨에 적용됩니다. 먼저 URL을 파싱해 슬래시, 포트, 쿼리 값, 프래그먼트를 도메인 문자로 오해하지 않게 하세요.
표시된 유니코드만 비교하기
서로 다른 코드 포인트나 문자 체계가 비슷하게 보일 수 있습니다. DNS에서 쓰는 정확한 식별자를 확인하려면 검증된 ASCII 라벨을 비교하세요.
변환되면 등록 가능하다고 생각하기
레지스트리는 UTS #46보다 더 엄격하게 문자 체계, 변형 문자, 이모지, 예약 이름, 라벨 조합을 제한할 수 있습니다. 정책과 등록 가능 여부는 권한 있는 곳에서 별도로 확인해야 합니다.
문자 체계 감지를 보안 스캐너로 보기
변환기는 일반 문자 체계와 단순한 라벨 내 혼합을 보고합니다. 전체 유니코드 유사 문자, 도메인 평판, 소유권, 페이지 내용, 사용 의도는 평가하지 않습니다.
맥락 없이 루트 점을 빼거나 더하기
끝의 점은 완전한 이름에서 DNS 루트를 뜻합니다. 설정 형식에 따라 허용 여부가 다르므로 대상 맥락에서 필요할 때만 보존하세요.
자주 묻는 질문
ASCII 도메인은 왜 xn--로 시작하나요?
국제 도메인용 ASCII 호환 인코딩 라벨임을 나타내는 접두사입니다. IDNA 인코딩이 필요한 라벨에만 붙고 일반 ASCII 라벨은 그대로 유지됩니다.
https://와 경로까지 붙여넣어도 되나요?
안 됩니다. 먼저 호스트명을 분리하세요. URL 구문을 거부하면 경로, 포트, 쿼리, 사용자 정보 같은 관련 없는 부분이 도메인으로 잘못 바뀌는 것을 막을 수 있습니다.
유니코드 점이 왜 일반 점으로 바뀌었나요?
UTS #46은 국제 문서에서 쓰이는 여러 점 모양 구분자를 인식합니다. 표의문자 마침표와 전각·반각 점을 라벨 검증 전에 ASCII 점으로 매핑합니다.
안정적인 왕복 변환이면 DNS도 연결되나요?
아닙니다. 이 프로필에서 검증된 유니코드와 ASCII 표현이 일관되게 변환된다는 뜻입니다. DNS 해석은 별도의 실제 조회가 필요합니다.
국제 이메일 주소 검증에도 쓸 수 있나요?
IDNA 범위는 도메인 부분뿐입니다. 메일함 로컬 파트, SMTPUTF8 지원, 제공업체 정책, 실제 전달은 이메일 전용 검증이 필요합니다.
입력한 도메인을 레지스트리에 전송하나요?
아니요. 변환은 브라우저에서 실행되며 DNS, WHOIS, 등록대행자, 레지스트리, 인증서, 평판 서비스에 조회하지 않습니다.