大家好，我是Tony Bai。

作為 Gopher，我們每天都在和 rune 打交道。在 Go 語言中，它通常被解釋為“一個 Unicode 碼點”，官方文檔也說引入這個術語是為了“簡潔”。但你是否曾好奇，這個略帶神秘色彩的詞匯，究竟源自何方？僅僅是為了簡潔嗎？

最近，Connor Taffe的一篇精彩博文[1]以及 Go語言之父 Rob Pike 的親自確認[2]，為我們揭開了一段跨越三十余年，從 Plan 9 操作系統到 UTF-8 編碼誕生，再到 Go 語言的歷史傳奇。今天，就讓我們一起，深入 rune 背后的故事。

一句“簡潔”，一段 Plan 9 往事

Connor文章中引用的Adam Pritchard的關于限制字符串長度[3]的文章中提到：“請注意，在 Go 中，Unicode 碼點通常被稱為‘rune’。（Go 似乎是為了簡潔而引入了這個術語。）” 而 Go 官方博客《Strings, bytes, runes, and characters in Go[4]》也說：“‘Code point’有點拗口，所以 Go 引入了一個更短的術語：rune?！?/p>

圖片

Rob Pike 在 Bluesky 上的發言截圖

然而，真相遠不止于此。Rob Pike 最近在 Bluesky 上澄清(如上圖)，rune 這個詞實際上是 Ken Thompson 在一次為 Plan 9 尋找一個不同于 char（用于字節）的類型名稱的頭腦風暴中“得意地”提出的，Rob Pike 當即表示贊同。更關鍵的是，Rob Pike 隨后確認，這個命名發生在 Plan 9 為 UTF 和 ISO 10646 尋找類型名稱的時期，具體是1991 年 12 月 8 日的晚上！遠早于 Unicode 和 UTF-8 的廣泛應用，也比 Go 語言的誕生早了數十年。

是的，你沒看錯，rune 的故事，始于 Plan 9，那個由貝爾實驗室傳奇人物們（包括 Rob Pike, Ken Thompson 等）創造的操作系統。Go 語言深受 Plan 9 的影響，從鏈接器架構、并發原語 channel、標識符大小寫的可見性規則，到對簡潔性的極致追求，都帶著濃厚的 Plan 9 印記。rune 便是這血脈傳承中的一環。

餐巾紙上的革命：UTF-8 的誕生傳奇

要理解 rune 在 Plan 9 中的意義，就不得不提 UTF-8 的誕生。Connor 的文章中引用了一封 Rob Pike 在 2003 年的郵件，詳細披露了這段鮮為人知的歷史，糾正了“IBM 設計 UTF-8，Plan 9 實現它”的說法。

故事發生在 1992 年 9 月左右的一個晚上，新澤西一家小餐館的餐巾紙上：

