字符集名称：UTF-7

UTF-7（7-位元 Unicode 转换格式，Unicode Transformation Format，简写UTF）是一种可变长度字符编码方式，用以将 Unicode 字符以 ASCII 编码的字符串来呈现，可以应用在电子邮件传输之类的应用。

SMTP 为基本的电子邮件传输标准之一，其指明了传输格式为 US-ASCII ，并且不允许超过 ASCII 所定义的字符范围以外的位元值，也就是说八位元的字串将无法正常的被传输。 MIME （RFC 2045 ~ 2049）扩展了网络邮件以支援不同的媒体类型以及字符集，包含 UTF-8 与 UTF-16 的字符集皆可被指定使用。但由于 MIME 并未明确将 Unicode 定义为可支援的字符集，并且也没有说明其应如何编码，这使得既有的 SMTP 传输架构下仍旧无法保证可正确的处理 8 位元资料。Base64 编码也有其问题，例如甚至连纯英文的 US-ASCII 字符也可能会变成不可辨认；至于像是 UTF-8 与 quoted-printable 的编码结合，则需要 6 ～ 9 个位元来为非 ASCII 的字符（Unicode 的 基本多文种平面中定义的字符）进行编码，至于在基本多文种平面（BMP）以外的字原则需要多达 12 位元的长度才能完成编码，这显得相当没有效率。

简介

UTF-7 首次被提出是在一个实验性的通讯协定里（RFC 1642，A Mail-Safe Transformation Format of Unicode），这份 RFC（Request for Comments） 提案后来因 RFC 2152 的提出而被取代（RFC 2152 本身为新闻型（informational）的文案）。在 RFC 2152 当中明确的指出该份 RFC 本身不为因特网的标准做出任何明确的定义（明列于文案前头的 Status of this Memo ）。尽管这份 RFC 2152 在 IANA （Internet Assigned Numbers Authority） 的字符集列表里被引述为 UTF-7，然而 UTF-7 本身并非 Unicode 的标准之一，即使在目前最新的 Unicode 5.0 里也仅列出 UTF-8 、 UTF-16 和 UTF-32 。

如同引言所提到的，由于在过去 SMTP 的传输仅能接受 7 位元的字符，而当时 Unicode 并无法直接满足既有的 SMTP 传输限制，在这样地背景下 UTF-7 被提出。严格来说 UTF-7 不能算是 Unicode 所定义的字符集之一，较精确的来说， UTF-7 是提供了一种将 Unicode 转换为 7 位元 US-ASCII 字符的转换方式。

有些字符本身可以直接以单一的 ASCII 字符来呈现。第一个群组被称作“direct characters”，其中包含了 62 个数字与英文字母，以及包含了九个符号字符：' ( ) , - . / : ?。这些“direct characters”被认为可以很安全的直接在文件里呈现。另一个主要的群组称作“optional direct characters”，其中包含了所有可被打印的字符，这些字符在 U+0020 ～ U+007E 之间，除了~ \ +和空白字符以外。这些“optional direct characters”的使用虽可减少空间的使用也可增加人的可阅读性，但却会因为一些不良设计的邮件闸道而会产生一些错误，导致必须使用额外的跳脱字符。

空白字符、Tab字符、以及换行字符一般虽也可直接是为单一的 ASCII 字符来使用，然而，若是邮件中有使用了编码过的字串，则必须特别注意这些字符有无被使用在其他地方。

其他的字符则必须被编码成 UTF-16 然后转换为修改的 Base64。这些区块的开头会以 + 符号来标示，结尾则以任何不在 Base64 里定义的字符来标示。

范例

• "Hello, World!" 会被编码为 "Hello, World!"
• "1 + 1 = 2" 会被编码为 "1 +- 1 = 2"
• "£1" 会被编码为 "+AKM-1". 第一个字符 £ （英镑的符号）的 Unicode 码为 U+00A3 (在 UTF-16 即为 00A3₁₆），接着转换至修改的 Base64格式，如同下表。表中可见有两个位元多了出来，被以 0 填补上。

16进制码	0				0				A				3
2进制码	0	0	0	0	0	0	0	0	1	0	1	0	0	0	1	1	0	0
索引	0						10						12
Base64 编码	A						K						M

手动编码与解码 UTF-7 的算法

A.编码

首先必须先决定哪些字符呈现为 ASCII 格式，哪些字符呈现在 Unicode 区块。简单的编码器可以假设所有的字符皆可以很安全的被直接编码。然而要将原本属于 Unicode 区块的字符视为 ASCII 来加以编码的代价是需要额外的2⅔字符。

Unicode 序列一旦被认定后，其必须以下面的程序来加以编码，并以适当的符号加以标注：

我们将使用 £† (0x00A3) (0x2020) 字符序列来作为以下的范例。

1. 将字符的 Unicode 数值 (UTF-16) 以二进制呈现：
   0x00A3 → 0000 0000 1010 0011
0x2020 → 0010 0000 0010 0000
2. 将二进制序列合并
   0000 0000 1010 0011 and 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
3. 重新將二進位序列編組，以六位數為一組，由左開始：
0000 0000 1010 0011 → 000000 001010 001100 100000 001000 00
4. 如果最后一组小于六位数，则不足的位数以 0 补足尾数：
   0000 0000 1010 0011 → 000000 001010 001100 100000 001000 000000
5. 将每一组六位数的数值以对应的 Base64 码取代：
   000000 001010 001100 100000 001000 000000 → AKMgIA

B.解码

首先讯息必须被拆分到纯文字与 Unicode 区块，紧接着 Unicode 区块必须以下面的程序来进行解译（使用上面提到的范例）：

1. 将每一个 Base64 码以二进制序列来描述，如下：
   AKMgIA → 000000 001010 001100 100000 001000 000000
2. 重新将二进制编组，以使其 16 位数一组，从左开始：
   000000 001010 001100 → 0000000010100011 0010000000100000 0000
3. 若有其中一组无法完全编成 16 位数一组，则先排除它：
   0000000010100011 0010000000100000
4. 每一个 16 位元的一组二进制码为 Unicode （UTF-16）的数字字符并且可以被改写为如下：
   0000 0000 1010 0011 ≡ 0x00A3 ≡ 163₁₀

C.安全性

UTF-7 由于允许将相同来源的字串从 base64 的模式被平移，而显得安全性薄弱。现今的邮件与传输方式由于都已支援 UTF-8，UTF-7 则已走入历史而很少再被使用。即便如此，现今的应用软件仍应更加考量支援更安全的编码方式。

然而，除了邮件传输之外，仍有不少传输是采用 UTF-7 编码来进行传输。近期较著名的安全漏洞发生于 Google 的搜寻漏洞^[1]，该漏洞肇因于不当的使用 UTF-7 编码于网址资讯上，远端的攻击将可读取或修改网页内容。