自動前綴 URL——節省數分鐘的細節功夫

在縮短連結的表單中，你會輸入 allegro.pl。大多數縮短工具會告訴你這不是有效的 URL，並要求你重新輸入，在前面加上 https://。而 cutty.dev 則會自動幫你加上 https:// 並繼續處理。

這聽起來像是一個幾乎不值得提及的功能。在實踐中，這是以下兩者之間的差異：

• 「我貼上了，有了短連結，關閉視窗」（2 秒）
• 「我貼上了，出錯了，閱讀訊息，加上 https，再試一次，終於得到連結」（15-20 秒）

將每月貼上 URL 的次數、閱讀錯誤訊息時的挫折感，以及「啊，原來是協定問題」的那個瞬間相乘。這是個人每月以分鐘計量的瑣碎成本。

cutty.dev 具體做什麼

你已在表單中貼上文字。在將資料傳送至伺服器之前，JavaScript 會檢查其是否以特定協定（如 http://、https://、ftp://、mailto: 等）開頭。如果不是以這些協定開頭，系統便假設這僅是一個沒有協定的網域，並在其前方加上 https://。

也就是說：

• allegro.pl → https://allegro.pl
• github.com/twoj-profil/projekt → https://github.com/twoj-profil/projekt
• www.gazeta.pl → https://www.gazeta.pl

如果某個協議已經存在（即使不正確），系統會保持原樣並繼續檢查：

• http://example.com → 保留為 http://example.com（允許）
• ftp://example.com → 被拒絕（僅限 http/https）
• javascript:alert(1) → 被拒絕（XSS 防護）

為什麼我有，而別人沒有？

大多數縮短器會使用 new URL(string) 進行標準的 URL 驗證。瀏覽器/JavaScript 中的 URL 建構子是嚴格的——如果缺少協議，它會拋出錯誤。new URL("allegro.pl") 的預設輸出為 TypeError。

這是大多數應用程式的正常行為。但對於縮短連結的表單而言，當使用者從地址列或其他應用程式貼上已複製的 URL 時，這種嚴格性反而成為障礙而非助力。

解決方案僅需五行 JavaScript 程式碼：

function sanitizeUrl(input) {
  const trimmed = input.trim();
  const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
  const normalized = hasProtocol ? trimmed : "https://" + trimmed;
  // dalsza walidacja przez new URL(normalized)
}

五行程式碼，每天每位使用者減少十幾秒的挫折感。我不明白為什麼大多數市場沒有這麼做。也許是因為「標準」意味著「URL 建構子的運作方式就是如此」。

細節在 UX 中佔有不成比例的重要性

cutty.dev 有幾十個這樣的東西，它們沒有出現在任何功能列表中，因為單獨看每個都顯得微不足道：

• 修剪空白字元 在驗證前執行 — 貼上的 URL 若結尾有空格，不會導致錯誤
• 雜湊值保留 — https://example.com/page#section 在縮短後仍保留 #section
• 查詢參數保留 — ?utm_source=test 會完整通過，不被截斷
• 自動協議升級 — 當來源 URL 支援 TLS 時，將 http:// 升級為 https://（已規劃，尚未上線）
• IDN 網域 — źdźbło.pl 會自動轉換為 Punycode
• Slug 中的波蘭文字 — 建立自訂結尾時，自動轉換為 ASCII（różowy-link → rozowy-link）
• 偵測危險協議 — javascript:、data:、file:、mailto: 會被拒絕，並顯示明確的錯誤訊息

這些細節中的每一個都能為使用者節省 5 到 30 秒的時間，並減少一瞬間的煩躁感。加總起來，這正是「我喜歡這款應用程式」與「它運作正常」之間的差異。

UX 細節的後續發展

未來想做的事情清單：

• 智慧貼上 — 偵測使用者在文字中貼上包含 URL 的內容，並自動提取該 URL
• 批量貼上 — 貼上一列 URL（每行一個），同時建立多個短連結
• 建議的 slug — 根據目標頁面的標題，推薦三個品牌化的結尾供選擇
• 自動 OG 預覽 — 在貼上 URL 後立即顯示 Open Graph 卡片的預覽，點擊前進行縮短

這些都是「看起來毫無用處的五行函數」。整體而言，區別在於一個只是堪用的工具，與一個你願意每天使用的工具。

自己試試看

貼上內容 — allegro.pl 或 github.com 或 news.ycombinator.com。系統會自動補上通訊協定並繼續處理。無需等待、不會報錯，也沒有「請重試」的提示。

如果你對這類 UX 細節感興趣——請告知我接下來該往哪個方向繼續發展。hello@cutty.dev。