瀏覽器欠了阿拉伯文排版三十年的債
lr0.org · 2026-06-10
2026 年 6 月 10 日，一篇以互動方式呈現的深度長文在技術社群廣泛流傳，作者花費逾萬字梳理了阿拉伯文排版從西元 940 年延伸至今日瀏覽器的歷史欠債。文章指出，當前網頁對阿拉伯語系使用者的排版缺陷，並非技術不可行，而是經濟誘因長期缺失所導致的系統性忽視。
背景
阿拉伯文書法系統由阿拔斯王朝宰相伊本·穆格拉（Ibn Muqla）在西元 940 年前後加以系統化，其比例規則歷經千年仍是字型設計的基礎。阿拉伯字母依詞中位置（詞首、詞中、詞末、獨立）改變字形，這要求底層文字塑形引擎（shaping engine）在渲染前完成字形替換，而非直接輸出儲存的 Unicode 碼位。文章一語道破：「你儲存的文字是輸入，不是輸出。」
印刷技術的引入對阿拉伯文造成深遠傷害。1514 年法諾（Fano）出版的第一本阿拉伯語印刷書籍使用了分離字母，背離了手稿傳統。1958 年為配合 Linotype 機器，「簡化阿拉伯體（Simplified Arabic）」將每個字母壓縮為兩種字形，犧牲排版忠實度以換取生產速度。這些妥協直接影響了後來數位字型的設計方向，埋下了現代網頁渲染缺陷的遠因。
現代解法的基礎建設其實已相當完整：HarfBuzz 塑形引擎由伊朗裔加拿大工程師 Behdad Esfahbod 主導開發，後由埃及工程師 Khaled Hosny 持續維護，兩人均為義務投入。Hosny 另以 1924 年開羅版《古蘭經》字型為原型製作了 Amiri 字型，並支援弧形延筆（curvilinear kashida）。這套基礎設施由志工撐起，商業投入幾乎付之闕如。
核心改動
文章揭示了今日瀏覽器在處理阿拉伯文時仍存在的四大技術問題。首先是齊行（justification）機制的缺失：阿拉伯傳統排版以延長連筆 kashida（taṭwīl）在字內撐開行寬，而非擴大詞間距；CSS 規範曾收錄 text-justify: kashida 屬性，但隨後被移除，CSSWG 相關 issue 自 2015 年起懸而未決。
第二個問題是 Unicode 雙向演算法（UAX #9） 與數字系統的交互作用。阿拉伯文中同時存在西式數字、阿拉伯－印度數字（Arabic-Indic）與擴充阿拉伯－印度數字三套系統，雙向演算法在未明確標記方向性時，可能將「10-20」渲染成「20-10」。第三個問題是 Unicode Presentation Forms 區塊（U+FB50–U+FEFF）保留了源自 8-bit 編碼的廢棄字形，混用時會導致搜尋比對失敗，使相同意義的文字在搜尋時無法匹配。
第四個問題是 CSS overflow: hidden 搭配緊湊行高時，會截斷阿拉伯文的母音符號（diacritics）疊加層，在宗教文本閱讀情境下尤其關鍵。OpenType jstf（justification）字型表雖已定義對應規格，但幾乎無任何瀏覽器實作。Internet Explorer 5.5 曾短暫支援 kashida 齊行，此後二十餘年無任何瀏覽器跟進。
影響範圍
阿拉伯語是全球約 4 億人的母語，也是伊斯蘭宗教文本的書面語，潛在讀者超過 15 億。W3C 阿拉伯語版面需求（alreq）文件自 2015 年持續更新，列出了尚未被瀏覽器實作的排版規範項目。文章的核心論點是：「受影響的使用者群體中，作為整體並不包含任何廣告主」——這句話精準點出了技術欠債背後的政治經濟學。
這篇文章以互動示範讓非阿拉伯語讀者親眼感受文字渲染差異，也讓開發者社群意識到，「多語系支援」遠不只是切換字型那麼簡單。對前端工程師而言，在處理 RTL（right-to-left）文字時，dir 屬性、Unicode 雙向控制字元的正確使用，以及 text-justify 的侷限性，都是不得不面對的現實。
原始來源：lr0.org — An interactive introduction to rendering Arabic typography and its technical debt、Unicode UAX #9 — Unicode Bidirectional Algorithm
介面設計的兩條信號通道：帶內與帶外的取捨哲學
tomeraberba.ch · 2026-06-11
2026 年 6 月 11 日，工程師 Tomer Aberbach 發表了一篇探討 API 與介面設計的文章，借用電信領域「帶內信號（in-band signaling）」與「帶外信號（out-of-band signaling）」的概念，提出一套統一的分析框架，解釋為何有些介面天生讓人難以踩坑，有些卻在不知不覺中埋下 bug。文章以多種程式語言的具體案例佐證，覆蓋 Rust、Java、TypeScript、Go、Python、JavaScript 與 C#。
背景
電信系統中，帶內信號（in-band）指控制訊息與資料共用同一通道，例如電話線上的撥號音；帶外信號（out-of-band）則走獨立通道，不干擾主要資料流。Aberbach 將這對概念移植到軟體介面設計：帶內關注點（in-band concern）迫使使用者正視它，帶外關注點（out-of-band concern）則允許使用者在不察覺的情況下略過它。
文章的核心命題是：「介面所暴露的每個關注點，要麼強迫你面對它，要麼讓你在不知情的情況下忽略它。」這個框架跨越了函式庫 API、程式語言型別系統，乃至 UI 產品設計，統一了一個常被拆開討論的問題。
核心改動
文章以錯誤處理為核心示範。Rust 的 Result<T, E> 是帶內設計：呼叫者必須對 Ok 與 Err 兩個分支作出明確處理，無法跳過。相對地，JavaScript 的 fetch() 對 HTTP 4xx/5xx 不拋出例外，回傳的 Response 需要手動檢查 response.ok，若開發者未察覺此設計，靜默的錯誤處理缺漏就此埋下。這不是哪個設計更優秀，而是兩者對「錯誤」這個關注點選擇了不同的信號通道。
命名也是信號機制之一。Java 的 TreeSet 光憑名字就暗示了有序疊代，把「順序」這個關注點推入帶內；HashSet 則將其置於帶外。Go 與 Java 刻意隨機化雜湊表的疊代順序，正是用人工製造的不確定性，把「勿依賴未定義順序」這個關注點強制帶入注意。Guava 的 Files.asCharSource(File, Charset) 要求明確傳入字元集參數，杜絕了平台預設編碼造成的靜默錯誤。TypeScript 聯合型別亦可重構 API 形狀，令編譯器強制窮舉分支：
type KeyboardEvent =
| { kind: 'single-key'; key: string }
| { kind: 'modified-key'; primaryKey: string; modifier: string }產品 UI 同樣適用此框架。Google Chat 早期設計要求發訊時強制選擇「開新討論串」或「回覆至頻道頂層」，屬帶內設計，但用戶反映摩擦感過高；後續改為可選的討論串入口，轉為帶外，代價是出現更多意外的頂層回覆。這是注意力成本（in-band 的儀式感）與靜默 bug 風險（out-of-band 的遺漏）之間不可迴避的取捨。
影響範圍
Aberbach 歸納出六項設計原則，決定一個關注點應走哪條通道：
- 合理預設（Sensible defaults）：若預設值適用於絕大多數情境，帶外即可，例如
Array.indexOf預設從索引 0 開始搜尋。 - 安全預設（Safe defaults）：涉及資料完整性、隱私、安全的關注點，除非預設無損，否則必須帶內。
- 可行動性（Actionability）：只有在使用者能在當下有意義地回應時，才值得帶內強制；若回應方式只有「忽略」，帶內只是增加雜訊。
- 自我揭示（Self-revealing）：若關注點在實際使用時必然顯現，無需提前帶內強制。
- 受眾期望（Audience expectations）：Rust 程式設計師自我篩選接受高儀式感；Python 初學者則期待低門檻。Rust 互斥鎖的「中毒（poisoning）」機制對 Rust 社群是合理的帶內設計，但在 Python 中幾乎不可能被接受。
- 比例原則（Proportionality）：帶內關注點過多會造成注意力疲乏，讓所有強制提示都被機械性略過，反而比帶外更危險。
這套框架為 API 設計審查提供了一個共同語言：與其爭辯「要不要拋出例外」，不如先問「這個關注點應該走哪條通道，以及六項原則中哪一項決定了答案」。文章的最終目標是讓介面的使用者「落入成功之坑（Pit of Success）」——正確做法是最省力的路徑。
遊戲主機上的網頁瀏覽器：三十年興衰史
vale.rocks · 2026-06-11
2026 年 6 月 11 日，開發者 Declan Chidlow 在個人部落格發表了一篇逾八千字的考察文章，系統梳理了從 1995 年飛利浦 CD-i 到現代 PlayStation 5、Nintendo Switch 的主機瀏覽器演進史。文章指出，遊戲主機曾是數百萬家庭接入網際網路的唯一管道，如今這段歷史已幾乎被前端開發者所遺忘。
原本的問題
1990 年代中期，個人電腦售價對普通家庭仍是沉重負擔，而客廳裡的遊戲主機已是既有設備。讓主機兼具上網功能，等於以近乎零邊際成本為數百萬戶家庭開通網際網路入口。 1995 年，飛利浦 CD-i 透過 CD-Online 光碟提供受限的網路存取，但機器的 RAM 極為有限，光是使用瀏覽器就會覆寫其他記憶體內容（包含遊戲存檔），充分暴露了硬體妥協的代價。
電視螢幕的低解析度與隔行掃描特性，對文字渲染提出了與桌機截然不同的要求。1996 年 Sega Saturn 搭載的 PlanetWeb 瀏覽器刻意針對電視顯示器最佳化抗鋸齒字型，並加入縮放、書籤與家長監控功能，展示了主機瀏覽器需要一套有別於桌面 Web 的設計哲學。同年，Apple Bandai Pippin 在北美地區提供 @WORLD Browser，日本版則基於 Netscape，平台的商業失敗卻沒有抹去它在主機瀏覽器史上的一頁。
採用的方法
不同世代的主機採取了截然不同的技術路徑。Dreamcast（1998）同時存在三條瀏覽器血脈：Dream Passport、PlanetWeb 與 DreamKey，其中 DreamKey 內藏 3D 模型、影片與示範程式，甚至支援光槍控制器操作介面，技術野心遠超同期競爭者。PlayStation 2 日本版的 PlayStation Broadband Navigator 整合了 NetFront Browser 3.0，支援 HTML 4.1 與 JavaScript，並內建電子郵件與帳單功能，幾乎是一台完整的網路終端機。
2006 年是主機瀏覽器的黃金期。Nintendo Wii 的 Opera 授權版「網路頻道（Internet Channel）」原本收費 500 Wii Points，後改為免費，並支援 Flash；PlayStation 3 從 NetFront 轉移至 WebKit，達到近乎桌面等級的相容性，支援分頁瀏覽、截圖與影片播放。Nintendo DS 的 Opera 8.5 版本以雙螢幕設計解決了響應式設計尚未普及前的版面適配問題，提供「總覽」與「符合寬度」兩種瀏覽模式。 Wii U 是最後一代具備完整通用瀏覽器的主機，其 GamePad 觸控螢幕讓使用者可在電視播放內容的同時獨立操作瀏覽器，展示了雙螢幕 Web 互動的可能性。
主機瀏覽器的技術演進與桌面 Web 標準的發展並行但不同步。各平台面臨的共同挑戰包括：有限的 RAM（CD-i 的記憶體問題尤為極端）、電視螢幕的視距與解析度差異、無實體鍵盤的輸入限制，以及對閉源外掛（Flash、DRM）的依賴。3DS 的瀏覽器允許從系統記憶體或 SD 卡下載與上傳，在封閉生態中開了一扇小窗。
實際效果
現代主機——Nintendo Switch（含 Switch 2）、PlayStation 5 與 Xbox Series——均已移除面向使用者的通用瀏覽器。內部瀏覽器仍存在，但僅用於登入流程、eShop 內容顯示與 Web 應用，無法自由導航至任意網址。智慧型手機的普及從根本上改變了「平價上網裝置」的定義，主機瀏覽器因此失去了存在的必要性。
文章最後以一句話點出這段歷史的轉折：網路不再是人們「前往」的地方，而是始終隨身攜帶的存在。對前端開發者而言，這段歷史揭示了一個值得正視的現實：Web 標準曾被迫在 RAM 以 KB 計、顯示器以隔行掃描運作的環境中實作，那些妥協與創新共同塑造了今日我們視為理所當然的相容性假設——也留下了許多幾乎不再有人測試的邊界情境。