编辑“︁UTF-7”︁（章节）

== 手動編碼與解碼UTF-7的演算法 ==
=== 編碼 ===
首先必須先決定哪些字元呈現為ASCII格式，哪些字元呈現在Unicode區塊。簡單的編碼器可以假設所有的字元皆可以很安全的被直接編碼。然而要將原本屬於Unicode區塊的字元視為ASCII來加以編碼的代價是需要額外的2⅔字元。

Unicode序列一旦被認定後，其必須以下面的程序來加以編碼，併以適當的符號加以標注：

我們將使用£† (0x00A3) (0x2020)字元序列來作為以下的範例。

#將字元的Unicode數值 (UTF-16)以二進位呈現：<br /><code>0x00A3 → 0000 0000 1010 0011</code><br /><code>0x2020 → 0010 0000 0010 0000</code>
#將二進位序列合併<br /><code> 0000 0000 1010 0011 及 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000</code>
#重新將二進位序列編組，以六位數為一組，由左開始：<br /><code>0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00</code>
#如果最後一組小於六位數，則不足的位數以0補足尾數：<br /><code>0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 000000</code>
#將每一組六位數的數值以對應的Base64碼取代：<br /><code>000000 001010 001100 100000 001000 000000 → AKMgIA</code>

=== 解碼 ===
首先訊息必須被拆分到純文字與Unicode區塊，緊接著Unicode區塊必須以下面的程序來進行解譯（使用上面提到的範例）：

# 將每一個Base64碼以二進位序列來描述，如下：<br /><tt>AKMgIA → 000000 001010 001100 100000 001000 000000</tt>
# 重新將二進位編組，以使其16位數一組，從左開始：<br /><tt>000000 001010 001100 → 0000000010100011 0010000000100000 0000</tt>
# 若有其中一組無法完全編成16位數一組，則先排除它：<br /><tt>0000000010100011 0010000000100000</tt>
# 每一個16位元的一組二進位碼為Unicode（UTF-16）的數字字元並且可以被改寫為如下：<br /><tt>0000 0000 1010 0011 ≡ 0x00A3 ≡ 163<sub>10</sub></tt>

=== 安全性 ===
UTF-7由於允許將相同來源的字串從base64的模式被平移，而顯得安全性薄弱。現今的郵件與傳輸方式由於都已支援UTF-8，UTF-7則已走入歷史而很少再被使用。即便如此，現今的應用軟體仍應更加考量支援更安全的編碼方式。

然而，除了郵件傳輸之外，仍有不少傳輸是採用UTF-7編碼來進行傳輸。近期較著名的安全漏洞發生於[[Google]]的搜尋漏洞<ref>http://www.kb.cert.org/vuls/id/989144 {{Wayback|url=http://www.kb.cert.org/vuls/id/989144 |date=20211207201747 }}, Vulnerability Note VU#989144, Google Mini and Google Search Appliance vulnerable to cross-site scripting</ref>，該漏洞肇因於不當的使用UTF-7編碼於網址資訊上，遠端的攻擊將可讀取或修改網頁內容。

=== 尚未被完整開發的UTF-6和UTF-5 ===
有些可應用於電信電報領域的UTF-6和UTF-5提案已經被提出<ref>Seng, James, [http://www.watersprings.org/pub/id/draft-jseng-utf5-01.txt UTF-5, a transformation format of Unicode and ISO 10646] {{Wayback|url=http://www.watersprings.org/pub/id/draft-jseng-utf5-01.txt |date=20160303182813 }}, 28 Jan 2000, retrieved 23 Aug 2007</ref><ref>{{cite web
|url = http://tools.ietf.org/html/draft-ietf-idn-utf6-00
|title = UTF-6 - Yet Another ASCII-Compatible Encoding for IDN
|accessdate = 2007-08-28
|last = Welter
|first = Mark
|coauthors = Brian W. Spolarich, WALID, Inc.
|date = 2000-11-16
|work = Internet Engineering Task Force (IETF) INTERNET-DRAFT
|publisher = The Internet Society
|archive-date = 2021-04-28
|archive-url = https://web.archive.org/web/20210428214158/https://tools.ietf.org/html/draft-ietf-idn-utf6-00
|dead-url = no
}}</ref>，然而，截至2006年止，這些提案尚未被正式的制定出來。

這些提案與[[Punycode]]並無相關。