域名驗證器（RFC合規性檢查）
檢查域名是否符合RFC 1035/1123語法規則。逐項驗證標籤長度、總長度、允許字元和連字元位置，如有違規會顯示具體原因。
使用提示
- 本工具依據RFC 1035/1123規定的語法規則進行驗證，並不檢查該域名是否實際已註冊或可通過DNS解析。
- 在為表單自行編寫校驗正規表示式之前，先用本工具確認邊界情況（恰好63個字元、連字元位置等）的判定結果，有助於避免實現中的疏漏。
- 包含非ASCII字元（如日語域名）的輸入僅會跳過字元集檢查。如需精確驗證，請先使用Punycode轉換工具轉換為`xn--`表示後再輸入。
- 頂級域名全為數字的情況在實際中幾乎不會出現，但特意將其納入檢查項，以便在表單校驗時防止與IP地址混淆。
- 同樣的規則也可直接應用於電子郵件地址中`@`之後的部分（域名部分），因此也可用作郵箱域名的簡易檢查。
常見問題
根據RFC 1035，標籤（由`.`分隔的每一部分）為1〜63個字元，域名整體最多253個字元（源自二進位制傳輸格式中255位元組的限制）。不過各註冊局的政策可能會在此基礎上施加更嚴格的限制。
根據RFC 1035/1123，主機名中只允許使用字母、數字和連字元，不允許使用下劃線。不過在TXT或SRV等非主機名用途的DNS記錄標籤中（例如`_dmarc.example.com`），下劃線是被使用的。
RFC 1123規定每個標籤必須以字母數字字元開頭和結尾。若在開頭或結尾允許使用連字元，會使解析變得模糊，並可能與舊版DNS實現產生相容性問題，此規定正是為了避免這種情況。
包含日語等字元的國際化域名（IDN）在註冊到DNS之前，必須先轉換為Punycode（以`xn--`開頭的ASCII表示）。由於本工具設計為驗證Punycode轉換後的字串，建議先用Punycode轉換工具將非ASCII域名轉換後，再使用本工具進行語法檢查。
閒話 ― 為何「域名驗證」總是被反覆重新發明
域名的語法檢查乍看之下似乎只需一個簡單的正規表示式即可完成，但實際上許多開發者都曾在自行實現時栽過跟頭。無論是表單中的郵箱驗證、配置檔案中的主機名解析，還是API中的URL校驗，各種場景都需要處理「類似域名的字串」，然而能夠準確反映RFC 1035（1987年）和RFC 1123（1989年）正式規則的實現卻並不多見。
例如「每個標籤不超過63個字元」「整體不超過253個字元」這一兩級長度限制，源自DNS二進位制傳輸格式（實際在網路上交換的二進位制格式）的設計。每個標籤前面都會放置一個表示長度的位元組，而該位元組的取值被限制在0〜63（6位可表示的最大值）之內，這正是標籤長度限制的直接原因。
頂級域名不應全為數字這一慣例也有其有趣的歷史。這並非RFC中明文規定的強制規則，而是作為區分IPv4地址（數字與點組成的序列）和域名的一種實現智慧被廣泛採納。許多DNS解析器和瀏覽器正是利用這一慣例，將「192.168.1.1」這樣的字串判定為IP地址而非域名。