요약

  • RFC 3492의 Bootstring은 기본 ASCII 코드 포인트를 그대로 복사하고, 나머지 모든 비기본 포인트는 코드 포인트 거리와 증가 중인 출력 안의 삽입 위치를 함께 담은 델타로 인코딩했습니다.
  • 자기 구분 정수와 적응형 바이어스는 그 표현을 유일하고 가역적으로 만들었습니다. 하지만 그것이 번역, 정규화, IDNA 검증, 등록 접수 또는 신원 증명을 의미하지는 않았습니다.

Punycode는 흔히 눈에 보이는 결과로 기억됩니다: 후반부가 불투명해 보이는 ASCII 레이블이 그것입니다. RFC 3492는 디코더의 작업대에서 출발해 뒤에서부터 읽을 때 더 흥미롭습니다. 디코더는 단어를 번역하지 않습니다. ASCII에서 그대로 살아남을 수 있는 문자로 시작해, 나머지 모든 것을 정확한 틈에 삽입하는 방식으로 수열을 재구성합니다.

Bootstring은 먼저 기본 코드 포인트를 분리합니다. 원래 상대 순서를 유지한 채 앞부분에 복사하고, 하나라도 존재하면 그 뒤에 구분자가 옵니다. Punycode에서 기본 집합은 ASCII이고 구분자는 하이픈 마이너스입니다. 이 문자 그대로의 부분은 미니 번역이 아닙니다. 입력 중 인코딩이 필요 없는 부분일 뿐입니다.

꼬리부는 빠진 구조를 담고 있습니다. 디코더는 두 개의 상태 변수를 유지합니다:n은 후보 코드 포인트 값이고,i는 지금까지 만든 출력 안의 가능한 삽입 위치입니다. 상태를 진행시키면i가 모든 틈을 지나가고, 끝에 이르면i가 0으로 되돌아가고n이 증가합니다. 하나의 델타는 현재n을 현재i에 삽입하기 전에 그러한 비삽입 상태를 몇 개 건너뛰는지를 말해 줍니다.

여기가 결정적인 압축 지점입니다. 하나의 비음수 정수가 코드 포인트 공간의 거리와 성장 중인 문자열 안의 위치를 동시에 담습니다. 인코더는 비기본 포인트를 수치 순서로 처리하는데, 이는 연속된 거리를 작게 유지하는 경향이 있으며, 디코더가 원래 순서를 재구성하도록 만드는 델타들을 도출합니다. 따라서 꼬리부는 명시적인 위치 테이블을 쓰지 않고도 위치를 기록합니다.

여러 델타를 이어 붙여야 하므로, 보통의 자릿수 고정 정수라면 어디서 하나가 끝나는지 모호해질 것입니다. Bootstring은 대신 일반화된 가변 길이 정수를 사용합니다. 각 자릿수마다 임계값이 다음 자릿수가 더 따르는지를 결정합니다. 자신의 임계값보다 낮은 마지막 자릿수는 정확히 하나만 존재합니다. 리틀엔디언 자릿수를 쓰면 디코더는 앞에서부터 읽으면서 첫 정수를 분리하고 그다음 정수를 분리할 수 있습니다. 임계값이 고정되어 있다면 각 비음수 정수는 정확히 하나의 표현을 갖습니다.

임계값은 델타마다 고정되어 있지 않습니다. 삽입이 일어날 때마다 적응 함수가bias를 바꿉니다. 첫 큰 점프는 강하게 감쇠되고, 이후 점프는 이미 처리한 코드 포인트 수에 맞춰 조정됩니다. 가장 최근의 델타는 다음 델타의 크기에 대한 힌트가 됩니다. 이는 언어적 예측이 아닙니다. 가까운 크기에 더 적은 기본 문자를 쓰기 위한 국소적인 산술 예측입니다.

Punycode는 메커니즘을 36진법으로 고정했습니다. 문자는 0부터 25까지의 값을 담고, 숫자는 26부터 35까지, 초기 코드 포인트는 128, 초기 바이어스는 72입니다. 이 매개변수 집합이 효율성을 좌우했습니다. Bootstring의 제약 조건이 지켜지는 한, 매개변수는 인코딩과 디코딩의 정확성에 영향을 주지 않았습니다.

정확성에는 여전히 방어적인 산술이 필요했습니다. RFC 3492는 오버플로를 실패로 식별하고 덧셈과 곱셈을 어디에서 검사해야 하는지 보여 줍니다. 이 RFC는 유효한 IDNA 레이블에서는 유니코드와 63자 DNS 레이블 한도를 감안할 때 26비트 부호 없는 정수로 충분하다고 논증합니다. 그 유계적인 결론이 일반 구현에서 검사하지 않은 오버플로를 허용 가능하게 만들지는 않았습니다.

유일성은 보안의 문제였습니다. 하나의 유니코드 수열이 여러 ASCII 인코딩을 얻을 수 있다면, 그 레이블들은 서로 다른 DNS 권한 아래 존재할 수 있었습니다. Punycode는 확장 문자열 하나당 기본 문자열을 최대 하나만 제공함으로써 그 분열을 피했습니다. 그러나 RFC는 즉시 다음 경계를 보존했습니다: 서로 다른 유니코드 수열은 여전히 어떤 인간적, 언어적 또는 정규화 규칙 아래에서 "같은" 텍스트로 취급될 수 있습니다. Punycode는 그 질문을 결코 판정하지 않았습니다.

RFC 3490은 Punycode를 IDNA의 수용 및 표시 연산 안에 배치했습니다. IDNA2008은 이후 주변의 준비 및 유효성 규칙을 바꾸면서도 Punycode A-레이블은 유지했습니다. 이 연속성은 Lu Heng의 최소 초기 명세 원리를 보여 줍니다. 좁은 가역 인코딩은 허용 가능한 코드 포인트, 로컬 매핑, 등록에 관한 정책이 다른 곳에서 진화하는 동안에도 안정적으로 남을 수 있었습니다.

현실 계층의 교훈도 똑같이 정확합니다. 입력 코드 포인트, 준비된 코드 포인트, 문자 그대로의 접두부, 델타 스트림, 재구성된 수열, 수용된 A-레이블, 등록된 이름, DNS 응답, 인식된 신원은 서로 다른 영수증입니다. Punycode는 그중 두 가지를 연결했습니다: 하나의 수열과 그 ASCII 표현. 그 성공은 나머지를 연결했다고 가장하기를 거부한 데 있었습니다.

출처