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...............................................2 1.1 Features..............................................2 1.2 Interaction of protocol parts.........................3 2. Terminology................................................3 3. Bootstring description.....................................4 3.1 Basic code point segregation..........................4 3.2 Insertion unsort coding...............................4 3.3 Generalized variable-length integers..................5 3.4 Bias adaptation.......................................7 4. Bootstring parameters......................................8 5. Parameter values for Punycode..............................8 6. Bootstring algorithms......................................9 Costello Standards Track [Page 1] RFC 3492 IDNA Punycode March 2003 6.1 Bias adaptation function.............................10 6.2 Decoding procedure...................................11 6.3 Encoding procedure...................................12 6.4 Overflow handling....................................13 7. Punycode examples.........................................14 7.1 Sample strings.......................................14 7.2 Decoding traces......................................17 7.3 Encoding traces......................................19 8. Security Considerations...................................20 9. References................................................21 9.1 Normative References.................................21 9.2 Informative References...............................21 A. Mixed-case annotation.....................................22 B. Disclaimer and license....................................22 C. Punycode sample implementation............................23 Author's Address.............................................34 Full Copyright Statement.....................................35 1. Introduction [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]. 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 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. Costello Standards Track [Page 2] RFC 3492 IDNA Punycode March 2003 * 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. * 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". 1.2 Interaction of protocol parts 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. 2. Terminology 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]. 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. 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. The break statement jumps out of the innermost loop (as in C). Costello Standards Track [Page 3] RFC 3492 IDNA Punycode March 2003 An overflow is an attempt to compute a value that exceeds the maximum value of an integer variable. 3. Bootstring description 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 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 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. Costello Standards Track [Page 4] RFC 3492 IDNA Punycode March 2003 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 , the next state is if i is less than the length of the extended string, or 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. 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 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 Costello Standards Track [Page 5] RFC 3492 IDNA Punycode March 2003 when unique encodings are needed. Second, the integer is not self- delimiting, so if multiple integers are concatenated the boundaries between them are lost. 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 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. Encoding this representation is similar to encoding a conventional integer: If N ((base - tmin) * tmax) div 2 do let delta = delta div (base - tmin) 4. The bias is set: 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 Costello Standards Track [Page 7] RFC 3492 IDNA Punycode March 2003 (balancing the hope of the expected-last digit being unnecessary against the danger of it being insufficient). 4. Bootstring parameters 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: 0 = 1 damp >= 2 initial_bias mod base ((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. Costello Standards Track [Page 10] RFC 3492 IDNA Punycode March 2003 6.2 Decoding procedure 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 + tmax, or k - bias otherwise if digit 0 {if the input contains a 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 = bias + tmax, or k - bias otherwise if q 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. 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. 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. Costello Standards Track [Page 13] RFC 3492 IDNA Punycode March 2003 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. 7. Punycode examples 7.1 Sample strings 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 ?" (courtesy of Michael Kaplan's "provincial" page [PROVINCIAL]). Word breaks and punctuation have been removed, as is often done in domain names. (A) Arabic (Egyptian): 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): u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587 Punycode: ihqwcrb4cv8a8dqg056pqjye (C) Chinese (traditional): u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587 Punycode: ihqwctvzc91f659drss3x8bo0yb (D) Czech: Proprostnemluvesky 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 Costello Standards Track [Page 14] RFC 3492 IDNA Punycode March 2003 (E) Hebrew: 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): 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): 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): 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): 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: PorqunopuedensimplementehablarenEspaol 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: Tisaohkhngthch\ nitingVit 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 Costello Standards Track [Page 15] RFC 3492 IDNA Punycode March 2003 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) 3B u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F Punycode: 3B-ww4c5e180e575a65lsy2b (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- 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) 2 u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032 Punycode: 2-u9tlzr9756bt3uc0v (P) MajiKoi5 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) de u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0 Punycode: de-jg4avhby1noc0d (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 $1.00 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 Costello Standards Track [Page 24] RFC 3492 IDNA Punycode March 2003 /*** 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) > 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: */ Costello Standards Track [Page 26] RFC 3492 IDNA Punycode March 2003 for (j = 0; j 0) output[out++] = delimiter; /* Main encoding loop: */ while (h = n && input[j] state to , 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 = max_out) return punycode_big_output; Costello Standards Track [Page 27] RFC 3492 IDNA Punycode March 2003 t = k = bias + tmax ? tmax : k - bias; if (q max_out) return punycode_big_output; for (j = 0; j 0 ? b + 1 : 0; 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 + tmax ? tmax : k - bias; if (digit 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) = max_out) return punycode_big_output; if (case_flags) { memmove(case_flags + i + 1, case_flags + i, out - i); Costello Standards Track [Page 29] RFC 3492 IDNA Punycode March 2003 /* 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 #include #include #include /* 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) Costello Standards Track [Page 30] RFC 3492 IDNA Punycode March 2003 { 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); Costello Standards Track [Page 31] RFC 3492 IDNA Punycode March 2003 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 = 0 && c