域名驗證器（RFC合規性檢查）
檢查域名是否符合RFC 1035/1123語法規則。逐項驗證標籤長度、總長度、允許字元和連字元位置，如有違規會顯示具體原因。
域名驗證器是什麼
域名驗證器會將輸入的字串依照RFC 1035（1987年發布）與RFC 1123（1989年發布）所訂定的域名語法規則逐一檢驗，而不是只給出「有效或無效」這樣單一的結論。它會明確顯示違反了哪一條規則，以及是哪個標籤（以.分隔的各個部分）導致違規，因此在你已經知道某個域名字串被系統拒絕、卻不清楚原因為何時，這項工具特別派得上用場。
請留意，本工具僅檢查語法（也就是字串的書寫形式），並不會向DNS查詢該域名是否已經實際註冊、對應網站是否正在運作，也不會告訴你這個名稱目前是否可供註冊。正因如此，它很適合在正式註冊或部署之前，先確認新域名候選名稱、或設定檔中預計使用的主機名稱，在語法上是否成立。
域名驗證器的使用方式
-
輸入域名
在輸入欄位中輸入想要檢查的域名（例如example.com）。請先移除開頭的通訊協定（如
https://）與結尾的路徑（如/path），只保留域名本身。 - 確認判定結果 輸入後會即時評估6項規則，每一項會分別顯示為「通過」「違規」或「提示」。
- 閱讀違規原因 標示為「違規」的項目會附上具體原因，例如出問題的標籤內容或字元數，可依此判斷該修改哪個部分。
- 用範例按鈕體驗邊界狀況 按下「有效示例」或「無效示例」按鈕，會自動帶入位於規則邊界的範例字串，方便快速了解各項規則的判定方式。
用好本工具的小技巧
- 本工具依據RFC 1035/1123規定的語法規則進行驗證，並不檢查該域名是否實際已註冊或可通過DNS解析。
- 在為表單自行編寫校驗正規表示式之前，先用本工具確認邊界情況（恰好63個字元、連字元位置等）的判定結果，有助於避免實現中的疏漏。
- 包含非ASCII字元（如日語域名）的輸入僅會跳過字元集檢查。如需精確驗證，請先使用Punycode轉換工具轉換為
xn--表示後再輸入。 - 頂級域名全為數字的情況在實際中幾乎不會出現，但特意將其納入檢查項，以便在表單校驗時防止與IP地址混淆。
- 同樣的規則也可直接應用於電子郵件地址中
@之後的部分（域名部分），因此也可用作郵箱域名的簡易檢查。
適用情境
實作表單驗證前的事先確認
在自行撰寫域名輸入欄位的驗證正規表示式之前，先用本工具確認恰好63個字元的標籤、連字元位置等邊界狀況，有助於提前發現實作上的疏漏。
新域名候選名稱的事先檢查
在為服務或子網域挑選候選名稱時，可以在向註冊商查詢之前，先確認該名稱在語法上是否成立。
電子郵件地址中域名部分的簡易驗證
電子郵件地址中@之後的部分基本上遵循相同的主機名稱規則，因此本工具也可作為郵件驗證邏輯的輔助檢查手段。
排查錯誤原因
當系統提示某個字串「不是有效的域名」卻不清楚具體原因時，可以貼上進來，快速找出未通過的規則。
術語表
- 標籤
- 域名中以
.分隔出的各個部分。以www.example.com為例，「www」「example」「com」這三者都是標籤。RFC 1035正是以標籤為單位限制長度與可用字元，而非針對域名整體。 - 頂級域名（TLD）
- 域名中最右側的那個標籤，例如.com或.jp。它位於DNS階層結構的最頂端，直接位於（不可見的）根網域之下。
- 完全限定域名（FQDN）
- 從主機名稱到頂級域名，完整、不省略任何層級寫出的域名。嚴格來說，FQDN結尾會帶有代表根網域的一個「.」（例如example.com.），只是日常使用時通常會省略這個句點。
- 國際化域名（IDN）
- 包含日語、中文、阿拉伯語等非ASCII字元的域名。由於DNS本身只能處理ASCII字元，IDN在實際註冊與解析之前都會被轉換為Punycode。
- Punycode
- 一種編碼方式（RFC 3492），用於將IDN中含有非ASCII字元的標籤轉換為DNS可以處理的ASCII字串。在DNS中，使用的是由IDNA在其結果前加上
xn--後的形式（A-label）。瀏覽器網址列通常會將其還原為原始文字後再顯示。 - 線路格式
- DNS查詢與回應在網路上實際傳輸時採用的二進位格式。每個標籤前面都會有一個表示其長度的位元組，而該位元組只能表示0到63之間的數值，這正是標籤長度上限訂為63個字元的技術根源。
- 主機名稱
- 用來識別網路上某台裝置的名稱，是域名的一種具體形式。RFC 1123將主機名稱可用的字元限定為字母、數字與連字元，本工具正是依據這項規則進行驗證。
常見問題
.分隔的每一部分）為1〜63個字元，域名整體最多253個字元（源自二進位制傳輸格式中255位元組的限制）。不過各註冊局的政策可能會在此基礎上施加更嚴格的限制。_dmarc.example.com），下劃線是被使用的。xn--開頭的ASCII表示）。由於本工具設計為驗證Punycode轉換後的字串，建議先用Punycode轉換工具將非ASCII域名轉換後，再使用本工具進行語法檢查。
閒話 ― 為何「域名驗證」總是被反覆重新發明
域名的語法檢查乍看之下似乎只需一個簡單的正規表示式即可完成，但實際上許多開發者都曾在自行實現時栽過跟頭。無論是表單中的郵箱驗證、配置檔案中的主機名解析，還是API中的URL校驗，各種場景都需要處理「類似域名的字串」，然而能夠準確反映RFC 1035（1987年）和RFC 1123（1989年）正式規則的實現卻並不多見。
例如「每個標籤不超過63個字元」「整體不超過253個字元」這一兩級長度限制，源自DNS二進位制傳輸格式（實際在網路上交換的二進位制格式）的設計。每個標籤前面都會放置一個表示長度的位元組，而該位元組的取值被限制在0〜63（6位可表示的最大值）之內，這正是標籤長度限制的直接原因。
頂級域名不應全為數字這一觀點也有其有趣的背景。RFC 1123（1989年）在允許主機名以數字開頭的同時補充說明：「由於至少最高層標籤是字母，有效的主機名永遠不會呈現 #.#.#.# 的形式。」這並不是以 MUST 形式寫成的規範性條文，但後來的 RFC 3696 也說明「存在實際上要求頂級域名不得全為數字的規則」。許多DNS解析器和瀏覽器正是利用這一前提，將「192.168.1.1」這樣的字串判定為IP地址而非域名。