背景

這篇討論源於 Daniel Lemire 的部落格文章，探討了在 URL 中使用換行符號（Newline characters）的可能性。文章指出，根據目前的網頁標準與瀏覽器實作，在 HTML 屬性或特定的 URL 解析過程中，換行符號與縮排符號（Tab）往往會被自動忽略或移除，這使得某些看似格式錯誤的網址在實務上仍能正常運作。

社群觀點

針對「URL 可以包含換行符號」這一觀點，Hacker News 社群的反應普遍趨向保守與質疑，多數開發者認為這屬於「雖然技術上可行，但實務上不應嘗試」的範疇。部分留言者精確地指出，標題可能帶有誤導性，更準確的說法應該是：當換行符號出現在 HTML 的 href 屬性中時，瀏覽器會先執行驗證並移除這些非法字元，隨後才嘗試導向正確的位址。這並非 URL 本身支持換行，而是瀏覽器容錯機制與 URL 解析規範（如 WHATWG URL Spec）共同作用的結果。

在技術風險方面，不少資深開發者表達了強烈的擔憂。最直接的威脅在於 HTTP 協議本身，因為換行符號在 HTTP 標頭中扮演著分隔符的角色，若在不當的情境下引入換行，極可能導致嚴重的安全漏洞或解析錯誤。此外，社群中也引發了一場關於檔案命名與字元處理的延伸討論。有開發者分享自己甚至連空白鍵都不願意在檔名中使用，傾向以底線代替，以避免在 URI 編碼時產生歧義，或是在口頭溝通檔名時造成困擾。這種對「乾淨路徑」的堅持，反映了工程界對於可預測性與穩定性的追求。

有趣的是，討論中也出現了對歷史規範的考據。有網友翻閱了 RFC 1738 規範，發現早期標準確實提到為了排版美觀，長網址在跨行顯示時可以加入空白或換行，並建議解析器在提取網址時應忽略這些字元。這顯示了現代瀏覽器的行為其實有其歷史脈絡。然而，多數人仍以幽默的譬喻來回擊這種技術冷知識，例如將「在 URL 加換行」比喻為「在麥片裡加酸黃瓜汁」，雖然物理上辦得到，但絕對不是一個好主意。

最後，部分討論轉向了對作者寫作風格的爭議。有讀者批評這類文章過於瑣碎且缺乏實際應用價值，甚至指責作者在面對質疑時的態度不夠透明。儘管如此，仍有少數人對這種挖掘技術細節的好奇心表示讚賞，認為這類冷知識有助於理解底層解析器的運作邏輯，即便在生產環境中永遠不會用到。

延伸閱讀

• WHATWG URL Standard: 詳細定義了現代瀏覽器如何解析 URL，包括對換行符號的處理邏輯。
• RFC 1738: 關於統一資源定位器（URL）的早期規範，其中提及了對空白字元的處理建議。
• RFC 2549: 關於鳥類載體（信鴿）傳輸 IP 數據包的服務質量（QoS）規範，作為網路協議歷史的趣味補充。