• 緣起： Plan 9 當時使用 ISO 10646 最初的 UTF（一種16位字符編碼）來支持寬字符，但團隊對它非常不滿。Rob Pike 形容道：“UTF 太糟糕了。它有模192的算術，而且在沒有除法硬件的老 SPARC 機器上幾乎不可能高效實現。像【/*】這樣的字符串可能出現在西里爾字符中間，導致你的俄文文本變成一個 C 語言注釋。還有更多問題。它作為一種編碼根本不實用?！?/li>
• 契機： 一天下午，X/Open 委員會的一些人（據 Rob Pike 回憶可能來自 IBM 奧斯?。┐騺黼娫挘Ｍ?Ken 和 Rob 審查他們的 FSS-UTF (File System Safe UTF) 設計。Ken 和 Rob 意識到這是一個用他們的經驗設計一個真正優秀的標準，并讓 X/Open 將其推廣出去的機會。
• 餐巾紙上的靈感： 他們接受了挑戰，條件是必須快速完成。于是，在那個決定性的晚餐上，Ken Thompson 在餐巾紙上構想出了 UTF-8 的位打包方案。
• 閃電般的實現： 晚餐后回到實驗室，他們便向 X/Open 解釋了新方案，并承諾在周一前（據信是 X/Open 的重要投票日）拿出一個完整的運行系統。當晚，Ken 寫了打包和解包代碼，Rob Pike 則開始修改 C 庫和圖形庫。到周五的某個時候，Plan 9 已經完全運行在后來被稱為 UTF-8 的編碼上了。

Rob Pike 在郵件中強調，他們之所以要“另起爐灶”，是因為 FSS-UTF 缺少他們認為至關重要的特性之一：支持定位到文件或流的中間，并讀取有效字符，或處理損壞的字符。 Ken Thompson 設計的 UTF-8 完美地解決了這個問題。

對比 Ken Thompson 當時提出的 UTF-8 方案(如下圖)和 FSS-UTF，我們可以看到 UTF-8 的精妙之處：后續字節以 10 開頭，與首字節的 110、1110 等模式區分開來，確保了自同步性和對 ASCII 的兼容性。

圖片

Rune 的首次亮相與演變

那么，Rune 這個詞是什么時候正式與這種新的字符表示方式聯系起來的呢？Rob Pike 在其關于 Plan 9 UTF-8 實現的論文《Hello World》中寫道：

“在語義層面上，ANSI C 允許（但并未限制）寬字符的概念，并且允許此類字符串和字符常量。我們選擇 unsigned short 作為寬字符類型。在庫中，Rune 一詞由 typedef 定義為等同于 unsigned short，并用于表示 一個Unicode 字符?！?/p>

這似乎是 Rune 作為一種特定類型名稱，用于指代 Unicode 字符（碼點）的最早文獻記錄。最初在 Plan 9 C 中，Rune 是一個 16 位無符號短整型，足以表示當時的 Unicode 基本多文種平面（BMP）。

而到了 Go 語言，rune 被定義為 int32 的別名。這是因為自 1992 年以來，Unicode 已經擴展，需要更大的空間來表示所有碼點（UCS-4 定義了 31 位碼空間）。Go 語言標準庫中的 unicode/utf8 包也定義了 UTFMax = 4，表明一個 rune 最多可以用 4 個字節的 UTF-8 編碼表示。有趣的是，在 Russ Cox 移植的 plan9 port 中，Rune 類型在 2009 年末也被修改為了 unsigned int，同樣是為了支持更廣的碼點范圍。

Ken Thompson 在最初的郵件中提到：“4、5 和 6 字節序列只是出于政治原因才存在的。我更愿意刪除它們。” 這也印證了早期設計者對編碼效率和實用性的極致追求。

Rune 的足跡：從 Plan 9 到更廣闊的世界

Rune 這個術語，并沒有止步于 Plan 9。通過 Paul Borman 的貢獻，Plan 9 的 rune 功能被整合進了 4.4 BSD。從此，rune 開始在更廣闊的 Unix 世界留下足跡：

• FreeBSD 繼承了 4.4 BSD 的 rune 函數，盡管后來推薦使用 ISO C99 的寬字符工具。
• Apple 的 Darwin 內核，作為 BSD 的衍生，也包含了 rune_t 類型。
• C 標準庫實現如 newlib 也包含了源自 BSD 4.4 的 rune 功能。
• Android 通過 plan9port 移植了 Plan 9 的 libutf，其中自然也包含了 rune。
• 甚至，微軟的 .NET 在引入 System.Text.Rune 類型時，其靈感也明確來自 Go 語言，這在其 GitHub issue 中由 Miguel de Icaza 提及[5]。

可見，rune 這個由 Ken Thompson 靈光一閃提出的詞匯，承載著一段從貝爾實驗室 Plan 9 開始，經由 BSD 社區，最終深刻影響了包括 Go 在內的現代編程語言和操作系統的字符處理歷史。

小結：rune 不只是簡潔

通過Rob Pike的親自確認，我們應該知道，當我們今天再看到 Go 語言中的 rune 時，它不僅僅是為了“簡潔”而對“Unicode code point”的替換。它是一個承載著厚重歷史的符號，是 Go 語言設計者們深厚技術底蘊和創新精神的體現，是 Plan 9 簡潔哲學與 UTF-8 實用主義的結晶。

理解 rune 的來龍去脈，有助于我們更深刻地體會 Go 語言在文本處理、字符串操作以及 Unicode 支持方面的設計考量，也讓我們對這門語言背后的巨匠們多一份敬意。下一次，當你在 Go 代碼中寫下 rune 時，或許會想起那個在新澤西餐館餐巾紙上誕生的傳奇，以及那段跨越三十余年的 Plan 9 往事。

聊一聊：

• 在了解了 rune 的歷史后，你對 Go 語言的設計是否有新的認識？
• UTF-8 誕生的故事中，有哪些細節讓你印象深刻？
• 你認為這種對歷史淵源的挖掘，對我們理解和使用一門編程語言有何幫助？

歡迎在評論區分享你的看法！如果你覺得這篇文章有趣且有價值，也請轉發給你身邊的 Gopher 朋友們，讓更多人了解 rune 背后的故事。

參考資料

[1] Connor Taffe的一篇精彩博文: https://connor.zip/posts/2025-05-03-rune

[2] Go語言之父 Rob Pike 的親自確認: https://bsky.app/profile/robpike.io/post/3lokt3qzvos2h

[3] 限制字符串長度: https://adam-p.ca/blog/2025/04/string-length/

[4] Strings, bytes, runes, and characters in Go: https://go.dev/blog/strings

[5] 這在其 GitHub issue 中由 Miguel de Icaza 提及: https://github.com/dotnet/runtime/issues/23578

[6] Rune by Connor Taffe: https://connor.zip/posts/2025-05-03-rune