この文書はRFC3492の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group A. Costello
Request for Comments: 3492 Univ. of California, Berkeley
Category: Standards Track March 2003
Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA)
プニコード：アプリケーションの国際化ドメイン名（ＩＤＮＡ）
のためのユニコードブースティングコーディング
Status of this Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
概要
Punycode is a simple and efficient transfer encoding syntax designed
for use with Internationalized Domain Names in Applications (IDNA).
It uniquely and reversibly transforms a Unicode string into an ASCII
string. ASCII characters in the Unicode string are represented
literally, and non-ASCII characters are represented by ASCII
characters that are allowed in host name labels (letters, digits, and
hyphens). This document defines a general algorithm called
Bootstring that allows a string of basic code points to uniquely
represent any string of code points drawn from a larger set.
Punycode is an instance of Bootstring that uses particular parameter
values specified by this document, appropriate for IDNA.
Ｐｕｎｙｃｏｄｅはアプリケーションの国際化ドメイン名（ＩＤＮＡ）を使
用のために設計された単純で転送効率のよいコード方式です。これは一意で
可逆的にユニコード文字列をＡＳＣＩＩ文字列に変換します。ユニコード文
字列でのＡＳＣＩＩ文字がそのままで表わされ、非ＡＳＣＩＩ文字がホスト
名ラベルで許されるＡＳＣＩＩ文字（英字と数字とハイフン）で表わされま
す。この文書は基本コードポイント文字列からユニークな表現を生成するブー
スティングと呼ばれる一般的なアルゴリズムを定義します。プニコードは、
は、この書類でＩＤＮＡに適切なように指定したパラメータ値を使う、ブー
スティングの実例です。
Table of Contents
目次
1. Introduction
1. はじめに
1.1 Features
1.1 特徴
1.2 Interaction of protocol parts
1.2 プロトコル部分の相互作用
2. Terminology
2. 用語
3. Bootstring description
3. ブースティングの詳細
3.1 Basic code point segregation
3.1 基本コードポイント分離
3.2 Insertion unsort coding
3.2 非順序挿入コーディング
3.3 Generalized variable-length integers
3.3 一般化可変長整数
3.4 Bias adaptation
3.4 バイアス調整
4. Bootstring parameters
4. ブースティングパラメータ
5. Parameter values for Punycode
5. プニコードのパラメータ値
6. Bootstring algorithms
6. ブースティングアルゴリズム
6.1 Bias adaptation function
6.1 バイアス適合機能
6.2 Decoding procedure
6.2 解読処理
6.3 Encoding procedure
6.3 コード化手順
6.4 Overflow handling
6.4 溢れ処理
7. Punycode examples
7. プニコード例
7.1 Sample strings
7.1 サンプル文字列
7.2 Decoding traces
7.2 解読跡
7.3 Encoding traces
7.3 コード化跡
8. Security Considerations
8. セキュリティの考察
9. References
9. 参考文献
9.1 Normative References
9.1 参照する参考文献
9.2 Informative References
9.2 有益な参考文献
A. Mixed-case annotation
A. 大文字小文字の混合の注釈
B. Disclaimer and license
B. 断り書きと許可
C. Punycode sample implementation
C. プニコードサンプル実装
Author's Address
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
[IDNA] describes an architecture for supporting internationalized
domain names. Labels containing non-ASCII characters can be
represented by ACE labels, which begin with a special ACE prefix and
contain only ASCII characters. The remainder of the label after the
prefix is a Punycode encoding of a Unicode string satisfying certain
constraints. For the details of the prefix and constraints, see
[IDNA] and [NAMEPREP].
[IDNA]は国際化ドメイン名をサポートする体系を記述します。非ＡＳＣＩＩ
文字を含むラベルがＡＣＥラベルで表記することができ、これは特別なＡＣ
Ｅプレフィックスから始まって、ＡＳＣＩＩ文字だけを含んでいます。プレ
フィックスの後のラベルの残りがある特定の制約を満たすユニコード文字列
のプニコードコーディングです。プレフィックスの細部と制約は[IDNA]と
[NAMEPREP]を見てください。
Punycode is an instance of a more general algorithm called
Bootstring, which allows strings composed from a small set of "basic"
code points to uniquely represent any string of code points drawn
from a larger set. Punycode is Bootstring with particular parameter
values appropriate for IDNA.
プニコードはブースティングと呼ばれるより一般的なアルゴリズムの実例で、
これは「基本」コードポイントの小さな集合で構成された文字列で、一意に
大きなコードポイント集合からなる文字列を表現できます。プニコードはＩ
ＤＮＡに適切な特定のパラメータ値を持っているブースティングです。
1.1 Features
1.1 特徴
Bootstring has been designed to have the following features:
ブースティングは次の特徴を持つよう意図されました：
* Completeness: Every extended string (sequence of arbitrary code
points) can be represented by a basic string (sequence of basic
code points). Restrictions on what strings are allowed, and on
length, can be imposed by higher layers.
* 完全性：すべての拡張文字列（任意コードポイント列）が基本文字列（基
本コードポイント列）で表すことができます。どの文字と長さが許される
かは、より上位層で決めれます。
* Uniqueness: There is at most one basic string that represents a
given extended string.
* 一様性：与えられた拡張文字列を表す基本文字列が１つだけあります。
* Reversibility: Any extended string mapped to a basic string can
be recovered from that basic string.
* 可逆性：基本文字列に変換された拡張文字列を、元の拡張文字列にもど
せます。
* Efficient encoding: The ratio of basic string length to extended
string length is small. This is important in the context of
domain names because RFC 1034 [RFC1034] restricts the length of a
domain label to 63 characters.
* 効率的コーディング：基本文字列長と拡張文字列長の比率は小さいです。
これはＲＦＣ１０３４［RFC1034］がドメインラベルの長さを６３文字に
制限するから、ドメイン名環境で重要です。
* Simplicity: The encoding and decoding algorithms are reasonably
simple to implement. The goals of efficiency and simplicity are
at odds; Bootstring aims at a good balance between them.
* 単純：コーディングとデコーディングのアルゴリズムは実装が適度に簡単
です。効率と単純の目標は競合します；ブースティングはそれらの良いバ
ランスを狙います。
* Readability: Basic code points appearing in the extended string
are represented as themselves in the basic string (although the
main purpose is to improve efficiency, not readability).
* 可読性：拡張文字列に現われている基本コードポイントは、基本文字列で
そのままあらわれます（本来の目的は効率の改善であり、可読性ではない）
Punycode can also support an additional feature that is not used by
the ToASCII and ToUnicode operations of [IDNA]. When extended
strings are case-folded prior to encoding, the basic string can use
mixed case to tell how to convert the folded string into a mixed-case
string. See appendix A "Mixed-case annotation".
プニコードは同じく[IDNA]のToASCIIとToUnicode演算で使われない追加機能
をサポートできます。拡張文字列がコーディングの前に大文字小文字を区別
した場合、基本文字列を大文字小文字が入り混じった形で使うことが出来ま
す。付録Ｂ「大文字小文字の混ざった表現」を見てください。
1.2 Interaction of protocol parts
1.2 プロトコル部分の相互作用
Punycode is used by the IDNA protocol [IDNA] for converting domain
labels into ASCII; it is not designed for any other purpose. It is
explicitly not designed for processing arbitrary free text.
プニコードはドメインラベルをＡＳＣＩＩに変換する際にＩＤＮＡプロトコ
ル[IDNA]で使われます；これは他の目的のために設計されてません。特にこ
れは任意文字列を処理することに対する設計でありません。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"はＢＣ
Ｐ１４、ＲＦＣ２１１９で記述されるように解釈されるはずです。
A code point is an integral value associated with a character in a
coded character set.
コードポイントがコード化文字集合で文字と結び付く値です。
As in the Unicode Standard [UNICODE], Unicode code points are denoted
by "U+" followed by four to six hexadecimal digits, while a range of
code points is denoted by two hexadecimal numbers separated by "..",
with no prefixes.
ユニコード標準[UNICODE]で、ユニコードコードポイントは"U+"に続く４つか
ら６つの１６進数で表され、コードポイントの範囲がプレフィックスなしで
".."で区切られた２桁の１６進数で表されます。
The operators div and mod perform integer division; (x div y) is the
quotient of x divided by y, discarding the remainder, and (x mod y)
is the remainder, so (x div y) * y + (x mod y) == x. Bootstring uses
these operators only with nonnegative operands, so the quotient and
remainder are always nonnegative.
演算子divとmodは整数割り算を行います；(x div y)が余りを切り捨てたx割
るyの商で、(x mod y)が余りです、従って(x div y) * y + (x mod y) == x
です。ブースティングは非負整数演算でだけこれらのオペレーターを使い、
それで商と余りは常に非負整数です。
The break statement jumps out of the innermost loop (as in C).
break文は一番奥のループから抜けます（Ｃ言語のように）。
An overflow is an attempt to compute a value that exceeds the maximum
value of an integer variable.
あふれは整数変数の最大値を超える値を計算する試みです。
3. Bootstring description
3. ブースティングの詳細
Bootstring represents an arbitrary sequence of code points (the
"extended string") as a sequence of basic code points (the "basic
string"). This section describes the representation. Section 6
"Bootstring algorithms" presents the algorithms as pseudocode.
Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
algorithms for sample inputs.
ブースティングは任意のコードポイント列（「拡張文字列」）を基本的なコー
ドポイント列（「基本文字列」）で表現します。この章は表現を記述します。
６章の「ブースティングアルゴリズム」がアルゴリズムを擬似コードとして
提示します。７.１章「デコーディング跡」と７.２章の「コーディング跡」
はサンプル入力に対してアルゴリズムを追跡します。
The following sections describe the four techniques used in
Bootstring. "Basic code point segregation" is a very simple and
efficient encoding for basic code points occurring in the extended
string: they are simply copied all at once. "Insertion unsort
coding" encodes the non-basic code points as deltas, and processes
the code points in numerical order rather than in order of
appearance, which typically results in smaller deltas. The deltas
are represented as "generalized variable-length integers", which use
basic code points to represent nonnegative integers. The parameters
of this integer representation are dynamically adjusted using "bias
adaptation", to improve efficiency when consecutive deltas have
similar magnitudes.
次の章はブースティングで使う４つのテクニックを記述します。「基本コー
ドポイント分離」が拡張文字列にある基本コードポイントの非常に単純で効
率的なコーディングです：ただコピーします。「非順序挿入コーディング」
が非基本コードポイントをデルタで表し、コードポイントを出現順ではなく
数値順で処理し、これにより一般に小さいデルタ値をもたらします。デルタ
は「一般化可変長整数」と表現され、これは非負整数の代わりとして基本コー
ドポイントを使います。この整数表現パラメータは、連続したデルタが類似
した大きさの場合に効率を改善するため、「バイアス調整」を使って動的に
調整されます。
3.1 Basic code point segregation
3.1 基本コードポイント分離
All basic code points appearing in the extended string are
represented literally at the beginning of the basic string, in their
original order, followed by a delimiter if (and only if) the number
of basic code points is nonzero. The delimiter is a particular basic
code point, which never appears in the remainder of the basic string.
The decoder can therefore find the end of the literal portion (if
there is one) by scanning for the last delimiter.
拡張文字列にある基本的なコードポイントは、基本文字列の始めにそのまま
の順序にそのままで設定され、基本コードポイントの数がゼロでなければ、
その後に区切文字が続きます。区切文字は特定の基本コードポイントで、そ
れは決して基本文字列の残りに現われません。従って解読者は最後の区切文
字を走査することでそのままの文字列の部分の終わりを見いだすことができ
ます（もしあるなら）。
3.2 Insertion unsort coding
3.2 非順序挿入コーディング
The remainder of the basic string (after the last delimiter if there
is one) represents a sequence of nonnegative integral deltas as
generalized variable-length integers, described in section 3.3. The
meaning of the deltas is best understood in terms of the decoder.
基本文字列の残り（もしあれば最後の区切り文字の後）が非負整数のデルタ
列で、３.３章の一般化可変長整数で記述します。デルタの意味はデコードの
際に最も理解しやすいです。
The decoder builds the extended string incrementally. Initially, the
extended string is a copy of the literal portion of the basic string
(excluding the last delimiter). The decoder inserts non-basic code
points, one for each delta, into the extended string, ultimately
arriving at the final decoded string.
デコーダは徐々に拡張文字列を作ります。初めに、拡張文字列は（最後の区
切り文字を除いて）基本文字列のそのままの部分のコピーです。デコーダは
非負コードポイントを各差分毎に拡張文字列に入れます、最終的にデコード
された文字列になります。
At the heart of this process is a state machine with two state
variables: an index i and a counter n. The index i refers to a
position in the extended string; it ranges from 0 (the first
position) to the current length of the extended string (which refers
to a potential position beyond the current end). If the current
state is <n,i>, the next state is <n,i+1> if i is less than the
length of the extended string, or <n+1,0> if i equals the length of
the extended string. In other words, each state change causes i to
increment, wrapping around to zero if necessary, and n counts the
number of wrap-arounds.
この処理の中心は２つ状態変数を持つ状態遷移図です：インデックスｉと、
カウンタｎ。インデックスｉは拡張文字列における場所を参照し；これは０
（最初の位置）から拡張文字列の現在の長さ（現在文字列の最後の位置）の
範囲です。もし現在の状態が<n,i>なら、もしｉが拡張文字列の長さより短け
れば次の状態が<n,i+1>で、もしｉが拡張文字列の長さと等しいなら<n+1,0>
です。言い換えれば、各状態変更でiが増加し、必要なら０に戻り、nが回っ
た回数です。
Notice that the state always advances monotonically (there is no way
for the decoder to return to an earlier state). At each state, an
insertion is either performed or not performed. At most one
insertion is performed in a given state. An insertion inserts the
value of n at position i in the extended string. The deltas are a
run-length encoding of this sequence of events: they are the lengths
of the runs of non-insertion states preceeding the insertion states.
Hence, for each delta, the decoder performs delta state changes, then
an insertion, and then one more state change. (An implementation
need not perform each state change individually, but can instead use
division and remainder calculations to compute the next insertion
state directly.) It is an error if the inserted code point is a
basic code point (because basic code points were supposed to be
segregated as described in section 3.1).
状態が常に一様に進むことに注意してください（デコーダが前の状態に戻る
方法がない）。各状態で、挿入が実行されるか、あるいはされません。ある
状態で挿入されるのは多くても１つです。挿入は拡張文字列の位置ｉに値ｎ
を挿入します。デルタはこのイベントのランレングスコーディングです：非
挿入状態が続く長さです。それ故、各デルタに対し、デコーダはデルタ回の
状態変更を行い、それから挿入し、次にもう１つ状態を変化します（実装が
状態変更を１つづつ行う必要がありません、直接次の挿入状態を計算するた
めに割り算を使って、計算を早くできます）。もし挿入コードポイントが基
本コードポイントならエラーです（基本コードポイントが３.１章で記述され
るように分離されることになっているから）。
The encoder's main task is to derive the sequence of deltas that will
cause the decoder to construct the desired string. It can do this by
repeatedly scanning the extended string for the next code point that
the decoder would need to insert, and counting the number of state
changes the decoder would need to perform, mindful of the fact that
the decoder's extended string will include only those code points
that have already been inserted. Section 6.3 "Encoding procedure"
gives a precise algorithm.
エンコーダの仕事は、デコーダが目的の文字列を生成すようなデルタ列を作
る事です。これは拡張文字列からデコーダが次に挿入するコードポイントを
繰り返し走査し、デコーダが行う状態変更回数を数えることで実施します、
デコーダの拡張文字列が挿入済みのコードポイントだけを含む事に気をつけ
てください。６.３章の「コーディング処理」が正確なアルゴリズムを与えま
す。
3.3 Generalized variable-length integers
3.3 一般化可変長整数
In a conventional integer representation the base is the number of
distinct symbols for digits, whose values are 0 through base-1. Let
digit_0 denote the least significant digit, digit_1 the next least
significant, and so on. The value represented is the sum over j of
digit_j * w(j), where w(j) = base^j is the weight (scale factor) for
position j. For example, in the base 8 integer 437, the digits are
7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 +
3*8 + 4*64 = 287. This representation has two disadvantages: First,
there are multiple encodings of each value (because there can be
extra zeros in the most significant positions), which is inconvenient
when unique encodings are needed. Second, the integer is not self-
delimiting, so if multiple integers are concatenated the boundaries
between them are lost.
従来の整数表示で基は区別できる記号の数で、各記号は０から基−１の値に
対応します。digit_0を最下位桁で、digit_1を最下位から次の桁、以下同様
とします。w(j) = base^jを各jに対する重さ（スケール量）とした時に、表
現される値は各jに対しするdigit_j×w(j)の合計値です。例えば、基が８の
整数４３７は、７と３と４の桁があり、各桁の重さは１と８と６４で、この
値は値は7 + 3*8 + 4*64 = 287になります。この表現は２つの欠点を持って
います：最初に、各値に対して多数のコーディング方法があります（最上位
桁にいくつでも０を設定できる）、これはユニークコーディングが必要な時
に不都合です。第二に、区切りがないので、もし多数の整数をつなぐと、そ
れらの間の境界線が失われます。
The generalized variable-length representation solves these two
problems. The digit values are still 0 through base-1, but now the
integer is self-delimiting by means of thresholds t(j), each of which
is in the range 0 through base-1. Exactly one digit, the most
significant, satisfies digit_j < t(j). Therefore, if several
integers are concatenated, it is easy to separate them, starting with
the first if they are little-endian (least significant digit first),
or starting with the last if they are big-endian (most significant
digit first). As before, the value is the sum over j of digit_j *
w(j), but the weights are different:
一般化可変長表現はこれらの２つの問題を解きます。各桁の値はやはり０か
ら基−１ですが、閾値t(j)によって区切りを持ち、これは０から基−１です。
正確に１つの桁が、最上位桁が、digit_j < t(j)を満たします。それ故、も
しいくつかの整数が連結されたらそれらを切り離すことは容易で、もしリト
ルエンディアン（下位桁が最初）なら列の頭から検査し、ビッグエンディア
ン（上位桁が最初）なら列の最後から検査します。前と同じように、値は
各jに対しするdigit_j×w(j)の合計値ですが、重さは異なっています：
w(0) = 1
w(j) = w(j-1) * (base - t(j-1)) for j > 0
For example, consider the little-endian sequence of base 8 digits
734251... Suppose the thresholds are 2, 3, 5, 5, 5, 5... This
implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) =
90, 90*(8-5) = 270, and so on. 7 is not less than 2, and 3 is not
less than 3, but 4 is less than 5, so 4 is the last digit. The value
of 734 is 7*1 + 3*6 + 4*30 = 145. The next integer is 251, with
value 2*1 + 5*6 + 1*30 = 62. Decoding this representation is very
similar to decoding a conventional integer: Start with a current
value of N = 0 and a weight w = 1. Fetch the next digit d and
increase N by d * w. If d is less than the current threshold (t)
then stop, otherwise increase w by a factor of (base - t), update t
for the next position, and repeat.
例えば、基が８のベースのリトルエンディアン列734251...を考えます。閾値
を発端が2、3、5、5、5、5・・・とします。これは重さが1、1*(8-2) = 6、
6*(8-3) = 30、30*(8-5) = 90、90*(8-5) = 270・・・であることを意味しま
す。７が２以上で、３が３以上で、４が５以下なので、４は最後の桁です。
７３４の価値は7*1 + 3*6 + 4*30 = 145です。次の整数は２５１で、値は
2*1 + 5*6 + 1*30 = 62です。この表現のデコードは従来の整数のデコードに
非常に類似します：初期値N=0と重さW=1から始めてください。次の桁dを取っ
て来て、Nにd*wを加算します。もしdが現在の閾値(t)以下なら終わりです、
そうでなければ重さwに（基−ｔ）を掛けて、tを新しい値にし、繰り返しま
す。
Encoding this representation is similar to encoding a conventional
integer: If N < t then output one digit for N and stop, otherwise
output the digit for t + ((N - t) mod (base - t)), then replace N
with (N - t) div (base - t), update t for the next position, and
repeat.
この表現をコード化することは従来の整数のコード化に類似します：もしN<t
ならNを１桁出力し停止します、そうでなければt + ((N - t) mod (base - t))
を出力し、Nを(N - t) div (base - t)で置き換えて、tを新しい値にして、
繰り返します。
For any particular set of values of t(j), there is exactly one
generalized variable-length representation of each nonnegative
integral value.
どんなt(j)値列でも、非負整数値に対して、正確に１つの一般化可変長表現
があります。
Bootstring uses little-endian ordering so that the deltas can be
separated starting with the first. The t(j) values are defined in
terms of the constants base, tmin, and tmax, and a state variable
called bias:
ブースティングは、デルタを先頭から切り離すために、リトルエンディア
ン順序を使います。t(j)値が基定数とtmin定数とtmax定数とバイアスと呼
ぶ状態変数に関して定義されます：
t(j) = base * (j + 1) - bias,
clamped to the range tmin through tmax
tminからtmaxの範囲に限定
The clamping means that if the formula yields a value less than tmin
or greater than tmax, then t(j) = tmin or tmax, respectively. (In
the pseudocode in section 6 "Bootstring algorithms", the expression
base * (j + 1) is denoted by k for performance reasons.) These t(j)
values cause the representation to favor integers within a particular
range determined by the bias.
限定は、もし式がtmin以下の値ならt(j) = tminに、tmax以上の値ならt(j) =
tamxであることを意味します。（６章の「ブースティングアルゴリズム」の
擬似コードで、表現base * (j + 1) は処理能力のためにｋで表しています。）
これらのt(j)値は、バイアスで決定された特定の範囲の整数で、値表現が有
利になります。
3.4 Bias adaptation
3.4 バイアス調整
After each delta is encoded or decoded, bias is set for the next
delta as follows:
各デルタのコード化やデコード後に、次のデルタのバイアス以下の様になり
ます：
1. Delta is scaled in order to avoid overflow in the next step:
1. デルタは次のステップで数値溢れを避けるために大きさを調整されます：
let delta = delta div 2
But when this is the very first delta, the divisor is not 2, but
instead a constant called damp. This compensates for the fact
that the second delta is usually much smaller than the first.
しかしこれが最初のデルタである時、２で割らずに、代わりのdampという
定数を使います。これは２番目のデルタが通常最初よりずっと小さいとい
う事実を埋め合わせます。
2. Delta is increased to compensate for the fact that the next delta
will be inserting into a longer string:
2. デルタは次のデルタがより長い文字列に挿入しているであろう事実を埋め
合わせるために増やされます：
let delta = delta + (delta div numpoints)
numpoints is the total number of code points encoded/decoded so
far (including the one corresponding to this delta itself, and
including the basic code points).
numpointsがこれまでのコード化／でコード化しているコードポイントの
合計の数です（このデルタ自身に対応しているもを含め、基本コードポイ
ントも含めて）。
3. Delta is repeatedly divided until it falls within a threshold, to
predict the minimum number of digits needed to represent the next
delta:
3. デルタは、次のデルタを表すために必要な桁の最小数を予想するために、
閾値に達するまで、繰り返して分割します：
while delta > ((base - tmin) * tmax) div 2
do let delta = delta div (base - tmin)
4. The bias is set:
4. バイアス設定：
let bias =
(base * the number of divisions performed in step 3) +
(((base - tmin + 1) * delta) div (delta + skew))
The motivation for this procedure is that the current delta
provides a hint about the likely size of the next delta, and so
t(j) is set to tmax for the more significant digits starting with
the one expected to be last, tmin for the less significant digits
up through the one expected to be third-last, and somewhere
between tmin and tmax for the digit expected to be second-last
(balancing the hope of the expected-last digit being unnecessary
against the danger of it being insufficient).
この手順のための動機づけは、可能性が高い次のデルタの大きさについて、
現在のデルタがヒントを供給するということで、そして最後と期待される
最上位桁のt(j)をtmaxに設定し、最下位桁から最後から３番目までをtmin
に設定し、最後から２番目のtminとtmaxの間のどこかに設定します。（最
終桁の希望と、失敗時の危険を均衡させている）。
4. Bootstring parameters
4. ブースティングパラメータ
Given a set of basic code points, one needs to be designated as the
delimiter. The base cannot be greater than the number of
distinguishable basic code points remaining. The digit-values in the
range 0 through base-1 need to be associated with distinct non-
delimiter basic code points. In some cases multiple code points need
to have the same digit-value; for example, uppercase and lowercase
versions of the same letter need to be equivalent if basic strings
are case-insensitive.
ある基本コードポイントで、１つの区切り記号は必要です。基は残りの識別
可能な基本コードポイントの数より大きいはずがありません。桁−値は０か
ら基−１の範囲で、それぞれ異なる区切り記号でない基本コードポイントと
結び付けられる必要があります。ある場合は多数のコードポイントが同じ桁
値を持つ必要があります；例えば、もし基本文字列が大文字小文字の違いを
無視するなら、同じ文字の大文字と小文字が等しい必要があります。
The initial value of n cannot be greater than the minimum non-basic
code point that could appear in extended strings.
初期値ｎは拡張文字列に現われる基本コードポイント以外の最小コードポイ
ントよりおおきいはずがありません。
The remaining five parameters (tmin, tmax, skew, damp, and the
initial value of bias) need to satisfy the following constraints:
残りの５つのパラメータは（tminとtmaxとskewとdampとバイアスの初期値）
は次の制約を満足する必要があります：
0 <= tmin <= tmax <= base-1
skew >= 1
damp >= 2
initial_bias mod base <= base - tmin
Provided the constraints are satisfied, these five parameters affect
efficiency but not correctness. They are best chosen empirically.
制約を満足したら、これらの５つのパラメータは正確さではなく、効率に影
響を与えます。それらは経験的に最も良く選択されます。
If support for mixed-case annotation is desired (see appendix A),
make sure that the code points corresponding to 0 through tmax-1 all
have both uppercase and lowercase forms.
もし大文字と小文字の混在をサポートするなら（付録Ｂ参照）、０から
tmax-1に対応しているコードポイントがすべて大文字と小文字の形を持って
いることを確かにしてください。
5. Parameter values for Punycode
5. プニコードのパラメータ値
Punycode uses the following Bootstring parameter values:
プニコードは次のブースティングパラメータ値を使います：
base = 36
tmin = 1
tmax = 26
skew = 38
damp = 700
initial_bias = 72
initial_n = 128 = 0x80
Although the only restriction Punycode imposes on the input integers
is that they be nonnegative, these parameters are especially designed
to work well with Unicode [UNICODE] code points, which are integers
in the range 0..10FFFF (but not D800..DFFF, which are reserved for
use by the UTF-16 encoding of Unicode). The basic code points are
the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the
delimiter, and some of the others have digit-values as follows:
プニコードが入力整数に課す唯一の制限はそれらが非負整数であるというこ
とですが、これらのパラメータはユニコード[UNICODE]コードポイントで特に
うまく働くよう意図されます、ユニコードは０〜１０ＦＦＦＦの範囲です
（但し、Ｄ８００〜ＤＦＦＦはＵＴＦ−１６のコード化のため予約されます）
基本的なコードポイントはＡＳＣＩＩ[ASCII]コードポイント（０〜７Ｆ）で、
U+002D(-)は区切りで、他のものは以下の値を持ちます：
code points digit-values
コードポイント 値
------------ ----------------------
41..5A (A-Z) = 0 to 25, respectively
61..7A (a-z) = 0 to 25, respectively
30..39 (0-9) = 26 to 35, respectively
Using hyphen-minus as the delimiter implies that the encoded string
can end with a hyphen-minus only if the Unicode string consists
entirely of basic code points, but IDNA forbids such strings from
being encoded. The encoded string can begin with a hyphen-minus, but
IDNA prepends a prefix. Therefore IDNA using Punycode conforms to
the RFC 952 rule that host name labels neither begin nor end with a
hyphen-minus [RFC952].
ハイフンマイナスを区切りと用いることは、ユニコード文字列が完全に基本
コードポイントから成り立つ場合に限り、コード化された文字列がハイフン
マイナスで終わることを意味しますが、ＩＤＮＡはこのような文字列がコー
ド化されることを禁止します。コード化文字列はハイフンマイナスから始ま
ることができますが、ＩＤＮＡは前にプレフィックスを付けます。それ故に
プニコードを使うＩＤＮＡはホスト名ラベルの始め終わりもハイフンマイナ
スではないというＲＦＣ９５２の規則に従います[RFC952]。
A decoder MUST recognize the letters in both uppercase and lowercase
forms (including mixtures of both forms). An encoder SHOULD output
only uppercase forms or only lowercase forms, unless it uses mixed-
case annotation (see appendix A).
デコーダは大文字も小文字も（両方の混合も）認識しなくてはなりません。
(MUST)エンコーダは混合表記を使わないなら、大文字か小文字のどちらか一
方だけを出力すべきです(SHOULD)（付録Ａ参照）。
Presumably most users will not manually write or type encoded strings
(as opposed to cutting and pasting them), but those who do will need
to be alert to the potential visual ambiguity between the following
sets of characters:
多分たいていのユーザーが手書きかタイプでコード化文字列を書かないでしょ
うが（カットアンドペーストを除いて）、そうする場合は次の文字の間の視
覚的なあいまい性に対して強く警戒する必要があります：
G 6
I l 1
O 0
S 5
U V
Z 2
Such ambiguities are usually resolved by context, but in a Punycode
encoded string there is no context apparent to humans.
このようなあいまい性は普通は文脈を見て解決されますが、プニコードでコー
ドされた文字列に人に明白な文脈がありません。
6. Bootstring algorithms
6. ブースティングアルゴリズム
Some parts of the pseudocode can be omitted if the parameters satisfy
certain conditions (for which Punycode qualifies). These parts are
enclosed in {braces}, and notes immediately following the pseudocode
explain the conditions under which they can be omitted.
もしパラメータが（プニコード内容が）ある特定の条件を満足するなら、擬
似コードのある部分を除くことができます。これらの部分は{括弧}で囲まれ、
擬似コードの後ので除ける条件を説明します。
Formally, code points are integers, and hence the pseudocode assumes
that arithmetic operations can be performed directly on code points.
In some programming languages, explicit conversion between code
points and integers might be necessary.
公式にいうと、コードポイントは整数で、それ故擬似コードは算術演算がコー
ドポイント上に直接行われることができると想定します。あるプログラム言
語で、コードポイントと整数の間の明白な変換が必要かもしれません。
6.1 Bias adaptation function
6.1 バイアス適合機能
function adapt(delta,numpoints,firsttime):
if firsttime then let delta = delta div damp
else let delta = delta div 2
let delta = delta + (delta div numpoints)
let k = 0
while delta > ((base - tmin) * tmax) div 2 do begin
let delta = delta div (base - tmin)
let k = k + base
end
return k + (((base - tmin + 1) * delta) div (delta + skew))
It does not matter whether the modifications to delta and k inside
adapt() affect variables of the same name inside the
encoding/decoding procedures, because after calling adapt() the
caller does not read those variables before overwriting them.
adapt()内のdeltaとkの修正が、エンコード／デコード処理の同名の変数を変
えなくても問題ありません、なぜなら呼び出し者は変数の上書きをするまで、
その変数を読まないからです。
6.2 Decoding procedure
6.2 解読処理
let n = initial_n
let i = 0
let bias = initial_bias
let output = an empty string indexed from 0
consume all code points before the last delimiter (if there is one)
and copy them to output, fail on any non-basic code point
if more than zero code points were consumed then consume one more
(which will be the last delimiter)
while the input is not exhausted do begin
let oldi = i
let w = 1
for k = base to infinity in steps of base do begin
consume a code point, or fail if there was none to consume
let digit = the code point's digit-value, fail if it has none
let i = i + digit * w, fail on overflow
let t = tmin if k <= bias {+ tmin}, or
tmax if k >= bias + tmax, or k - bias otherwise
if digit < t then break
let w = w * (base - t), fail on overflow
end
let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
let n = n + i div (length(output) + 1), fail on overflow
let i = i mod (length(output) + 1)
{if n is a basic code point then fail}
insert n into output at position i
increment i
end
The full statement enclosed in braces (checking whether n is a basic
code point) can be omitted if initial_n exceeds all basic code points
(which is true for Punycode), because n is never less than initial_n.
（ｎが基本的なコードポイントであるかどうか調べている）括弧内の文は、
ｎが決してinitial_nより少くないから、もしinitial_nがすべての基本的な
コードポイントより大きい（プニコードについて本当である）、省略できま
す。
In the assignment of t, where t is clamped to the range tmin through
tmax, "+ tmin" can always be omitted. This makes the clamping
calculation incorrect when bias < k < bias + tmin, but that cannot
happen because of the way bias is computed and because of the
constraints on the parameters.
ｔの割当てで、ｔがtminからtmaxの範囲に固定されるので、"+ tmin"が常に
省略できます。これはbias < k < bias + tminである時に固定計算を正しく
なくしますが、バイアスの計算方法と、パラメータの制約から、起きること
がありません。
Because the decoder state can only advance monotonically, and there
is only one representation of any delta, there is therefore only one
encoded string that can represent a given sequence of integers. The
only error conditions are invalid code points, unexpected end-of-
input, overflow, and basic code points encoded using deltas instead
of appearing literally. If the decoder fails on these errors as
shown above, then it cannot produce the same output for two distinct
inputs. Without this property it would have been necessary to re-
encode the output and verify that it matches the input in order to
guarantee the uniqueness of the encoding.
デコーダ状態がただ一方向に進むだけで、そしてデルタの表現がただ１つだ
けなので、それ故に与えられた数値列を表すことができるただ１つのコード
化文字列があります。エラー条件は無効なコードポイントと、意外な入力の
終了と、溢れと、最初に現れるのではなくデルタを使ってコード化された基
本コードポイントです。もしデコーダーが上記のエラーで失敗するなら、そ
れは２つの異なる入力で同じ出力を作り出すことができません。この特性が
なければ、出力を再度コード化し、そしてコーディングの一意性を保証する
ために入力に一致するか確かめることは必要であったでしょう。
6.3 Encoding procedure
6.3 コード化手順
let n = initial_n
let delta = 0
let bias = initial_bias
let h = b = the number of basic code points in the input
copy them to the output in order, followed by a delimiter if b > 0
{if the input contains a non-basic code point < n then fail}
while h < length(input) do begin
let m = the minimum {non-basic} code point >= n in the input
let delta = delta + (m - n) * (h + 1), fail on overflow
let n = m
for each code point c in the input (in order) do begin
if c < n {or c is basic} then increment delta, fail on overflow
if c == n then begin
let q = delta
for k = base to infinity in steps of base do begin
let t = tmin if k <= bias {+ tmin}, or
tmax if k >= bias + tmax, or k - bias otherwise
if q < t then break
output the code point for digit t + ((q - t) mod (base - t))
let q = (q - t) div (base - t)
end
output the code point for digit q
let bias = adapt(delta, h + 1, test h equals b?)
let delta = 0
increment h
end
end
increment delta and n
end
The full statement enclosed in braces (checking whether the input
contains a non-basic code point less than n) can be omitted if all
code points less than initial_n are basic code points (which is true
for Punycode if code points are unsigned).
（入力にｎより小さい非基本的コードポイントがあるかどうか調べている）
括弧内の文は、initial_nより小さい全てのコードポイントが基本コードポ
イントなら（プニコードについて本当である）、省略できます。
The brace-enclosed conditions "non-basic" and "or c is basic" can be
omitted if initial_n exceeds all basic code points (which is true for
Punycode), because the code point being tested is never less than
initial_n.
括弧で囲まれた"non-basic"と"or c is basic"は、もしinitial_nがすべての
基本的なコードポイントを超えるなら、テストされているコードポイントが
決してinitial_nより小さくないので、省略できます（プニコードについて本
当です）。
In the assignment of t, where t is clamped to the range tmin through
tmax, "+ tmin" can always be omitted. This makes the clamping
calculation incorrect when bias < k < bias + tmin, but that cannot
happen because of the way bias is computed and because of the
constraints on the parameters.
ｔの割当てで、ｔがtminからtmaxの範囲に固定されるので、"+ tmin"が常に
省略できます。これはbias < k < bias + tminである時に固定計算を正しく
なくしますが、バイアスの計算方法と、パラメータの制約から、起きること
がありません。
The checks for overflow are necessary to avoid producing invalid
output when the input contains very large values or is very long.
入力が非常に大きい値を含んでいるか、あるいは非常に長い時、あふれ検査
は、無効な出力を作り出すのを避けるために必要です。
The increment of delta at the bottom of the outer loop cannot
overflow because delta < length(input) before the increment, and
length(input) is already assumed to be representable. The increment
of n could overflow, but only if h == length(input), in which case
the procedure is finished anyway.
外のループの一番下のデルタの増加は、増加前にdelta < length(input)で、
length(input)が既に表現可能と考えられるから、あふれることができません。
ｎの増加はあふれることがありえますが、もしh == length(input)の場合だ
けで、この場合いずれにしろ手順が終了します。
6.4 Overflow handling
6.4 溢れ処理
For IDNA, 26-bit unsigned integers are sufficient to handle all valid
IDNA labels without overflow, because any string that needed a 27-bit
delta would have to exceed either the code point limit (0..10FFFF) or
the label length limit (63 characters). However, overflow handling
is necessary because the inputs are not necessarily valid IDNA
labels.
２７ビットのデルタを必要とする文字列は、コードポイント限界(0..10FFFF)
を超えるか長さ限界（６３の文字）を超えるので、ＩＤＮＡで２６ビットの
符号なしの整数があふれなしですべての正当なＩＤＮＡラベルを処理するた
めに十分です。しかしながら、入力が必ずしも正当なＩＤＮＡラベルではな
いから、溢れ処理が必要です。
If the programming language does not provide overflow detection, the
following technique can be used. Suppose A, B, and C are
representable nonnegative integers and C is nonzero. Then A + B
overflows if and only if B > maxint - A, and A + (B * C) overflows if
and only if B > (maxint - A) div C, where maxint is the greatest
integer for which maxint + 1 cannot be represented. Refer to
appendix C "Punycode sample implementation" for demonstrations of
this technique in the C language.
訳注：RFC誤植情報によると、上記の"where maxint is the greatest integer
for which maxint + 1 cannot be represented."は"where maxint is the
maximum value of an integer variable."が正しいそうです。
もしプログラム言語が溢れ発見を供給しないなら、次のテクニックを使われ
ることができます。ＡとＢとＣが表現可能な非負整数で、Ｃがゼロ以外とし
ます。最大整数値を整数変数の最大値とすると、Ａ＋Ｂが溢れるのは
Ｂ＞最大整数値−Ａの時だけで、Ａ＋（Ｂ×Ｃ）が溢れるのは
Ｂ＞（最大性数値−Ａ）÷Ｃの時だけです。Ｃ言語でこの技法の実演説明の
ために付録Ｃ「プニコードサンプル実装」に参照してください。
The decoding and encoding algorithms shown in sections 6.2 and 6.3
handle overflow by detecting it whenever it happens. Another
approach is to enforce limits on the inputs that prevent overflow
from happening. For example, if the encoder were to verify that no
input code points exceed M and that the input length does not exceed
L, then no delta could ever exceed (M - initial_n) * (L + 1), and
hence no overflow could occur if integer variables were capable of
representing values that large. This prevention approach would
impose more restrictions on the input than the detection approach
does, but might be considered simpler in some programming languages.
６.２章と６.３章で示す解読とコード化アルゴリズムは、溢れが起こるとこ
ろで検出する事で溢れを処理します。もう１つの方法が溢れ起きるのを阻止
するため入力に限界を強制することです。例えば、もしコード化で入力コー
ドポイントがＭを超えず入力長がＬを超えないことを確かめるなら、デルタ
は（Ｍ−initial_n）×（Ｌ＋１）を超えず、したがって整数がこれ以上の値
を表現できれば溢れは起こりません。この防止方法は検出する方法より入力
により多くの制限を課すであろうが、しかしあるプログラム言語ではより単
純であると思われるかもしれません。
In theory, the decoder could use an analogous approach, limiting the
number of digits in a variable-length integer (that is, limiting the
number of iterations in the innermost loop). However, the number of
digits that suffice to represent a given delta can sometimes
represent much larger deltas (because of the adaptation), and hence
this approach would probably need integers wider than 32 bits.
理論上解読者は、可変長整数の桁数を制限することで、同様の方法を使用で
きます（それが一番奥のループの繰り返し回数を制限します）。しかしなが
ら、与えられたデルタを表すのに十分である桁数は（適合のために）しばし
ばより大きいデルタを表すことができ、それ故この方法は恐らく３２ビット
より大きい整数を必要とするでしょう。
Yet another approach for the decoder is to allow overflow to occur,
but to check the final output string by re-encoding it and comparing
to the decoder input. If and only if they do not match (using a
case-insensitive ASCII comparison) overflow has occurred. This
delayed-detection approach would not impose any more restrictions on
the input than the immediate-detection approach does, and might be
considered simpler in some programming languages.
さらに他の解読時の方法は、あふれに起こることを許し、出力を再度コード
化して、解読の入力と比較することで、出力文字列を検査することです。も
し（大文字小文字の違いを無視するＡＳＣＩＩ比較で）それが一致しない場
合に限り溢れが起こっています。この事後検出方法は即時検出方法より入力
制限を課すことはなく、あるプログラミング言語でより単純であると思われ
ます。
In fact, if the decoder is used only inside the IDNA ToUnicode
operation [IDNA], then it need not check for overflow at all, because
ToUnicode performs a higher level re-encoding and comparison, and a
mismatch has the same consequence as if the Punycode decoder had
failed.
実際、もし解読がＩＤＮＡのToUnicode演算[IDNA]内でだけ使われるなら、まっ
たくあふれを調べる必要がありません、なぜならToUnicodeはもっと上位レベ
ルで再コーディングと比較を行い、不一致はプニコード解読が失敗したのと
同じ結果を生じます。
7. Punycode examples
7. プニコード例
7.1 Sample strings
7.1 サンプル文字列
In the Punycode encodings below, the ACE prefix is not shown.
Backslashes show where line breaks have been inserted in strings too
long for one line.
下記のプニコードコード化で、ＡＣＥプレフィックスは記述しません。１行
には長すぎる文字列に、バックスラッシュが挿入されています。
The first several examples are all translations of the sentence "Why
can't they just speak in <language>?" (courtesy of Michael Kaplan's
"provincial" page [PROVINCIAL]). Word breaks and punctuation have
been removed, as is often done in domain names.
最初のいくつかの例はすべて"Why can't they just speak in <language>?"
（マイケル・カプランの[PROVINCIAL]の「地方」ページの転載）の翻訳です。
単語区切りと句読点は、ドメイン名でしばしばされるように、除去しました。
(A) Arabic (Egyptian):
(A) アラブ語（エジプト語）:
u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
Punycode: egbpdaj6bu4bxfgehfvwxn
(B) Chinese (simplified):
(B) 中国語（簡易）:
u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
Punycode: ihqwcrb4cv8a8dqg056pqjye
(C) Chinese (traditional):
(C) 中国語（伝統）:
u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
Punycode: ihqwctvzc91f659drss3x8bo0yb
(D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
(D) チェコ:
U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
u+0065 u+0073 u+006B u+0079
Punycode: Proprostnemluvesky-uyb24dma41a
(E) Hebrew:
(E) ヘブライ語:
u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
u+05D1 u+05E8 u+05D9 u+05EA
Punycode: 4dbcagdahymbxekheh6e0a7fei0b
(F) Hindi (Devanagari):
(F) ヒンディー語:
u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
u+0939 u+0948 u+0902
Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
(G) Japanese (kanji and hiragana):
(G) 日本語（漢字と平仮名）:
u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
(H) Korean (Hangul syllables):
(H) 韓国語（ハングル音節）:
u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
psd879ccm6fea98c
(I) Russian (Cyrillic):
(I) ロシア語（キリル文字）:
U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
u+0438
Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
(J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
(J) スペイン語:
U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
u+0061 u+00F1 u+006F u+006C
Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
(K) Vietnamese:
(K) ベトナム語:
T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
<ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
U+0056 u+0069 u+1EC7 u+0074
Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
The next several examples are all names of Japanese music artists,
song titles, and TV programs, just because the author happens to have
them handy (but Japanese is useful for providing examples of single-
row text, two-row text, ideographic text, and various mixtures
thereof).
次のいくつかの例はすべての、著者がたまたま使えた、日本の音楽芸術家の
名前と歌の題名とＴＶ番組です。（けれども日本語は１桁文字、２桁文字、
表意文字、それらの混合の例を供給することに役立ちます）。
(L) 3<nen>B<gumi><kinpachi><sensei>
(L) ３年Ｂ組金八先生
u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
Punycode: 3B-ww4c5e180e575a65lsy2b
(M) <amuro><namie>-with-SUPER-MONKEYS
(M) 安室奈美恵-with-SUPER-MONKEYS
u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
U+004F U+004E U+004B U+0045 U+0059 U+0053
Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
(N) Hello-Another-Way-<sorezore><no><basho>
(N) Hello-Another-Way-それぞれの場所
U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
(O) <hitotsu><yane><no><shita>2
(O) ひとつ屋根の下2
u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
Punycode: 2-u9tlzr9756bt3uc0v
(P) Maji<de>Koi<suru>5<byou><mae>
(P) MajiでKoiする5秒前
U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
u+308B u+0035 u+79D2 u+524D
Punycode: MajiKoi5-783gue6qz075azm5e
(Q) <pafii>de<runba>
(Q) パフィdeルンバ
u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
Punycode: de-jg4avhby1noc0d
(R) <sono><supiido><de>
(R) そのスピードで
u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
Punycode: d9juau41awczczp
The last example is an ASCII string that breaks the existing rules
for host name labels. (It is not a realistic example for IDNA,
because IDNA never encodes pure ASCII labels.)
最後の例はホスト名ラベルのために既存の規則を壊すＡＳＣＩＩ文字列です。
（ＩＤＮＡは決して純粋なＡＳＣＩＩラベルをコード化しないので、これは
ＩＤＮＡの現実的な例ではありません）。
(S) -> $1.00 <-
u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
u+003C u+002D
Punycode: -> $1.00 <--
7.2 Decoding traces
7.2 解読跡
In the following traces, the evolving state of the decoder is shown
as a sequence of hexadecimal values, representing the code points in
the extended string. An asterisk appears just after the most
recently inserted code point, indicating both n (the value preceeding
the asterisk) and i (the position of the value just after the
asterisk). Other numerical values are decimal.
次は、拡張文字列をコードポイントを表す１６進値の列で、解読の進行跡を
示します。アスタリスクが、ｎ（アスタリスクの直前の値）とｉ（アスタリ
スクの直後の値の位置）の両方を示し、最も最近差し込まれたコードポイン
トのすぐ後に現われます。他の数の値は１０進数です。
Decoding trace of example B from section 7.1:
７.１章の例Ｂの解読跡
n is 128, i is 0, bias is 72
input is "ihqwcrb4cv8a8dqg056pqjye"
there is no delimiter, so extended string starts empty
delta "ihq" decodes to 19853
bias becomes 21
4E0D *
delta "wc" decodes to 64
bias becomes 20
4E0D 4E2D *
delta "rb" decodes to 37
bias becomes 13
4E3A * 4E0D 4E2D
delta "4c" decodes to 56
bias becomes 17
4E3A 4E48 * 4E0D 4E2D
delta "v8a" decodes to 599
bias becomes 32
4E3A 4EC0 * 4E48 4E0D 4E2D
delta "8d" decodes to 130
bias becomes 23
4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
delta "qg" decodes to 154
bias becomes 25
4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
delta "056p" decodes to 46301
bias becomes 84
4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
delta "qjye" decodes to 88531
bias becomes 90
4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
Decoding trace of example L from section 7.1:
７.１章の例Ｌの解読跡
n is 128, i is 0, bias is 72
input is "3B-ww4c5e180e575a65lsy2b"
literal portion is "3B-", so extended string starts as:
0033 0042
delta "ww4c" decodes to 62042
bias becomes 27
0033 0042 5148 *
delta "5e" decodes to 139
bias becomes 24
0033 0042 516B * 5148
delta "180e" decodes to 16683
bias becomes 67
0033 5E74 * 0042 516B 5148
delta "575a" decodes to 34821
bias becomes 82
0033 5E74 0042 516B 5148 751F *
delta "65l" decodes to 14592
bias becomes 67
0033 5E74 0042 7D44 * 516B 5148 751F
delta "sy2b" decodes to 42088
bias becomes 84
0033 5E74 0042 7D44 91D1 * 516B 5148 751F
7.3 Encoding traces
7.3 コード化跡
In the following traces, code point values are hexadecimal, while
other numerical values are decimal.
次の跡で、コードポイント値は１６進数で、他の数値は１０進数です。
Encoding trace of example B from section 7.1:
７.１章の例Ｂのコード化跡
bias is 72
input is:
4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
there are no basic code points, so no literal portion
next code point to insert is 4E0D
needed delta is 19853, encodes as "ihq"
bias becomes 21
next code point to insert is 4E2D
needed delta is 64, encodes as "wc"
bias becomes 20
next code point to insert is 4E3A
needed delta is 37, encodes as "rb"
bias becomes 13
next code point to insert is 4E48
needed delta is 56, encodes as "4c"
bias becomes 17
next code point to insert is 4EC0
needed delta is 599, encodes as "v8a"
bias becomes 32
next code point to insert is 4ED6
needed delta is 130, encodes as "8d"
bias becomes 23
next code point to insert is 4EEC
needed delta is 154, encodes as "qg"
bias becomes 25
next code point to insert is 6587
needed delta is 46301, encodes as "056p"
bias becomes 84
next code point to insert is 8BF4
needed delta is 88531, encodes as "qjye"
bias becomes 90
output is "ihqwcrb4cv8a8dqg056pqjye"
Encoding trace of example L from section 7.1:
７.１章の例Ｌのコード化跡
bias is 72
input is:
0033 5E74 0042 7D44 91D1 516B 5148 751F
basic code points (0033, 0042) are copied to literal portion: "3B-"
next code point to insert is 5148
needed delta is 62042, encodes as "ww4c"
bias becomes 27
next code point to insert is 516B
needed delta is 139, encodes as "5e"
bias becomes 24
next code point to insert is 5E74
needed delta is 16683, encodes as "180e"
bias becomes 67
next code point to insert is 751F
needed delta is 34821, encodes as "575a"
bias becomes 82
next code point to insert is 7D44
needed delta is 14592, encodes as "65l"
bias becomes 67
next code point to insert is 91D1
needed delta is 42088, encodes as "sy2b"
bias becomes 84
output is "3B-ww4c5e180e575a65lsy2b"
8. Security Considerations
8. セキュリティの考察
Users expect each domain name in DNS to be controlled by a single
authority. If a Unicode string intended for use as a domain label
could map to multiple ACE labels, then an internationalized domain
name could map to multiple ASCII domain names, each controlled by a
different authority, some of which could be spoofs that hijack
service requests intended for another. Therefore Punycode is
designed so that each Unicode string has a unique encoding.
ユーザがＤＮＳの各ドメイン名が一人の権威によって制御されることを期待
します。もしドメインラベルに使うことを意図するユニコード文字列が多数
のＡＣＥラベルに投影できるなら、国際化ドメイン名がそれぞれが異なる権
威によって制御された多数のＡＳＣＩＩドメイン名に投影でき、そのいくつ
かは権威の対するサービス要求をハイジャックする詐欺であり得ます。それ
故にプニコードが、各ユニコード文字列が一意のコーディングを持つように、
設計されます。
However, there can still be multiple Unicode representations of the
"same" text, for various definitions of "same". This problem is
addressed to some extent by the Unicode standard under the topic of
canonicalization, and this work is leveraged for domain names by
Nameprep [NAMEPREP].
しかしながら、「同じ」の種々な定義のため、「同じ」テキストの多数のユ
ニコード表現があり得ます。この問題はユニコード標準に正規化のトピック
の下である程度扱われます、そしてこの仕事は名前前処理[NAMEPREP]によっ
てドメイン名で行使されます。
9. References
9. 参考文献
9.1 Normative References
9.1 参照する参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative References
9.2 有益な参考文献
[RFC952] Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
Host Table Specification", RFC 952, October 1985.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)", RFC
3491, March 2003.
[ASCII] Cerf, V., "ASCII format for Network Interchange", RFC
20, October 1969.
[PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page",
http://www.trigeminal.com/samples/provincial.html.
[UNICODE] The Unicode Consortium, "The Unicode Standard",
http://www.unicode.org/unicode/standard/standard.html.
A. Mixed-case annotation
A. 大文字小文字の混合の注釈
In order to use Punycode to represent case-insensitive strings,
higher layers need to case-fold the strings prior to Punycode
encoding. The encoded string can use mixed case as an annotation
telling how to convert the folded string into a mixed-case string for
display purposes. Note, however, that mixed-case annotation is not
used by the ToASCII and ToUnicode operations specified in [IDNA], and
therefore implementors of IDNA can disregard this appendix.
大文字小文字の違いを無視する文字列を表すためにプニコードを使うために、
より高いレイヤでプニコードコーディングの前に文字列の大文字小文字をあ
わせる必要があります。コード化された文字列は表示目的のためにどのよう
に大文字小文字をあわせた文字列を、大文字小文字の混ざった文字列に変換
するべきか述べる注釈として、大文字小文字の混在を使うことができます。
しかしながら、大文字小文字の混在の注記は[IDNA]の指定するToASCII演算と
ToUnicode演算で使えず、それゆえＩＤＮＡの実装はこの付録を無視すること
ができることを注意してください。
Basic code points can use mixed case directly, because the decoder
copies them verbatim, leaving lowercase code points lowercase, and
leaving uppercase code points uppercase. Each non-basic code point
is represented by a delta, which is represented by a sequence of
basic code points, the last of which provides the annotation. If it
is uppercase, it is a suggestion to map the non-basic code point to
uppercase (if possible); if it is lowercase, it is a suggestion to
map the non-basic code point to lowercase (if possible).
解読者は、小文字コードポイントを小文字のままにし、大文字コードポイン
トを大文字のままにし、逐語的にそれらをコピーするので、基本的なコード
ポイントが直接大文字小文字の混在を使うことができます。各基本でないコー
ドポイントがデルタで表現され、そしてこれは基本コードポイント列で表現
され、その最後が注釈を供給出来ます。もしそれが大文字なら基本的でない
コードポイントを大文字にマップし（もし可能でなら）、もしそれが小文字
なら基本的でないコードポイントを小文字にマップする（もし可能でなら）、
のを提案します。
These annotations do not alter the code points returned by decoders;
the annotations are returned separately, for the caller to use or
ignore. Encoders can accept annotations in addition to code points,
but the annotations do not alter the output, except to influence the
uppercase/lowercase form of ASCII letters.
これらの注釈は解読によって返されたコードポイントを変えません；注釈は
呼び出し者が使うか無視するか出来るように、別に返されます。エンコーダ
がコードポイントのほかに注釈を受け入れることができます、しかし注釈は
ＡＳＣＩＩ文字の大文字／小文字形式に影響を与えるため以外には、出力を
変更しません。
Punycode encoders and decoders need not support these annotations,
and higher layers need not use them.
プニコードエンコーダと解読者がこれらの注釈をサポートする必要がありま
せん、そしてより高い層がそれらを使う必要がありません。
B. Disclaimer and license
B. 断り書きと許可
Regarding this entire document or any portion of it (including the
pseudocode and C code), the author makes no guarantees and is not
responsible for any damage resulting from its use. The author grants
irrevocable permission to anyone to use, modify, and distribute it in
any way that does not diminish the rights of anyone else to use,
modify, and distribute it, provided that redistributed derivative
works do not contain misleading author or version information.
Derivative works need not be licensed under similar terms.
この文書の全部や一部に関して（擬似コードとＣコードを含めて）、著
者は保証をせず、そしてその使用の結果として生じる損害に関して責任
がありません。著者は、再配布された派生的な仕事が紛らわしい著者や
版情報を含まなければ、他人の使用と変更と配布の権利を減らさない任
意の方法での、だれも使用と変更と配布をできる取り消しできない許可
に応じます。派生的な仕事が類似の項の下で認可される必要がありませ
ん。
C. Punycode sample implementation
C. プニコードサンプル実装
/*
punycode.c from RFC 3492
http://www.nicemice.net/idn/
Adam M. Costello
http://www.nicemice.net/amc/
This is ANSI C code (C89) implementing Punycode (RFC 3492).
*/
/************************************************************/
/* Public interface (would normally go in its own .h file): */
#include <limits.h>
enum punycode_status {
punycode_success,
punycode_bad_input, /* Input is invalid. */
punycode_big_output, /* Output would exceed the space provided. */
punycode_overflow /* Input needs wider integers to process. */
};
#if UINT_MAX >= (1 << 26) - 1
typedef unsigned int punycode_uint;
#else
typedef unsigned long punycode_uint;
#endif
enum punycode_status punycode_encode(
punycode_uint input_length,
const punycode_uint input[],
const unsigned char case_flags[],
punycode_uint *output_length,
char output[] );
/* punycode_encode() converts Unicode to Punycode. The input */
/* is represented as an array of Unicode code points (not code */
/* units; surrogate pairs are not allowed), and the output */
/* will be represented as an array of ASCII code points. The */
/* output string is *not* null-terminated; it will contain */
/* zeros if and only if the input contains zeros. (Of course */
/* the caller can leave room for a terminator and add one if */
/* needed.) The input_length is the number of code points in */
/* the input. The output_length is an in/out argument: the */
/* caller passes in the maximum number of code points that it */
/* can receive, and on successful return it will contain the */
/* number of code points actually output. The case_flags array */
/* holds input_length boolean values, where nonzero suggests that */
/* the corresponding Unicode character be forced to uppercase */
/* after being decoded (if possible), and zero suggests that */
/* it be forced to lowercase (if possible). ASCII code points */
/* are encoded literally, except that ASCII letters are forced */
/* to uppercase or lowercase according to the corresponding */
/* uppercase flags. If case_flags is a null pointer then ASCII */
/* letters are left as they are, and other code points are */
/* treated as if their uppercase flags were zero. The return */
/* value can be any of the punycode_status values defined above */
/* except punycode_bad_input; if not punycode_success, then */
/* output_size and output might contain garbage. */
/* punycode_encode()がユニコードをプニコードに変換します。入力は */
/* ユニコードコードポイントの配列（コード単位；代理対は許されな */
/* い）として表現されます、そして出力はＡＳＣＩＩコードポイントの */
/* 配列として表現されるでしょう。出力文字列なヌルで終わって＊いま */
/* せん＊：これは、もし入力がゼロを含んでいる場合に限り、そしてそ */
/* の場合には必ず、ゼロを含んでいるでしょう。（もちろん呼び出し人 */
/* は必要なら界線を明示するために追加するスペースを残すことができ */
/* ます。）input_lengthは入力コードポイントの数です。output_length*/
/* は入出力引数です：呼び出し人は受け取ることができるコードポイン */
/* トの最大の数を渡し、成功して戻った場合、実際に出力されたコード */
/* ポイントの数を含んでいるでしょう。case_flags配列はinput_length */
/* ブール値を持ち、ゼロ以外である場合は対応するユニコード文字が、 */
/* （もし可能であるなら）、解読された後で大文字に強制されることを */
/* 提案します、そしてゼロが、（もし可能であるなら）小文字に強制さ */
/* れることを示唆します。ＡＳＣＩＩコードポイントが、ＡＳＣＩＩ文 */
/* 字が対応するuppercaseフラグに従って大文字あるいは小文字にされる*/
/* 以外、そのままコード化されます。もしcase_flagsがヌルポインタで */
/* あるなら、ＡＳＣＩＩ文字がそのままで、他のコードポイントは */
/* uppercaseフラグがゼロであるかのように扱われます。帰り値は */
/* punycode_bad_input以外は上で定義されるpunycode_status値のどれ */
/* かです；punycode_successでなければ、output_sizeと出力は無意味 */
/* な値を含んでいるかもしれません。 */
enum punycode_status punycode_decode(
punycode_uint input_length,
const char input[],
punycode_uint *output_length,
punycode_uint output[],
unsigned char case_flags[] );
/* punycode_decode() converts Punycode to Unicode. The input is */
/* represented as an array of ASCII code points, and the output */
/* will be represented as an array of Unicode code points. The */
/* input_length is the number of code points in the input. The */
/* output_length is an in/out argument: the caller passes in */
/* the maximum number of code points that it can receive, and */
/* on successful return it will contain the actual number of */
/* code points output. The case_flags array needs room for at */
/* least output_length values, or it can be a null pointer if the */
/* case information is not needed. A nonzero flag suggests that */
/* the corresponding Unicode character be forced to uppercase */
/* by the caller (if possible), while zero suggests that it be */
/* forced to lowercase (if possible). ASCII code points are */
/* output already in the proper case, but their flags will be set */
/* appropriately so that applying the flags would be harmless. */
/* The return value can be any of the punycode_status values */
/* defined above; if not punycode_success, then output_length, */
/* output, and case_flags might contain garbage. On success, the */
/* decoder will never need to write an output_length greater than */
/* input_length, because of how the encoding is defined. */
/* punycode_decode()がプニコードをユニコードに変換します。入力は */
/* ＡＳＣＩＩコードポイント配列として表現され、出力はユニコード */
/* コードポイント配列として表現されるでしょう。input_lengthは入力 */
/* コードポイントの数です。output_length入出力引数です：呼び出し */
/* 人はそれが受け取ることができるコードポイントの最大の数を渡し、 */
/* 成功して帰った場合は出力されたコードポイントの実際の数を含んで */
/* いるでしょう。case_flags配列は、少なくともoutput_length値の空 */
/* 間が必要か、あるいは大文字小文字情報が必要ないならヌルポインタ */
/* であり得ます。nonzeroフラグが対応するユニコード文字が、呼び出 */
/* し人によって（もし可能であるなら）大文字に押し付けられることを */
/* 示唆し、他方ゼロが（もし可能であるとしても）小文字に強制される */
/* ことをことを示唆します。ＡＳＣＩＩコードポイントが適切な大文字 */
/* 小文字で出力されます、しかしそれらのフラグは、フラグを応用する */
/* ことが無害であるであるように、適切に設定されるでしょう。戻り値 */
/* は上に定義されるpunycode_status値のどれかです；もし */
/* punycode_successでなければ、output_lengthと出力とcase_flagsが */
/* 無意味な値を含んでいるかもしれません。成功したら、コーディング */
/* が定義される方法により、解読者は決してinput_lengthより大きい */
/* output_lengthを書く必要がないでしょう。 */
/**********************************************************/
/* Implementation (would normally go in its own .c file): */
#include <string.h>
/*** Bootstring parameters for Punycode ***/
enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
/* basic(cp) tests whether cp is a basic code point: */
#define basic(cp) ((punycode_uint)(cp) < 0x80)
/* delim(cp) tests whether cp is a delimiter: */
#define delim(cp) ((cp) == delimiter)
/* decode_digit(cp) returns the numeric value of a basic code */
/* point (for use in representing integers) in the range 0 to */
/* base-1, or base if cp is does not represent a value. */
static punycode_uint decode_digit(punycode_uint cp)
{
return cp - 48 < 10 ? cp - 22 : cp - 65 < 26 ? cp - 65 :
cp - 97 < 26 ? cp - 97 : base;
}
/* encode_digit(d,flag) returns the basic code point whose value */
/* (when used for representing integers) is d, which needs to be in */
/* the range 0 to base-1. The lowercase form is used unless flag is */
/* nonzero, in which case the uppercase form is used. The behavior */
/* is undefined if flag is nonzero and digit d has no uppercase form. */
static char encode_digit(punycode_uint d, int flag)
{
return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
/* 0..25 map to ASCII a..z or A..Z */
/* 26..35 map to ASCII 0..9 */
}
/* flagged(bcp) tests whether a basic code point is flagged */
/* (uppercase). The behavior is undefined if bcp is not a */
/* basic code point. */
#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
/* encode_basic(bcp,flag) forces a basic code point to lowercase */
/* if flag is zero, uppercase if flag is nonzero, and returns */
/* the resulting code point. The code point is unchanged if it */
/* is caseless. The behavior is undefined if bcp is not a basic */
/* code point. */
static char encode_basic(punycode_uint bcp, int flag)
{
bcp -= (bcp - 97 < 26) << 5;
return bcp + ((!flag && (bcp - 65 < 26)) << 5);
}
/*** Platform-specific constants ***/
/* maxint is the maximum value of a punycode_uint variable: */
static const punycode_uint maxint = -1;
/* Because maxint is unsigned, -1 becomes the maximum value. */
/*** Bias adaptation function ***/
static punycode_uint adapt(
punycode_uint delta, punycode_uint numpoints, int firsttime )
{
punycode_uint k;
delta = firsttime ? delta / damp : delta >> 1;
/* delta >> 1 is a faster way of doing delta / 2 */
delta += delta / numpoints;
for (k = 0; delta > ((base - tmin) * tmax) / 2; k += base) {
delta /= base - tmin;
}
return k + (base - tmin + 1) * delta / (delta + skew);
}
/*** Main encode function ***/
enum punycode_status punycode_encode(
punycode_uint input_length,
const punycode_uint input[],
const unsigned char case_flags[],
punycode_uint *output_length,
char output[] )
{
punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
/* Initialize the state: */
n = initial_n;
delta = out = 0;
max_out = *output_length;
bias = initial_bias;
/* Handle the basic code points: */
for (j = 0; j < input_length; ++j) {
if (basic(input[j])) {
if (max_out - out < 2) return punycode_big_output;
output[out++] =
case_flags ? encode_basic(input[j], case_flags[j]) : input[j];
}
/* else if (input[j] < n) return punycode_bad_input; */
/* (not needed for Punycode with unsigned code points) */
}
h = b = out;
/* h is the number of code points that have been handled, b is the */
/* number of basic code points, and out is the number of characters */
/* that have been output. */
if (b > 0) output[out++] = delimiter;
/* Main encoding loop: */
while (h < input_length) {
/* All non-basic code points < n have been */
/* handled already. Find the next larger one: */
for (m = maxint, j = 0; j < input_length; ++j) {
/* if (basic(input[j])) continue; */
/* (not needed for Punycode) */
if (input[j] >= n && input[j] < m) m = input[j];
}
/* Increase delta enough to advance the decoder's */
/* <n,i> state to <m,0>, but guard against overflow: */
if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
delta += (m - n) * (h + 1);
n = m;
for (j = 0; j < input_length; ++j) {
/* Punycode does not need to check whether input[j] is basic: */
if (input[j] < n /* || basic(input[j]) */ ) {
if (++delta == 0) return punycode_overflow;
}
if (input[j] == n) {
/* Represent delta as a generalized variable-length integer: */
for (q = delta, k = base; ; k += base) {
if (out >= max_out) return punycode_big_output;
t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */
k >= bias + tmax ? tmax : k - bias;
if (q < t) break;
output[out++] = encode_digit(t + (q - t) % (base - t), 0);
q = (q - t) / (base - t);
}
output[out++] = encode_digit(q, case_flags && case_flags[j]);
bias = adapt(delta, h + 1, h == b);
delta = 0;
++h;
}
}
++delta, ++n;
}
*output_length = out;
return punycode_success;
}
/*** Main decode function ***/
enum punycode_status punycode_decode(
punycode_uint input_length,
const char input[],
punycode_uint *output_length,
punycode_uint output[],
unsigned char case_flags[] )
{
punycode_uint n, out, i, max_out, bias,
b, j, in, oldi, w, k, digit, t;
/* Initialize the state: */
n = initial_n;
out = i = 0;
max_out = *output_length;
bias = initial_bias;
/* Handle the basic code points: Let b be the number of input code */
/* points before the last delimiter, or 0 if there is none, then */
/* copy the first b code points to the output. */
for (b = j = 0; j < input_length; ++j) if (delim(input[j])) b = j;
if (b > max_out) return punycode_big_output;
for (j = 0; j < b; ++j) {
if (case_flags) case_flags[out] = flagged(input[j]);
if (!basic(input[j])) return punycode_bad_input;
output[out++] = input[j];
}
/* Main decoding loop: Start just after the last delimiter if any */
/* basic code points were copied; start at the beginning otherwise. */
for (in = b > 0 ? b + 1 : 0; in < input_length; ++out) {
/* in is the index of the next character to be consumed, and */
/* out is the number of code points in the output array. */
/* Decode a generalized variable-length integer into delta, */
/* which gets added to i. The overflow checking is easier */
/* if we increase i as we go, then subtract off its starting */
/* value at the end to obtain delta. */
for (oldi = i, w = 1, k = base; ; k += base) {
if (in >= input_length) return punycode_bad_input;
digit = decode_digit(input[in++]);
if (digit >= base) return punycode_bad_input;
if (digit > (maxint - i) / w) return punycode_overflow;
i += digit * w;
t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */
k >= bias + tmax ? tmax : k - bias;
if (digit < t) break;
if (w > maxint / (base - t)) return punycode_overflow;
w *= (base - t);
}
bias = adapt(i - oldi, out + 1, oldi == 0);
/* i was supposed to wrap around from out+1 to 0, */
/* incrementing n each time, so we'll fix that now: */
if (i / (out + 1) > maxint - n) return punycode_overflow;
n += i / (out + 1);
i %= (out + 1);
/* Insert n at position i of the output: */
/* not needed for Punycode: */
/* if (decode_digit(n) <= base) return punycode_invalid_input; */
if (out >= max_out) return punycode_big_output;
if (case_flags) {
memmove(case_flags + i + 1, case_flags + i, out - i);
/* Case of last character determines uppercase flag: */
case_flags[i] = flagged(input[in - 1]);
}
memmove(output + i + 1, output + i, (out - i) * sizeof *output);
output[i++] = n;
}
*output_length = out;
return punycode_success;
}
/******************************************************************/
/* Wrapper for testing (would normally go in a separate .c file): */
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
/* For testing, we'll just set some compile-time limits rather than */
/* use malloc(), and set a compile-time option rather than using a */
/* command-line option. */
enum {
unicode_max_length = 256,
ace_max_length = 256
};
static void usage(char **argv)
{
fprintf(stderr,
"\n"
"%s -e reads code points and writes a Punycode string.\n"
"%s -d reads a Punycode string and writes code points.\n"
"\n"
"Input and output are plain text in the native character set.\n"
"Code points are in the form u+hex separated by whitespace.\n"
"Although the specification allows Punycode strings to contain\n"
"any characters from the ASCII repertoire, this test code\n"
"supports only the printable characters, and needs the Punycode\n"
"string to be followed by a newline.\n"
"The case of the u in u+hex is the force-to-uppercase flag.\n"
, argv[0], argv[0]);
exit(EXIT_FAILURE);
}
static void fail(const char *msg)
{
fputs(msg,stderr);
exit(EXIT_FAILURE);
}
static const char too_big[] =
"input or output is too large, recompile with larger limits\n";
static const char invalid_input[] = "invalid input\n";
static const char overflow[] = "arithmetic overflow\n";
static const char io_error[] = "I/O error\n";
/* The following string is used to convert printable */
/* characters between ASCII and the native charset: */
static const char print_ascii[] =
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
" !\"#$%&'()*+,-./"
"0123456789:;<=>?"
"@ABCDEFGHIJKLMNO"
"PQRSTUVWXYZ[\\]^_"
"`abcdefghijklmno"
"pqrstuvwxyz{|}~\n";
int main(int argc, char **argv)
{
enum punycode_status status;
int r;
unsigned int input_length, output_length, j;
unsigned char case_flags[unicode_max_length];
if (argc != 2) usage(argv);
if (argv[1][0] != '-') usage(argv);
if (argv[1][2] != 0) usage(argv);
if (argv[1][1] == 'e') {
punycode_uint input[unicode_max_length];
unsigned long codept;
char output[ace_max_length+1], uplus[3];
int c;
/* Read the input code points: */
input_length = 0;
for (;;) {
r = scanf("%2s%lx", uplus, &codept);
if (ferror(stdin)) fail(io_error);
if (r == EOF || r == 0) break;
if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
fail(invalid_input);
}
if (input_length == unicode_max_length) fail(too_big);
if (uplus[0] == 'u') case_flags[input_length] = 0;
else if (uplus[0] == 'U') case_flags[input_length] = 1;
else fail(invalid_input);
input[input_length++] = codept;
}
/* Encode: */
output_length = ace_max_length;
status = punycode_encode(input_length, input, case_flags,
&output_length, output);
if (status == punycode_bad_input) fail(invalid_input);
if (status == punycode_big_output) fail(too_big);
if (status == punycode_overflow) fail(overflow);
assert(status == punycode_success);
/* Convert to native charset and output: */
for (j = 0; j < output_length; ++j) {
c = output[j];
assert(c >= 0 && c <= 127);
if (print_ascii[c] == 0) fail(invalid_input);
output[j] = print_ascii[c];
}
output[j] = 0;
r = puts(output);
if (r == EOF) fail(io_error);
return EXIT_SUCCESS;
}
if (argv[1][1] == 'd') {
char input[ace_max_length+2], *p, *pp;
punycode_uint output[unicode_max_length];
/* Read the Punycode input string and convert to ASCII: */
fgets(input, ace_max_length+2, stdin);
if (ferror(stdin)) fail(io_error);
if (feof(stdin)) fail(invalid_input);
input_length = strlen(input) - 1;
if (input[input_length] != '\n') fail(too_big);
input[input_length] = 0;
for (p = input; *p != 0; ++p) {
pp = strchr(print_ascii, *p);
if (pp == 0) fail(invalid_input);
*p = pp - print_ascii;
}
/* Decode: */
output_length = unicode_max_length;
status = punycode_decode(input_length, input, &output_length,
output, case_flags);
if (status == punycode_bad_input) fail(invalid_input);
if (status == punycode_big_output) fail(too_big);
if (status == punycode_overflow) fail(overflow);
assert(status == punycode_success);
/* Output the result: */
for (j = 0; j < output_length; ++j) {
r = printf("%s+%04lX\n",
case_flags[j] ? "U" : "u",
(unsigned long) output[j] );
if (r < 0) fail(io_error);
}
return EXIT_SUCCESS;
}
usage(argv);
return EXIT_SUCCESS; /* not reached, but quiets compiler warning */
}
Author's Address
著者のアドレス
Adam M. Costello
University of California, Berkeley
http://www.nicemice.net/amc/
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。