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

简介

范例

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

安全性

尚未被完整开发的 UTF-6 和 UTF-5

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 的演算法

编码

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

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

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

将字元的 Unicode 数值 (UTF-16) 以二进位呈现：

0x00A3 → 0000 0000 1010 0011

0x2020 → 0010 0000 0010 0000

将二进位序列合并

0000 0000 1010 0011 and 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000

重新将二进位序列编组，以六位数为一组，由左开始：

0000 0000 1010 0011 → 000000 001010 001100 100000 001000 00

如果最后一组小于六位数，则不足的位数以 0 补足尾数：

0000 0000 1010 0011 → 000000 001010 001100 100000 001000 000000

将每一组六位数的数值以对应的 Base64 码取代：

000000 001010 001100 100000 001000 000000 → AKMgIA

解码

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

将每一个 Base64 码以二进位序列来描述，如下：

AKMgIA → 000000 001010 001100 100000 001000 000000

重新将二进位编组，以使其 16 位数一组，从左开始：

000000 001010 001100 → 0000000010100011 0010000000100000 0000

若有其中一组无法完全编成 16 位数一组，则先排除它：

0000000010100011 0010000000100000

每一个 16 位元的一组二进位码为 Unicode （UTF-16）的数字字元并且可以被改写为如下：

0000 0000 1010 0011 ≡ 0x00A3 ≡ 16310

安全性

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

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

尚未被完整开发的 UTF-6 和 UTF-5

有些可应用于电信电报领域的 UTF-6 和 UTF-5 提案已经被提出 [2] [3] ，然而，截至 2006 年止，这些提案尚未被正式的制定出来。

这些提案与 Punycode 并无相关。