JavaScript 的 Location 對象提供對當(dāng)前 URL 組件的訪問。人們可以將此對象視為當(dāng)前位置的只讀窗口。
Location 對象有兩個經(jīng)常混淆的屬性：主機和主機名。
位置.主機
host 屬性返回當(dāng)前 URL 的主機名、端口號和協(xié)議。例如，如果當(dāng)前 URL 為“http://example.com:8080/path/to/page.html”，則 host 的值為“example.com:8080”。
使用location.host的優(yōu)點
使用 location.host 相對于 location.hostname 也有一些優(yōu)點。
首先，它更加具體。如果您需要端口號或協(xié)議，您可以確定主機屬性將返回它。
第二，更加簡潔。如果您只需要主機名，則可以使用較短的主機名屬性。但如果您還需要端口號或協(xié)議，則可以使用主機屬性并一次性獲取所有信息。
第三，它更面向未來。如果添加新的 URL 組件，它可能會包含在主機屬性中。主機名屬性不一定是這種情況。
位置.主機名
另一方面，hostname 屬性僅返回當(dāng)前 URL 的主機名部分。例如，如果當(dāng)前 URL 為“http://example.com:8080/path/to/page.html”，則主機名的值為“example.com”。
使用location.hostname的優(yōu)點
使用 location.hostname 相對于 location.host 有一些優(yōu)點。
首先，它更具可讀性。當(dāng)您查看 URL 時，您通常對主機名比端口號或協(xié)議更感興趣。
第二，更加一致。主機名是 URL 的必需部分，而端口號和協(xié)議是可選的。這意味著并非所有 URL 都具有主機屬性，但它們都具有主機名。
第三，它更有彈性。如果更改 URL 的端口號或協(xié)議，主機名仍將相同。主機屬性的情況并非如此。
什么時候使用每個？
一般來說，除非您特別需要端口號或協(xié)議，否則您應(yīng)該使用 location.hostname。
原因是主機名是 URL 中“人類可讀”的部分，而主機屬性還包括端口號和協(xié)議。大多數(shù)時候，不需要這些額外的信息。
但是，也有一些例外。一個示例是，如果您需要使用當(dāng)前 URL 作為基礎(chǔ)來構(gòu)造新 URL。在這種情況下，您需要使用 location.host 來保留端口號和協(xié)議。
另一個例外是您使用 URL 縮短器。在這種情況下，您需要使用 location.host 來保留原始 URL 的主機名。
JavaScript 中 location.host 和 location.hostname 之間的差異
下表突出顯示了 JavaScript 中 location.host 和 location.hostname 之間的主要區(qū)別 –
| 比較基礎(chǔ) | 位置.主機 | 位置.主機名 |
|---|---|---|
| 定義 | host 屬性返回當(dāng)前 URL 的主機名、端口號和協(xié)議 | 另一方面，hostname 屬性僅返回當(dāng)前 URL 的主機名部分 |
| 示例 | 如果當(dāng)前 URL 為“http://example.com:8080/path/to /page.html”，則主機的值為“example.com:8080 | 如果當(dāng)前 URL 為“http://example.com:8080/path /to/page.html”，則主機名的值為“example.com”。 |
| 何時使用？ | 如果您特別需要端口號或協(xié)議，則應(yīng)使用 location.host。 | 除非您特別需要端口號或協(xié)議，否則您應(yīng)該使用 location.hostname。 |
| 可讀性 | 主機屬性還包括端口號和協(xié)議，使其可讀性較差。 | 主機名是 URL 中“人類可讀”的部分。 |
結(jié)論
在大多數(shù)情況下，您應(yīng)該使用 location.hostname 而不是 location.host。它更具可讀性、更一致、更有彈性。不過，也有一些例外情況，例如當(dāng)您需要構(gòu)造新 URL 或使用 URL 縮短器時。
以上就是JavaScript 中 location.host 和 location.hostname 之間的區(qū)別的詳細內(nèi)容，更多請關(guān)注www.92cms.cn其它相關(guān)文章！
