信箱地址格式怎麼看？標準長度與現實限制

信箱地址格式看起來只是幾個字加上一個符號，實際上它是兩段不同規則的組合，而且標準訂下的上限與現實服務接受的程度並不一致。這段落差是表單驗證最常見的誤傷來源：寫得太嚴會擋掉合法地址，寫得太鬆又會讓錯誤在寄信時才爆發。

一個信箱地址由哪兩半組成？

整條地址由「@」分成前後兩半。前半叫本地部分，是你在這個服務上的識別名稱；後半是網域，決定信要送到哪一台收信伺服器。這個「@」是唯一的分隔點，整條地址只應該有一個。

本地部分由提供服務的一方決定規則。多數服務只接受英文字母、數字、句點、底線與減號，而且不允許句點出現在開頭或結尾，也不允許連續兩個句點。這些限制不是標準規定的，而是各家的實作選擇。

網域的部分則要能被解析。它必須是有效的網域名稱，或是標準允許但現實少見的其他形式。只要網域無法被查到對應的收信伺服器，信就送不到，這一點與前半段完全無關。

公開標準對三個層級分別給了上限：本地部分最多 64 個位元組，網域最多 255 個位元組，整條地址（含用於標示的角括號）最多 256 個位元組。

要注意「位元組」不等於「字元」。同一個字元在不同編碼下佔用的空間不同，所以在有非 ASCII 字元的地址上，字元數會少於位元組數。這一層差異常被忽略，卻正好是長度判斷出錯的地方。

現實中，多數服務把整條地址收得比標準更窄，常見的工程慣例是收在兩百五十幾個字元以內。這是慣例而不是標準值，所以不能當成規定；但設計表單上限時，跟著慣例走通常比跟著理論上限走更安全。

標準的語法比多數人想像的寬鬆，但寬鬆的語法與實際可用的地址是兩件事。

這張表的用途不是教你寫出奇特的地址，而是提醒你：拿一個「標準上合法」的樣本去測別人的表單，被擋下來不代表對方寫錯了。判斷對錯要看該服務自己的規則，而不是只看標準。

其中「帶引號的本地部分」最值得寫驗證邏輯的人注意。這個寫法可以讓「@」出現在引號裡面，也就意味著整條地址可能有兩個以上的「@」；如果你的程式是靠著找最後一個「@」來分割前後兩半，遇到這種樣本就會切錯位置。標準的作法是從語法結構解析，而不是用字串搜尋。

反過來說，如果你在寫驗證邏輯，把標準語法全部拒絕是過度嚴格；把標準語法全部接受又會讓使用者在寄信時才發現問題。妥協點通常是：寬鬆地接受，嚴格地提示。

第一，上限要按標準訂，不要憑感覺。欄位長度如果訂得比標準更短，就會擋掉合法地址，而且這類問題通常要等到某位使用者抱怨才會被發現。

第二，大小寫要保留原樣。網域的部分不分大小寫，但本地部分在多數實作裡是有區分的；把使用者輸入的地址整條轉成小寫，可能讓他之後收不到信。

第三，不要自動移除空白。前後多一個空白確實是常見的打字錯誤，但內部的空白在某些語法下是有意義的；比較安全的作法是只修剪前後，其餘原樣保留。

第四，別忘了非 ASCII 的相容性。使用者的地址可能含有母語字元，你的欄位、資料庫與寄信流程都要先確認能不能處理，而不是等到有人填了才發現。處理方式有兩種：一種是原樣保存並在寄信時處理，另一種是明確拒絕並給出可讀的提示；最糟的是第三種，也就是默默接受卻在寄信時失敗。

還有一個常被忽略的細節：驗證信能不能寄到，與地址寫得對不對是兩件事。表單驗證只能確認格式，真正的答案是寄信結果；所以格式檢查應該寬鬆，而寄送失敗的提示要清楚可行動。

如果你正在寫表單驗證，最快的檢查方式是拿幾組邊界樣本實際跑一遍。在本站的臨時信箱裡產生地址，可以觀察一般服務接受的本地部分長什麼樣子；再對照信箱驗證測試的案例清單，補上長度與字元的邊界測試。

這裡的地址僅供測試與接收註冊驗證信，不得當作真實身分或聯絡方式；也不要用它來冒充他人、偽造往來紀錄或規避任何服務的規則。

先檢查你的欄位長度上限是不是比標準更短，這是最常見也最容易修正的一類誤傷。想了解地址在寄送過程中實際怎麼被處理，可以讀臨時信箱原理；上線前的整體檢查則可以參考事務郵件測試清單。