最近客戶買了一台 Android 平板電腦在測試網站，不過卻發生網站無法連線的狀況，我們依據客戶的描述也使用同事手邊的 Android 手機 (PDA) 進行測試，測試的結果卻相當順利 ( 測試相同網址 )。另外，客戶手邊的使用 Android 可以連接大部分網站，唯獨連到我們的測試網站就無法連線，最後才發現原來是域名中使用了底線所致。
以下是客戶提供的畫面圖示：
遇到這種問題我的直覺就是 網路斷線 不然就是 DNS 查不到 才會有這種錯誤訊息，接著便往這個方向著手追查問題，負責處理這個問題的人把網址中的「底線」切換成「減號」問題就自然迎刃而解，但我為了證明是網址域名中出現底線造成的問題，特別翻出了 RFC 1035 來證明這個問題的解決方式是正確的。
註：有時候將問題解決不見得是使用了正確的方法，我一向習慣將無法解釋的問題找到一種合理且可驗證的方式證明其問題發生的主因(root cause)，並找出佐證資料證明其正確性與可靠性。如果沒時間驗證解決方法的正確性，我就會對這次的解決方式產生質疑，並且不會相信自己解決問題的方法，並且在下次找出可以驗證的方式。
依據 RFC 1035 - Domain names - implementation and specification 規格的 2.3.1. Preferred name syntax 章節有提到一段話，說明網域名稱最好使用以下建議的格式，這樣可以減少在許多應用程式裡使用域名時會發生的問題，以下是原文片段轉載：
The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
以上表示式是在 RFC 規格裡經常使用的 Backus–Naur Form (BNF) 表示法，其中建議使用的字元並沒有底線 ( _ )，而且也提到了使用這個以外的格式(syntax)有可能會出現問題，雖然這份 RFC 規格是在西元 1987 年 11 月頒佈的，但還真想不到在 2011 年的今日還會有作業系統 (Android) 無法解析域名的狀況，可見 RFC 規格的偉大阿！
事實上在網址域名的地方有使用到底線字元的話，使用 IE 瀏覽器 ( IE6 ~ IE9 ) 也會導致 Cookie 無法正常寫入瀏覽器的狀況，無法寫入 Cookie 將對的就會導致 Session 遺失，以致於讓網站發生一些預期以外的錯誤，這些詭異的錯誤將會增加開發人員在除錯時的挫折感，因此各位還需特別小心。
相關連結