zetavg/zh-tw-wikipedia huggingface dataset:
HTTP_307

**307 Temporary Redirect** 是 HTTP 協定中的一個狀態碼（Status Code）。可以理解為一個臨時的重新導向。

但該回應代碼與 302 重新導向有所區別的地方在於，收到 307 回應碼後，客戶端應保持請求方法不變向新的位址發出請求。

## 引入

雖然 RFC 1945 和 RFC 2068 規範不允許客戶端在重新導向時改變請求的方法，但是很多現存的瀏覽器在收到 302 回應時，直接使用 GET 方式存取在 Location 頭部中規定的 URI，而無視原先請求的方法。

因此，狀態碼 307 被添加了進來，用以明確伺服器期待客戶端進行何種反應。

## 特徵

根據 RFC 2616 定義:

* 回應實體必須帶有一個 HTTP Location 頭部來指示新位址。
* 如果一個客戶端有連結編輯能力，其應當把所有的參照連結重新導向到新的 URL 上。
* 除非帶有 Cache-Control 或 Expires 頭部，否則該回應不能被快取。
* 除非請求方法是 HEAD，否則回應實體應該包含一個小型的超文字，標註一個超連結到新的 URL。
* 如果是除了 GET 和 HEAD 之外的請求方法，客戶端必須在重新導向之前詢問使用者。

## 範例

### 以 GET 方式請求

伺服器回應:

## 伺服器組態

這是一個例子，展示如何使用 Nginx 返回 307 重新導向：

```
location /old/url/ {
    return 307 /new/url;
}
```

這是使用 PHP 實現 307 重新導向的方式：

 

## 用途

* 該回應碼被用於 Chrome，用來在本地對已經快取的 HSTS 站點進行重新導向。
* 該回應碼也常用於客戶端發出 PUT 請求，但非上傳具體檔案時，伺服器向客戶端返回確認用的文字訊息。

## 參見

* HTTP
* HTTP 狀態碼
* URL 重寫
* HTTP 301
* HTTP 302

## 參考文獻

## 外部連結

* HTTP/1.1 Error codes in RFC 2616（頁面存檔備份，存於網際網路檔案館） （英文）
* RFC 1945 (HTTP 1.0)
* RFC 7231 (HTTP 1.1 的後續更新)
HTTP_403

**403 Forbidden** 是 HTTP 協定中的一個 HTTP 狀態碼（Status Code）。403 狀態碼意為伺服器成功解析請求但是客戶端沒有存取該資源的權限。

## IIS 上的 403 子錯誤代碼

下列非標準代碼由微軟的網際網路資訊服務所返回，這些代碼不被 IANA 官方認可。

* 403.1 - 禁止執行存取。
* 403.2 - 禁止讀取存取。
* 403.3 - 禁止寫入存取。
* 403.4 - 需要 SSL
* 403.5 - 需要 128 位元 SSL。
* 403.6 - IP 位址被拒絕。
* 403.7 - 需要客戶端憑證。
* 403.8 - 拒絕站點存取。
* 403.9 - 使用者數過多。
* 403.10 - 無效組態。
* 403.11 - 密碼更改。
* 403.12 - 對映器拒絕存取。
* 403.13 - 客戶端憑證被復原。
* 403.14 - 拒絕列出目錄。
* 403.15 - 客戶端存取授權過多。
* 403.16 - 客戶端憑證不被信任或無效。
* 403.17 - 客戶端憑證已過期或尚未有效。
* 403.18 - 無法執行來自此應用程式池的請求。
* 403.19 - 無法為客戶端執行此應用程式池中的 CGI。
* 403.20 - 認證登入失敗。
* 403.21 - 拒絕源存取。
* 403.22 - 無限深度被拒絕。
* 403.502 - 來自客戶端 IP 的請求過多；已達到動態 IP 限制。

## 相關條目

* .htaccess
* HTTP 狀態碼
* URL 重寫

## 參考文獻

## 外部連結

* Help for HTTP 403 'Forbidden' errors （英文）
HTTP_404

**HTTP 404** 或 **Not Found** 錯誤訊息是 HTTP 的其中一種「標準回應訊息」（HTTP 狀態碼），此訊息代表客戶端在瀏覽網頁時，伺服器無法正常提供訊息，或是伺服器無法回應且不知原因。通常是因為使用者所存取的對應網頁已被刪除、移動或從未存在。404 也是網際網路上最常見的錯誤之一。404 錯誤訊息可能與「server not found」（無法找到伺服器）或其他類似訊息產生混淆。

## 概要

當客戶端使用 HTTP 瀏覽網頁時，伺服器需要針對不同的「要求」提供不同的「回應」，譬如瀏覽器發出 HTML 檔案（網頁）的要求，並帶有數字回應碼和 MIME 的訊息。代碼 404 的第一個「4」代表客戶端的錯誤，如錯誤的 URL；後兩位數字碼則代表著特定的錯誤訊息。HTTP 的三字元代碼跟早期通訊協定 FTP 和 NNTP 的代碼相當類似。

從 HTTP 的層面來看，404 訊息碼之後通常會有一個可讀的訊息「Not Found」，許多網路伺服器的預設頁面也都有「404」代碼跟「Not Found」的詞彙。

404 錯誤訊息通常是在目標頁面被更動或移除之後顯現的頁面。在第一種情況下，最好透過返回 301 Moved Permanently 回應進行 URL 對映或 URL 重新導向，該回應可以在大多數伺服器設定檔中組態，或者透過 URL 重寫 ；在第二種情況下，應返回 410 Gone。因為此兩種訊息需要特別架構的伺服器，許多網站並不使用。

## 軟 404

一些網站會以「200 OK」的回應訊息來回覆「Not Found」的錯誤，錯誤地報告該頁面已正確載入，稱為**軟 404**（soft 404）。軟 404 對於連結是否存在的判斷對搜尋引擎的抓取是有極大影響的，雅虎和 Google 會使用自動化工具來檢測軟 404。部分搜尋引擎的網路蜘蛛會對軟 404 的網站降低搜尋權重作為懲罰。

## 客製化 404 頁面

網頁伺服器通常可以組態自訂的 404 錯誤頁面，包括對使用者更友好的描述，站點標識，有時還包括站點地圖，搜尋表單或 404 頁面小部件。

越來越多的網站喜歡裝飾 404 頁面，如 Metro UK 的 404 頁面展示了一隻踩滑板的北極熊圖片，Web 開發機構 Left Logic 的 404 錯誤頁面則嵌入了一個簡單的繪圖程式。部分網站也利用 404 頁面展示公益廣告，如尋找失蹤兒童。

## 大眾文化

2008 年，英國皇家郵政電信部門進行了一項研究發現，「404」在俚語中用來描述「愚笨、無用之人」。據俚語詞典編撰者喬納森・格林（Jonathon Green）稱，「404」能作為俚語很大程度上受新世代接觸網際網路的年輕人推動的，但這種用法僅限於倫敦和其它大城市地區。

美國全球語言研究所的調查顯示，2013 年，404 Not Found 成為網路熱詞。

在中國，404 被大部分網友普遍用作網站被防火長城封鎖的代名詞。事實上，包括 404 在內的 HTTP 狀態碼由伺服器應答，即網站本身可存取。而 IP 封鎖、DNS 污染等切斷使用者連接網站伺服器的封鎖方式不會返回任何 HTTP 狀態碼。

## 參考文獻

## 外部連結

* Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content#section-6.5.4. IETF. 2014-06 [2018-09-16]. （原始內容存檔於 2017-05-25） （英語）.
* ErrorDocument Directive - Apache 2.0 web server 一般錯誤訊息的處理措施
* The Perfect 404（頁面存檔備份，存於網際網路檔案館） - 建立 404 頁面的指南
* 404 Research Lab - 不同的 404 錯誤訊息頁面
* 轉址式 404 (soft 404) 是什麼？ - soft 404 成因以及對於搜尋引擎的影響
HTTP_418

**超文字咖啡壺控制協定**（英語：Hyper Text Coffee Pot Control Protocol，縮寫 **HTCPCP**）是由 IETF 虛構的一種協定。這個協定在文件 RFC 2324（1998 年 4 月 1 日發布）中定義，是一個惡搞 RFC。

該協定被設計為一個類似 HTTP 的協定，可以用於控制、監測和診斷咖啡壺，後來也被拓展到茶壺；該協定有時也可以視作一種早期的物聯網實驗。

## 起源

儘管網際網路國際標準機構經常在 4 月 1 日（愚人節）發布一些惡搞之作，他們還是讓這個協定看上去像是一個真的、非虛構的協定（就像 HTTP）。

## 相容性

* 文字編輯器 Emacs 完全相容這個協定。
* 有數個 bug 報告抱怨說 Mozilla 不支援這個協定。

## 後續擴充

2014 年 4 月 1 日發布的惡搞 RFC 7168 是此協定的擴充，正式支援茶壺。

## 請求方式定義

HTCPCP 是 HTTP 協定的擴充。HTCPCP 請求通過 URI 架構 `coffee:` 來參照，並還包含了若干種 HTTP 請求：

* `BREW` 或 `POST`：令 HTCPCP 伺服器（咖啡壺）煮咖啡。
* `GET`：從伺服器取得咖啡。
* `PROPFIND`：取得咖啡的元資料。
* `WHEN`：讓伺服器停止向咖啡中加入牛奶（如適用），即英文「say when」之意。

## 錯誤應答

這個協定還定義了兩種錯誤答覆：

* `406 Not Acceptable`（無法接受）：HTCPCP 伺服器因故暫時不能煮咖啡。伺服器在回覆中應當包含一組可接受的咖啡類型列表。
* `418 I'm a teapot`（我是茶壺）：HTCPCP 伺服器是一個茶壺。這個錯誤答覆可能是由一個又矮又胖的東西（也就是茶壺）發出的。

## 相關條目

* RFC
* 惡搞 RFC
* 以鳥類為載體的網際協定

## 參考資料

## 外部連結

* Google 的 418 I'm a teapot "錯誤" 頁面
HTTP_451

在電腦網路領域中，**HTTP 451 因法律原因不可用**（英語：HTTP 451 Unavailable For Legal Reasons）是一種 HTTP 協定的錯誤狀態代碼，當使用者請求存取某個經政府審核等查核方法後認定不合法的來源時，就會顯示這個錯誤代碼。

該狀態碼定義於 RFC 7725 中，與 HTTP 協定其他的狀態碼不同。

## 定義

根據定義，HTTP 451 錯誤代碼狀態出現，不代表這個位址是否存在，而代表該網頁可能違反基於法律違規主張的要求。

該回應代碼有如下的性質：

* 除非另外指明，否則這個回應代碼是可以被快取的。
* 必須攜帶一個帶有一個 Link 頭部，列出要求封禁該位址的實體 URI；且應帶有一個 "rel" 欄位，值應為 "blocked-by"。

## 引入

本代碼於 2013 年由提姆・布雷（Tim Bray）正式提出，主要基於部落格 Terence Eden 的文章所提出的非正式提案。2015 年 12 月 18 日，此代碼由國際網路工程研究團隊通過。

451 這個代碼源於 1953 年的反烏托邦小說《華氏 451 度》（紙的燃點為華氏 451 度），在這部小說中，所有書籍是違禁品。相比較 HTTP 403 或 404 代碼，451 可更好描述一種由於法律規定或受權威部門要求而導致的封禁狀態。

## 演示範例

在本章節中，將對於 HTTP 451 的回應的返回、快取的設定和 Link 頭部的設定做出範例。

某地一使用者以 GET 方式請求 example.org 的 /index.php 路徑：

### 伺服器回應

由於使用者所在地的某項法律規定，網站不可以向該地區使用者返回這個頁面，所以伺服器做出回應，設定了有效期為一年的快取頭部，並在 Link 頭部中加入了指定的法律文字 URL「http://www.xxx.gov.tld/law.html」：

### 非伺服器實體

根據 RFC 文件第 3 節和第 4 節，作出回應的伺服器不一定是源伺服器，也可能是 ISP 或其他實體的伺服器向使用者返回 HTTP 451。該文件第四節進一步說明，回應中的 blocked-by 對應之頭部應連結至**實際執行此次封鎖的實體**，而不是作出決定的實體。假設某網路主管部門要求這些運營商的防火牆伺服器對所有存取某站點特定內容之請求均返回 451，則防火牆伺服器可以這樣回應使用者：

## 現實案例

### Github

2016 年 6 月 8 日，中國網路空間安全協會用英文致信 GitHub，稱其平台上的開源專案「Zhao」誹謗現任中國共產黨中央委員會總書記習近平，要求立刻刪除。三天後，GitHub 在專門公布各國政府發出的移除要求的版面上，公布了這封信件。

據信件所描述，GitHub 使用者 Programthink 建立的代碼倉庫「Zhao」中出現了一篇使用者名稱為「CMB-news」的帳號發布的「問題」（Issue），聲稱習近平涉及一樁命案，故引發相關部門「強烈關切」。根據 GitHub 公布的資訊顯示，這是 2014 年 10 月以來，GitHub 公布的第 6 項「刪除特定專案要求」，也是第一個來自中國政府相關方請求，此前 5 項都來自俄羅斯。

後來，GitHub 對於存取該倉庫的中國大陸使用者返回 451 代碼，並連結向上述投訴信件；但在海外的使用者仍能順利打開。 GitHub 給出的原因是「這個專案被中國政府列入黑名單」。GitHub 稱，雖無法認同政府審查，但為讓更多人可以正常使用網站服務，他們會在確認有關要求來自政府之後，在指定區域內滿足政府的要求，同時會公開來自政府的要求檔案。

## 參見

* HTTP
* HTTP 狀態碼
* HTTP 403
* HTTP 404
* 防火長城
* 科技解決

## 注釋

## 參考文獻

## 外部連結

* RFC 7725 - HTTP 451 的正式 RFC 檔案
* 451unavailable.org（頁面存檔備份，存於網際網路檔案館） 一個介紹 HTTP 451 錯誤代碼的網站
HTTP_Cookie

**HTTP cookie**，簡稱 **cookie**，又稱「**網站／瀏覽＋魔餅／魔片**」等，是瀏覽網站時由網路伺服器建立並由網頁瀏覽器存放在使用者電腦或其他裝置的小文字檔案。

Cookie 使 Web 伺服器能在使用者的裝置儲存狀態資訊（如添加到線上商店購物車中的商品）或跟蹤使用者的瀏覽活動（如點擊特定按鈕、登入或記錄歷史）。

## 歷史

「cookie」一詞由網路瀏覽器程式設計師盧・蒙特利創造，源自「magic cookie」（1979 年就已經出現，當時指 UNIX 程式收發的封包）。「magic cookie」這詞本身來自幸運餅。

盧・蒙特利在 1994 年 6 月想到這點子時正在網景工作，公司則正在為 MCI 開發電子商務應用程式。文頓・瑟夫和約翰・克倫辛代表 MCI 與網景討論技術，表示不希望總是由其伺服器儲存事務狀態，而要求網景將狀態儲存在使用者電腦。Cookies 便是網景提出的解決方案。

同年，蒙特利與約翰・詹南德雷亞一起編寫了最初的網景 cookie 規範。1994 年 10 月 13 日發布的網景領航員 0.9beta 版開始支援 cookie。它公開的首次使用目的是檢查網景網站的存取者是否已經存取過該網站。蒙特利於 1995 年申請了 cookie 技術的專利，1998 年獲批（US 5774670 ）。1995 年 10 月發布的第 2 版 Internet Explorer 也宣布支援 cookie。

當時，cookie 並未為公眾所知，雖然預設使用者接受 cookie，網站並不會通知使用者其存在。1996 年 2 月 12 日，英國《金融時報》發表文章介紹 cookie，使其為大眾所知。其潛在的隱私問題也引起討論，1996 年和 1997 年的美國聯邦貿易委員會兩次就 cookie 舉行聽證會。

網際網路工程任務組專門成立了工作小組規範 cookie 的用法。布萊恩・貝倫多夫和大衛・克里斯托分別提出兩套有關 HTTP 事務狀態的替代方案。但由克里斯托本人和蒙特利領導的小組很快決定還是使用網景規範。1996 年 2 月，工作群組將第三方 cookie 確定為嚴重隱私威脅。該小組制定的規範 RFC 2109 最終於 1997 年 2 月發布，要求第三方 cookie 要麼根本不允許，要麼至少預設不啟用。

網景的 cookie 頭欄位為 `Set-Cookie，`RFC 2965 添加了 `Set-Cookie2` 頭欄位，即「RFC 2965 cookie」，但 `Set-Cookie2` 很少使用，終於 2011 年 4 月的 RFC 6265 中棄用，已經沒有現代瀏覽器可以辨識 `Set-Cookie2` 頭欄位。

## 結構

Cookie 的基本結構包括

1. 名；
2. 值；
3. 各種屬性。

### 屬性

一塊 cookie 可能有 Domain、Path、Expires、Max-Age、Secure、HttpOnly 等多種屬性，如

#### Domain 和 Path

`Domain` 和 `Path` 屬性定義了 cookie 的範圍。它們告訴瀏覽器 cookie 屬於什麼網站。Cookies 只能設定在當前資源的頂級域及其子域上。

如果伺服器未指定 cookie 的 `Domain` 和 `Path`，則它們預設為所請求資源的域和路徑。

#### Expires 和 Max-Age

`Expires` 屬性定義了瀏覽器應刪除 cookie 的時間，格式為 `Wdy, DD Mon YYYY HH:MM:SS GMT` 或 `Wdy, DD Mon YY HH:MM:SS GMT`（YY 大於或等於 0 並且小於等於 69）。

此外也可用 `Max-Age` 將 cookie 的過期時間設定為某一段時間之後（相對於瀏覽器接收 cookie 的時間而言）。但 Internet Explorer 等瀏覽器可能不支援 `Max-Age`。

#### Secure 和 HttpOnly

`Secure` 屬性旨在將 cookie 加密，使瀏覽器僅通過安全／加密連接使用 cookie。

`HttpOnly` 要求瀏覽器不要通過 HTTP（和 HTTPS）以外的管道使用 cookie。這意味著無法通過客戶端手稿語言（尤其是 JavaScript）存取 cookie，因此無法通過跨站點指令碼攻擊輕易竊取。

## 分類

### 對談 cookie

對談 cookie 僅在瀏覽網站時臨時儲存，關閉瀏覽器後會自動過期或刪除。

### 持久 cookie

持久 cookie 只在其建立者設定的特定日期後過期，期間一直有效。

### 安全 cookie

安全 cookie 只能通過加密連接傳輸（HTTPS）。它們不能通過未加密的連接傳輸（HTTP），使 cookie 不易被盜。

## 用途

### 對談管理

雖然最初引入 cookie 是為了讓使用者在瀏覽網站時記錄要購買的物品。但現在使用者購物車的內容通常儲存在伺服器的資料庫中，而不再是客戶端的 cookie 中。

當前對談 cookie 的常見用途是登入。當使用者存取網站的登入頁面時，Web 伺服器通常會向客戶端傳送一個包含唯一交談識別碼符的 cookie。當使用者成功登入時，伺服器會記住該特定交談識別碼符已經過身分驗證，並授予使用者存取其服務的權限。

### 喜好設定

許多網站用 cookie 儲存使用者偏好等設定，向使用者顯示喜好內容。

### 跟蹤

跟蹤 cookie 用於跟蹤記錄使用者的網路瀏覽習慣，如使用者的購物習慣。

## 瀏覽器設定

大多數現代瀏覽器都支援 cookie 並允許使用者禁用它們，以下是常見選項：

* 完全啟用或禁用 cookie，以便它們始終被接受或始終被阻止；
* 使用 cookie 管理器檢視和有選擇地刪除 cookie；
* 徹底清除 cookie 等所有私人資料。

此外也有管理 cookie 權限的附加元件。

## 安全和隱私

### 第三方 cookie 和隱私

網頁可能第三方服務，使用網頁很可能會遇到第三方 cookie（存取網頁外其他伺服器的 cookie）。RFC 2109 和 RFC 2965 要求瀏覽器保護使用者隱私，預設不允許在伺服器間共享 cookie，但 RFC 6265 放寬。大多數瀏覽器只要第三方網站有合理的隱私政策申明，就預設允許第三方 cookie。

廣告是第三方 cookie 常見的使用場景，廣告公司藉此跟蹤使用者。網站應當告知使用者有第三方 cookie 存在，不向消費者披露第三方 cookie 使用情況的網站運營商可能面臨法律風險，一般網站都會在隱私或 cookie 政策說明其使用的第三方 cookie。

### 竊取 Cookie 和劫持對談

很多網站用 cookie 作為使用者的唯一識別碼，但如果網站使用 cookie 作為交談識別碼符，攻擊者就可以竊取受害者的全套 cookie 來冒充其請求。

Youtube 頻道 LinusTechTips 在 2023 年 3 月就曾遭竊取 cookie 的駭客入侵頻道須暫停運作，現已恢復正常。

## 參考文獻

## 外部連結

* RFC 6265
HTTP_ETag

**ETag** 或**實體標籤**（**entity tag**）是全球資訊網協議 HTTP 的一部分。

ETag 是 HTTP 協議提供的若干機制中的一種 Web 緩存驗證機制，並且允許客戶端進行緩存協商。這就使得緩存變得更加高效，而且節省帶寬。如果資源的內容沒有發生改變，Web 伺服器就不需要發送一個完整的響應。ETag 也可用於樂觀並發控制，作為一種防止資源同步更新而相互覆蓋的方法。

ETag 是一個不透明的標識符，由 Web 伺服器根據 URL 上的資源的特定版本而指定。如果那個 URL 上的資源內容改變，一個新的不一樣的 ETag 就會被分配。用這種方法使用 ETag 即類似於指紋，並且他們能夠被快速地被比較，以確定兩個版本的資源是否相同。ETag 的比較只對同一個 URL 有意義 —— 不同 URL 上的資源的 ETag 值可能相同也可能不同，從他們的 ETag 的比較中無從推斷。

## 部署風險

ETag 在 HTTP 頭欄位中的使用是可選的（不像 HTTP/1.1 的其他頭欄位是強制性的）。HTTP 規範從未指定生成 ETag 的方法。

生成 ETag 常用的方法包括對資源內容使用抗碰撞散列函數，使用最近修改的時間戳的哈希值，甚至只是一個版本號。

為了避免使用過時的緩存數據，用於生成 ETag 的方法應保證（同時儘可能的實用）每一個 ETag 都是唯一的。然而，只要 ETag 的生成函數可以用數學證明，即使生成的 ETag 可能重複，其概率也是可接受範圍內的無窮小，那麼就可以判斷這個函數是可用的。

一些早期的校驗和函數，如 CRC32 和 CRC64，常會碰到哈希碰撞問題。正因如此，他們並不是用於生成 ETag 的好選擇。

## 強校驗和弱校驗

ETag 機制同時支持強校驗和弱校驗。它們通過 ETag 標識符的開頭是否存在「W/」來區分，如：

```
"123456789"   -- 一个强ETag验证符
W/"123456789"  -- 一个弱ETag验证符
```

強校驗的 ETag 匹配要求兩個資源內容的每個字節需完全相同，包括所有其他實體欄位（如 `Content-Language`）不發生變化。強 ETag 允許重新裝配和緩存部分響應，以及字節範圍請求。弱校驗的 ETag 匹配要求兩個資源在語義上相等，這意味著在實際情況下它們可以互換，而且緩存副本也可以使用。不過這些資源不需要每個字節相同，因此弱 ETag 不適合字節範圍請求。當 Web 伺服器無法生成強 ETag 的時候，比如動態生成的內容，弱 ETag 就可能發揮作用了。

## 典型用法

在典型用法中，當一個 URL 被請求，Web 伺服器會返回資源和其相應的 ETag 值，它會被放置在 HTTP 的「ETag」欄位中：

```
ETag: "686897696a7c876b7e"
```

然後，客戶端可以決定是否緩存這個資源和它的 ETag。以後，如果客戶端想再次請求相同的 URL，將會發送一個包含已保存的 ETag 和「If-None-Match」欄位的請求。

```
If-None-Match: "686897696a7c876b7e"
```

客戶端請求之後，伺服器可能會比較客戶端的 ETag 和當前版本資源的 ETag。如果 ETag 值匹配，這就意味著資源沒有改變，伺服器便會發送回一個極短的響應，包含 HTTP 「304 未修改」的狀態。304 狀態告訴客戶端，它的緩存版本是最新的，並應該使用它。

然而，如果 ETag 的值不匹配，這就意味著資源很可能發生了變化，那麼，一個完整的響應就會被返回，包括資源的內容，就好像 ETag 沒有被使用。這種情況下，客戶端可以用新返回的資源和新的 ETag 替代先前的緩存版本。

ETag 值可用於網頁監視系統。大多數站點沒有為網頁設置 ETag 頭信息，這一事實阻礙了高效的網頁監測。當 Web 監視器不知道網站內容是否發生變化的時候，它不得不被檢索和分析所有的內容，這不僅占用發布者的計算資源，還有訂閱者的。

## 用 ETag 來跟蹤用戶

由於 HTTP cookie 被越來越多的注重隱私保護的用戶刪除，可以將 ETag 用來追蹤唯一用戶。2011 年 7 月，Ashkan Soltani 和加州大學伯克利分校的一組研究者，包括 Hulu.com 將 ETag 用於追蹤用途。Hulu 和 KISSmetrics 在 2011 年 7 月 29 日停止了這樣的追蹤，而 KISSmetrics 和超過 20 位其用戶面臨關於「無法刪除」的 cookie 的集體訴訟，其中包括了 ETag 的使用。

因為 ETag 由瀏覽器保存，並且在訪問統一資源時隨之後請求返回，一個追蹤伺服器可以輕鬆地重複設定任何從瀏覽器收到的 ETag，以保持 ETag 不變，類似於持久 cookie。額外的緩存頭部也能增強 ETag 的持久性。

根據實現，ETag 可以通過清除瀏覽器緩存清除。

## 參考資料

## 外部連結

* Apache HTTP Server Documentation - FileETag Directive（頁面存檔備份，存於網際網路檔案館）
* _Editing the Web: Detecting the Lost Update Problem Using Unreserved Checkout（頁面存檔備份，存於網際網路檔案館）,_ W3C Note, 10 May 1999.
* Old SQUID Development projects - ETag support（頁面存檔備份，存於網際網路檔案館） (completed in 2001)
* Using ETags to Reduce Bandwidth & Workload with Spring & Hibernate（頁面存檔備份，存於網際網路檔案館）
* Live demo of zombie cookie using ETags
* ETag in HTTP/1.1 specification（頁面存檔備份，存於網際網路檔案館）
* Concerning ETags and Datestamps by Lars R. Clausen (2004)
HTTP_Live_Streaming

**HTTP Live Streaming**，縮寫為 **HLS**，是由蘋果公司提出基於 HTTP 的串流媒體網路傳輸協定。是蘋果公司 QuickTime X 和 iPhone 軟體系統的一部分。它的工作原理是把整個流分成一個個小的基於 HTTP 的檔案來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許串流媒體對談適應不同的資料速率。在開始一個串流媒體對談時，客戶端會下載一個包含元資料的擴充 M3U (m3u8) 播放列表檔案，用於尋找可用的媒體流。

HLS 只請求基本的 HTTP 報文，與即時傳輸協定（RTP）不同，HLS 可以穿過任何允許 HTTP 資料通過的防火牆或者代理伺服器。它也很容易使用內容分發網路來傳輸媒體流。

蘋果公司把 HLS 協定作為一個網際網路草案（逐步提交），在第一階段中已作為一個非正式的標準提交到 IETF。2017 年 8 月，RFC 8216 發佈，描述了 HLS 協定第 7 版的定義。

## 伺服器支援

* Adobe Flash Media Server：從 4.5 開始支援 HLS、Protected HLS（PHLS）。5.0 改名為 Adobe Media Server
* Flussonic Media Server（頁面存檔備份，存於網際網路檔案館）：2009 年 1 月 21 日，版本 3.0 開始支援 VOD、HLS、時移等。
* RealNetworks 的 Helix Universal Server：2010 年 4 月，版本 15.0 開始支援 iPhone, iPad 和 iPod 的 HTTP 直播、點播 H.264/AAC 內容，最新更新在 2012 年 11 月。
* 微軟的 IIS Media Services：從 4.0 開始支援 HLS。
* Nginx RTMP Module：支援直播模式的 HLS。
* Nimble Streamer（頁面存檔備份，存於網際網路檔案館）
* Unified Streaming Platform（頁面存檔備份，存於網際網路檔案館）
* VLC Media Player：從 2.0 開始支援直播和點播 HLS。
* Wowza Media Server：2009 年 12 月 9 日發布 2.0，開始全面支援 HLS。
* VODOBOX Live Server：始支援 HLS。
* Gstreamill（頁面存檔備份，存於網際網路檔案館）是一個支援 hls 輸出的，基於 gstreamer 的即時編碼器。

## 客戶端支援

* iOS 從 3.0 開始成為標準功能。
* Adobe Flash Player 從 11.0 開始支援 HLS。
* Google 的 Android 自 Honeycomb（3.0）開始支援 HLS。
* VODOBOX HLS Player (Android,iOS, Adobe Flash Player)
* JWPlayer (Adobe Flash)
* Flowplayer (Adobe Flash, 使用 hlsjs 版本不使用 Adobe Flash)
* Windows 10 的 EDGE 瀏覽器開始支援 HLS。

## 參見

* 自適性串流

## 參考書目

## 外部連結

* Daniel Eran Dilger. Apple launches HTTP Live Streaming standard in iPhone 3.0. Apple Insider. 2009-07-08 [2009-07-10]. （原始內容存檔於 2019-05-13）.
* Chris Foresman. Apple proposes HTTP streaming feature as protocol standard. Ars Technica. July 9, 2009 [2009-07-10]. （原始內容存檔於 2009-07-11）.
* Internet-Draft: HTTP Live Streaming: draft-pantos-http-live-streaming（頁面存檔備份，存於網際網路檔案館）
* Backbone Networks supports http live streaming in its Internet Radio Automation system（頁面存檔備份，存於網際網路檔案館）
* Apple to Provide Live Video Streaming of September 1 Event（頁面存檔備份，存於網際網路檔案館）.
HTTP_Location

**HTTP Location** 是在兩種情況下，因來自 HTTP 服務器的響應中返回頭域：

1. 要求網頁瀏覽器加載其他網頁（網域名稱轉址）。在這種情況下，應該使用 HTTP 狀態碼 3xx 發送 Location 頭（Location header）。當請求的 URI 具有以下內容時，Web 服務器響應傳遞：
  * 臨時移動；
  * 永久移動；
  * 處理請求，例如一個 POST 表單，以一個不同的 URI 來提供該請求的結果。
2. 提供有關新創建資源位置的信息。在這種情況下，應該使用 HTTP 狀態碼 201 或 202 發送 Location 頭。

HTTP 1.1 規範（IETF RFC 2616）的過時版本需要完整的重定向 URI。 IETF HTTP 工作組發現，最受歡迎的 Web 瀏覽器允許傳遞相對 URL（relative URL） 。因此，更新後的 HTTP 1.1 規範（IETF RFC 7231）放寬了原始的約束，允許在位置標題中使用相對 URL。

## 例子

### 絕對 URL（Absolute URL）示例

絕對 URL 是一種以方案為頭的 URL (例如：http:，https:，telnet:，mailto:) ，並符合方案特定的語法和語義。 例如 HTTP URL 特定於 HTTP 方案的語法和語義需要用「主機」（Web 服務器地址）和「絕對路徑」，其中可選元件為「埠」和「查詢」。

例如，客戶端請求:

伺服器回應:

該位置的 URL 被客戶端重定向到 http://www.example.org/index.php.

### 相對 URL（Relative URL）示例

相對 URL 是不包含方案或主機的 URL。為了理解，它們必須與原始請求的 URL 相結合。例如，客戶端請求:

伺服器回應:

該位置的 URL 被客戶端擴展為 http://www.example.com/articles/.

## 參見

* 網域名稱轉址
* HTTP

## 參考文獻
HTTP_Strict_Transport_Security

**HTTP 嚴格傳輸安全**（英語：**H**TTP **S**trict **T**ransport **S**ecurity，縮寫：**HSTS**）是一套由網際網路工程任務組發布的網際網路安全策略機制。網站可以選擇使用 HSTS 策略，來讓瀏覽器強制使用 HTTPS 與網站進行通信，以減少連線劫持風險。

其徵求修正意見書檔案編號是 RFC 6797，發布於 2012 年 11 月。

## 內容

HSTS 的作用是強制客戶端（如瀏覽器）使用 HTTPS 與伺服器建立連接。伺服器開啟 HSTS 的方法是，當客戶端通過 HTTPS 發出請求時，在伺服器返回的超文字傳輸協定（HTTP）回應頭中包含 `Strict-Transport-Security` 欄位。非加密傳輸時設定的 HSTS 欄位無效。

比如，https://example.com/ 的回應頭含有 `Strict-Transport-Security: max-age=31536000; includeSubDomains`。這意味著兩點：

1. 在接下來的 31536000 秒（即一年）中，瀏覽器向 example.com 或其子域名傳送 HTTP 請求時，必須採用 HTTPS 來發起連接。比如，使用者點擊超連結或在網址列輸入 http://www.example.com/ ，瀏覽器應當自動將 http 轉寫成 https，然後直接向 https://www.example.com/ 傳送請求。
2. 在接下來的一年中，如果 example.com 伺服器傳送的 TLS 憑證無效，使用者不能忽略瀏覽器警告繼續存取網站。

## 歷史

HSTS 的雛形來自於 2008 年 4 月在北京召開的第十七屆國際全球資訊網大會上柯林・傑克遜（Collin Jackson）和亞當・巴斯（Adam Barth）的題為「ForceHTTPS: Protecting High-Security Web Sites from Network Attacks」的演講。他們的提議是使用「ForceHTTPS」 Cookie 來強制瀏覽器使用 HTTPS。

2009 年 9 月 18 日，他們和傑夫・霍奇斯（Jeff Hodges）發布了最初的草案，題目為 "Strict Transport Security"，這個草案基於 ForceHTTPS，並有所修改。

2010 年 6 月 17 日，這三位作者經由網際網路工程任務組發布了首版網際網路草案，"HTTP Strict Transport Security"。

2012 年 10 月 2 日，網際網路工程指導組批准了將第 14 版 HSTS 草案發布為 RFC 的請求。

2012 年 11 月 19 日，網際網路工程任務組發布 RFC 6797。

## 作用

HSTS 可以用來抵禦 SSL 剝離攻擊。SSL 剝離攻擊是中間人攻擊的一種，由 Moxie Marlinspike 於 2009 年發明。他在當年的黑帽大會上發表的題為「New Tricks For Defeating SSL In Practice」的演講中將這種攻擊方式公開。SSL 剝離的實施方法是阻止瀏覽器與伺服器建立 HTTPS 連接。它的前提是使用者很少直接在網址列輸入 `https://`，使用者總是通過點擊連結或 3xx 重新導向，從 HTTP 頁面進入 HTTPS 頁面。所以攻擊者可以在使用者存取 HTTP 頁面時替換所有 `https://` 開頭的連結為 `http://`，達到阻止 HTTPS 的目的。

HSTS 可以很大程度上解決 SSL 剝離攻擊，因為只要瀏覽器曾經與伺服器建立過一次安全連接，之後瀏覽器會強制使用 HTTPS，即使連結被換成了 HTTP。

另外，如果中間人使用自己的自簽章憑證來進行攻擊，瀏覽器會給出警告，但是許多使用者會忽略警告。HSTS 解決了這一問題，一旦伺服器傳送了 HSTS 欄位，將不再允許使用者忽略警告。

## 不足

使用者首次存取某網站是不受 HSTS 保護的。這是因為首次存取時，瀏覽器還未收到 HSTS，所以仍有可能通過明文 HTTP 來存取。解決這個不足目前有兩種方案，一是瀏覽器偏好設定 HSTS 域名列表，Google Chrome、Firefox、Internet Explorer 和 Microsoft Edge 實現了這一方案。二是將 HSTS 資訊加入到域名系統記錄中。但這需要保證 DNS 的安全性，也就是需要部署域名系統安全擴充。截至 2016 年這一方案沒有大規模部署。

由於 HSTS 會在一定時間後失效（有效期由 max-age 指定），所以瀏覽器是否強制 HSTS 策略取決於當前系統時間。部分作業系統經常通過網路時間協定更新系統時間，如 Ubuntu 每次連接網路時、OS X Lion 每隔 9 分鐘會自動連接時間伺服器。攻擊者可以通過偽造 NTP 資訊，設定錯誤時間來繞過 HSTS。解決方法是認證 NTP 資訊，或者禁止 NTP 大幅度增減時間。比如 Windows 8 每 7 天更新一次時間，並且要求每次 NTP 設定的時間與當前時間不得超過 15 小時。

## 瀏覽器支援

* Chromium 和 Google Chrome 從 4.0.211.0 版本開始支援 HSTS
* Firefox 4 及以上版本
* Opera 12 及以上版本
* Safari 從 OS X Mavericks 起
* Internet Explorer 和 Microsoft Edge 從 Windows 10 開始支援

## 網站支援

根據 SSL Pulse 的調查，截至 2015 年 2 月，僅有 2.7% 的網站開啟了 HSTS。目前支援 HSTS 的主流網站有：支付寶、PayPal、Twitter、維基百科郵寄清單等。

## 參見

* 超文字傳輸安全協定
* 傳輸層安全協定
* 中間人攻擊
* HTTP 公鑰固定

## 參考文獻

## 外部連結

* （英文）RFC 6797, HTTP Strict Transport Security (HSTS)（頁面存檔備份，存於網際網路檔案館）
* （英文）IETF WebSec Working Group（頁面存檔備份，存於網際網路檔案館）（網際網路工程任務組中的 WebSec 工作小組首頁）
* （英文）Security Now 262: Strict Transport Security（頁面存檔備份，存於網際網路檔案館）（HSTS 影片講解）
* （英文）Open Web Application Security Project (OWASP): HSTS description（OWASP 上的 HSTS 條目）
* （英文）Online browser HSTS and Public Key Pinning test（頁面存檔備份，存於網際網路檔案館）（瀏覽器支援測試）
* （英文）HSTS Preload Submission（頁面存檔備份，存於網際網路檔案館）（提交網站至主流瀏覽器的 HSTS 偏好設定列表）
* （中文）Linux 開啟 HSTS 安全機制 （頁面存檔備份，存於網際網路檔案館）
HTTP_header

**HTTP 頭欄位**（英語：HTTP header fields）是指在超文字傳輸協定（HTTP）的請求和回應訊息中的訊息頭部分。它們定義了一個超文字傳輸協定事務中的操作參數。HTTP 頭部欄位可以自己根據需要定義，因此可能在 Web 伺服器和瀏覽器上發現非標準的頭欄位。

## 基本格式

協定頭的欄位，是在請求（request）或回應（response）行（一條訊息的第一行內容）之後傳輸的。協定頭的欄位是以明文的字串格式傳輸，是以冒號分隔的鍵名與鍵值對，以 Enter (CR) 加換行 (LF) 符號序列結尾。協定頭部分的結尾以一個空白欄位標識，結果就是，也就是傳輸兩個連續的 CR+LF。在歷史上，很長的行曾經可能以多個短行的形式傳輸；在下一行的開頭，輸出一個空格 (SP) 或者一個水平制表符 (HT)，表示它是一個後續行。在如今，這種換行形式已經被廢棄。

## 類型

HTTP 頭欄位根據實際用途被分為以下 4 種類型：

* 通用頭欄位 (英語：General Header Fields)
* 請求頭欄位 (英語：Request Header Fields)
* 回應頭欄位 (英語：Response Header Fields)
* 實體頭欄位 (英語：Entity Header Fields)

## 欄位名

在 RFC 7230、RFC 7231、RFC 7232、RFC 7233、RFC 7234 和 RFC 7235 中，對一組核心欄位進行了標準化。有一份對於這些欄位的官方的登記冊，以及 一系列的補充規範 ，由網際網路號碼分配局（IANA）維護。各個應用程式也可以自行定義額外的欄位名字及相應的值。頭欄位的永久登記表（頁面存檔備份，存於網際網路檔案館）和臨時登記表（頁面存檔備份，存於網際網路檔案館）目前由 IANA 維護。其他的欄位名稱和允許的值可以由各應用程式定義。

按照慣例，非標準的協定頭欄位是在欄位名稱前加上 `X-` 字首來標識。但這一慣例已在 2012 年 6 月被廢棄，因為按照這種慣例，非標準欄位變成標準欄位時會引起很多不方便之處。以前曾經有的使用 `Downgraded-` 的限制也在 2013 年 3 月被解除。。

## 欄位值

某些欄位中可以包含注釋內容（例如 User-Agent、Server 和 Via 欄位中)，這些注釋內容可由應用程式忽略。

很多欄位的值中可以包含帶有權重的品質（quality，常被簡稱為 Q）的鍵值對，指定的「重量」會在內容協商的過程中使用。

## 大小限制

標準中沒有對每個協定頭欄位的名稱和值的大小設定任何限制，也沒有限制欄位的個數。然而，出於實際場景及安全性的考慮，大部分的伺服器、客戶端和代理軟體都會實施一些限制。例如，Apache 2.3 伺服器在預設情況下限制每個欄位的大小不得超過 8190 位元組，同時，單個請求中最多有 100 個頭欄位。

## 請求欄位

### 常見的非標準請求欄位

## 回應欄位

### 常見的非標準回應欄位

## 參見

* cookie

## 參考文獻

## 外部連結

* Headers: Permanent Message Header Field Names（頁面存檔備份，存於網際網路檔案館）
* RFC 6638: 廢除給非標準參數加上字首 X-
* RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
* RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
* RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
* RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
* RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
* RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication
* RFC 2965: IETF HTTP State Management Mechanism RFC
* HTTP/1.1 headers from a web server point of view
* HTTP Request Header Viewer
* HTTP Response Header Viewer（頁面存檔備份，存於網際網路檔案館） - Retrieves the HTTP response headers of any domain.
* Internet Explorer and Custom HTTP Headers - EricLaw's IEInternals - Site Home - MSDN Blogs（頁面存檔備份，存於網際網路檔案館）
* crwlr.net - HTTP Header index
* HTTP Header with Privacyinfo - Display your HTTP request and response headers
HTTP_referer

**HTTP 參照位址**（**referer**，或 **HTTP referer**）是 HTTP 表頭的一個欄位，用來表示從哪兒連結到目前的網頁，採用的格式是 URL。換句話說，藉著 HTTP 參照位址，目前的網頁可以檢查訪客從哪裡而來，這也常被用來對付偽造的跨網站請求。

而 _dereferer_ 則是將 HTTP 參照位址資訊剝離，所以網站將無法識別訪客從何而來。

## 拼寫問題

_Referer_ 的正確英語拼法是 **referrer**。這是早期 HTTP 規範當中存在的拼寫錯誤，後來為保持向下相容將錯就錯。例如 DOM Level 2、Referrer Policy 等其他網路技術的規範曾試圖修正此問題，使用正確拼法，導致目前拼法並不統一。

## 概念與功能

當訪客存取網頁時，HTTP 參照位址（**referer** 或 **referring page）** 是前一個網頁的 URL。如果是圖片的話，通常指的就是圖片所在的網頁。在網頁瀏覽器送往網頁伺服器的時候，HTTP 參照位址就被包含在 HTTP 請求方法中。

網站會將參照位址記錄以便追蹤使用者的動態或進行統計，大部分分析軟體也都會處理這個資訊。但因參照位址資訊可能會帶來隱私權問題，不少網頁瀏覽器允許使用者設定不要送出這個資訊，有些代理伺服器和防火牆也會將參照位址資訊過濾掉，以避免外部獲知非公開的網路位址。缺少參照位址資訊有可能會造成某些使用問題：某些伺服器會因為缺少正確的參照位址資訊而進行阻擋，以避免未經授權的圖片參照（圖像防盜鏈）或是其他對伺服器有影響的行為。針對這樣的阻擋，有些軟體還提供了針對特定網站送出假來源位址的功能（反防盜鏈）。

## 如何取得 HTTP 參照位址

**ASP.NET（C#）**

**ASP**

**PHP**

**JAVA**

**GO**

**Python**

## 參考與外部連結

* RFC 2616: Hypertext Transfer Protocol – HTTP/1.1
* IRI – Internationalized Resource Identifiers

## 參考資料
HTTP公钥固定

**HTTP 公鑰固定**（又稱 **HTTP 公鑰釘扎**，英語：HTTP Public Key Pinning，縮寫 **HPKP**）是 HTTPS 網站防止攻擊者利用數位憑證認證機構（CA）錯誤簽發的憑證進行中間人攻擊的一種安全機制，用於預防 CA 遭受入侵或其他會造成 CA 簽發未授權憑證的情況。採用公鑰固定時，網站會提供已授權公鑰的雜湊列表，指示客戶端在後續通訊中只接受列表上的公鑰。

## 工作原理

伺服器通過 `Public-Key-Pins`（或 `Public-Key-Pins-Report-Only` 用於監測）HTTP 頭向瀏覽器傳遞 HTTP 公鑰固定資訊。

HTTP 公鑰固定將網站 X.509 憑證鏈中的一個 SPKI（和至少一個備用金鑰）以 `pin-sha256` 方式進行雜湊，由參數 `max-age`（單位秒）所指定一段時間，可選參數 `includeSubDomains` 決定是否包含所有子域名，另一個可選參數 `report-uri` 決定是否回報違反 HTTP 公鑰固定策略的事例。在 `max-age` 所指定的時間內，憑證鏈中憑證的至少一個公鑰須和固定公鑰相符，這樣客戶端才認為該憑證鏈是有效的。

RFC 7469 規範發布時只允許 SHA-256 演算法。HTTP 公鑰固定中的雜湊演算法也可通過 RFC 7469 規範的附錄 A 中所提到的命令列或其他第三方工具來生成。

網站維護者可以選擇將特定 CA 根憑證公鑰固定 —— 只有該 CA 和其簽發的中階憑證才視同有效，而且可以選擇將一個或多個中階憑證固定，或將末端憑證固定。但是，至少得固定一個備用金鑰以便更換現有的固定金鑰。在沒有備用金鑰（備用金鑰須不在現有憑證鏈中）時，HTTP 公鑰固定並不會生效。

HTTP 公鑰固定在 RFC 7469 規範中成為標準。把憑證公鑰的雜湊值寫死在客戶端、瀏覽器中，這被稱為「憑證固定」，HTTP 公鑰固定則是「憑證固定」的一種擴充。

Chromium 瀏覽器現已經禁止固定自簽章根憑證的憑證鏈，這樣一些內容嗅探、抓包軟體如 mitmproxy、Fiddler 便無法再利用自簽憑證嗅探加密內容。RFC 7469 規範指出，對於此類憑證鏈，建議禁用 HTTP 公鑰固定的違規回報。

## 違規回報

客戶端進行 HTTP 公鑰固定驗證失敗後，將把此次錯誤詳情以 JSON 格式回報給 `report-uri` 參數中指定的伺服器。若發生客戶端向同域名的伺服器端回報失敗（如違規本身就是由連接問題引起的），伺服器端也可指定另一個域名或採用其他回報服務。

## 瀏覽器支援

Firefox 從版本 35.0 開始支援 HPKP，Chrome 從版本 46 開始支援，但在 Chrome 67 中終止了對 HPKP 的支援
。Internet Explorer、Microsoft Edge 目前尚不支援 HPKP。

## 應用現狀

2016 年，Netcraft 在有關 SSL 的調研中稱，只有 0.09% 的憑證在使用 HTTP 公鑰固定，加上實際運作中不當的組態，實際有效的 HTTP 公鑰固定憑證數量低於 3000。造成這種現象的原因是：該技術尚處於萌芽期，網站技術人員對其缺乏重視和理解，更重要的是，錯誤的部署可能帶來網站方面無法接受的嚴重後果 —— 使用者在相當長一段時間內（取決於 `max-age` 的組態）因新憑證公鑰與舊 HPKP 策略不符，對網站的合法訪問都將遭拒。

因為網站部署率過低，Google 在 2018 年 5 月 29 日發布的 Chrome 67 中終止了對 HPKP 的支援。

由 Google 所主導的 Certificate Transparency 提供了一個用於監測、稽核憑證的開放式框架，以保障憑證簽發流程的安全。這是一項和 HTTP 公鑰固定有著相同目標的較新專案。

## 參見

* 中間人攻擊
* HTTP 嚴格傳輸安全（HTTP Strict Transport Security，HSTS）
* RFC 7469

## 參考資料

## 外部連結

* 在 Apache、nginx、Lighttpd 上啟用 HPKP（頁面存檔備份，存於網際網路檔案館）
* 安全網站為何對 HPKP 敬而遠之？（頁面存檔備份，存於網際網路檔案館）
* Certificate Transparency 專案網站（頁面存檔備份，存於網際網路檔案館）
HTTP基本认证

在 HTTP 中，**基本認證**（英語：Basic access authentication）是允許 http 使用者代理（如：網頁瀏覽器）在請求時，提供 使用者名稱 和 口令 的一種方式。

在進行基本認證的過程里，請求的 HTTP 頭欄位會包含 `Authorization` 欄位，形式如下： `Authorization: Basic <凭证>`，該憑證是使用者和口令的組和的 base64 編碼。

最初，基本認證是定義在 HTTP 1.0 規範（RFC 1945）中，後續的有關安全的資訊可以在 HTTP 1.1 規範（RFC 2616）和 HTTP 認證規範（RFC 2617）中找到。於 1999 年 RFC 2617 過期，於 2015 年的 RFC 7617 重新被定義。

在 MDN 網站，已經有對應的維基文章。

## 優點

HTTP 基本認證 是一種十分簡單的技術，使用的是 HTTP 頭部欄位 強制使用者存取網路資源，而不是通過必要的 cookie、對談 ID、登入頁面等（非取得存取控制的）手段。

基本上所有流行的網頁瀏覽器都支援基本認證。基本認證很少在可公開存取的網際網路網站上使用，有時候會在小型私有系統中使用（如路由器網頁管理介面）。之後誕生的 HTTP 摘要認證 用於替代基本認證，允許金鑰以相對安全的方式在不安全的通道上傳輸。

程式設計師和系統管理員有時會在可信網路環境中使用基本認證。由於，基本認證使用的是 Base64，可解碼成明文，因此使用 Telnet 等網路協定工具進行監視時，可以直接取得內容，並用於診斷。

## 缺點

基本認證 並沒有為傳送憑證（英語：transmitted credentials）提供任何機密性的保護。僅僅使用 Base64 編碼並傳輸，而沒有使用任何 加密 或 雜湊演算法。因此，基本認證常常和 HTTPS 一起使用，以提供機密性。

現存的瀏覽器儲存認證資訊直到分頁或瀏覽器被關閉，或者使用者清除歷史記錄。HTTP 沒有為伺服器提供一種方法指示客戶端丟棄這些被快取的金鑰。這意味著伺服器端在使用者不關閉瀏覽器的情況下，並沒有一種有效的方法來讓使用者登出。

同時 HTTP 並沒有提供登出機制。但是，在一些瀏覽器上，存在清除憑證（credentials ）快取的方法。

## 原理

### 文字過程

這一個典型的 HTTP 客戶端和 HTTP 伺服器的對話，伺服器安裝在同一台電腦上（localhost），包含以下步驟：

1. 客戶端請求一個需要身分認證的頁面，但是沒有提供使用者名稱和口令。這通常是使用者在網址列輸入一個 URL，或是打開了一個指向該頁面的連結。
2. 伺服器端回應一個 401 應答碼，並提供一個認證域（英語：Access Authentication），頭部欄位為：`WWW-Authenticate`，該欄位為要求客戶端提供適配的資源。 `WWW-Authenticate: Basic realm="Secure Area"` 該例子，`Basic` 為驗證的模式，`realm="Secure Area"` 為保護域，用於與其他請求 URI 作區別。
3. 接到應答後，客戶端顯示該認證域給使用者並提示輸入使用者名稱和口令。此時使用者可以選擇確定或取消。
4. 使用者輸入了使用者名稱和口令後，客戶端軟體將對其進行處理，並在原先的請求上增加認證訊息頭（英語：Authorization）然後重新傳送再次嘗試。過程如下：
  1. 將使用者名稱和口令拼接為 `用户：密码` 形式的字串。
  2. 如果伺服器 `WWW-Authenticate` 欄位有指定編碼，則將字串編譯成對應的編碼（如：UTF-8）。
  3. 將字串編碼為 base64。
  4. 拼接 `Basic` ，放入 `Authorization` 頭欄位，就像這樣：`Authorization Basic 字符串`。 範例：使用者名稱：`Aladdin` ，口令：`OpenSesame` ，拼接後為 `Aladdin:OpenSesame`，編碼後 `QWxhZGRpbjpPcGVuU2VzYW1l`，在 HTTP 頭部里會是這樣：`Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l`。 Base64 編碼並非加密演算法，其無法保證安全與隱私，僅用於將使用者名稱和口令中的不相容的字元轉換為均與 HTTP 協定相容的字元集。
5. 在本例中，伺服器接受了該認證螢幕並返回了頁面。如果使用者憑據非法或無效，伺服器可能再次返回 401 應答碼，客戶端可以再次提示使用者輸入口令。

**注意:**客戶端有可能不需要使用者互動，在第一次請求中就傳送認證訊息頭。

### 電文過程

#### 1. 客戶端請求（沒有認證資訊）

（跟隨一個換行，以 Enter（CR）加換行（LF）的形式）

#### 2. 伺服器端應答

#### 3. 客戶端請求（有認證資訊）

使用者名稱「Aladdin」，口令 「open sesame」

（跟隨一個空行，如上所述）

Authorization 訊息頭的使用者名稱和口令的值可以容易地編碼和解碼。

#### 4. 伺服器端的應答

（跟隨一個空行，隨後是需憑據頁的 HTML 文字）。

## 參考文獻和注釋

## 參見

* HTTP 摘要認證

## 外部連結

* RFC2617: HTTP Authentication: Basic and Digest Access Authentication（頁面存檔備份，存於網際網路檔案館）
HTTP快取

**Web 快取**（或 **HTTP 快取**）是用於臨時儲存（快取）Web 文件（如 HTML 頁面和圖像），以減少伺服器延遲的一種資訊科技。Web 快取系統會儲存下通過這套系統的文件的副本；如果滿足某些條件，則可以由快取滿足後續請求。 Web 快取系統既可以指裝置，也可以指電腦程式。

## 系統

Web 快取可以用於各種系統（從 Web 內容的傳輸方向來看）：

### 前向位置系統（接受者或客戶端）

前向快取是 Web 伺服器網路外部的快取，例如在客戶電腦、ISP 或公司網路上。 網路感知前向快取就像一個前向快取，但只快取大量存取的專案。 客戶端（如網頁瀏覽器）也可以儲存網路內容以供重用。例如，如果按下後退按鈕，則可以顯示本地快取版本的頁面，而不是傳送到 Web 伺服器的新請求。位於客戶端和伺服器之間的 Web 代理可以通過評估 HTTP 頭來選擇是否儲存網頁內容。

### 反向位置系統（內容提供者或 Web 伺服器端）

反向快取位於一個或多個 Web 伺服器和 Web 應用的前端，加速來自網際網路的請求， 從而減少 Web 伺服器的高峰負載。內容傳遞網路（CDN）可以在整個網路的各個點上保留網頁內容的副本。搜尋引擎也可能會快取一個網站；它提供了一種從最近停機的網站檢索資訊的方法，或者比點擊直接連結更快地檢索資料的方式。例如，Google 就是這麼做的。Google 搜尋結果中可以找到快取內容的連結。

## 快取控制

HTTP 定義了三種控制快取的基本機制：新鮮度，驗證和失效。

**新鮮度**
: 允許在不在源伺服器上重新檢查的情況下使用一個回應，並且可以由伺服器和客戶端來控制。例如，Expires 回應頭給出文件過期的日期，而 Cache-Control: max-age 指示告訴快取該回應在多少秒內保持新鮮。

**驗證**
: 可用於檢查快取的回應是否過時之後仍然有效。例如，若回應有一個 Last-Modified 頭，快取可以使用 If-Modified-Since 頭來發出一個條件請求，來檢視它是否已經改變。ETag（實體標籤）機制還允許強弱驗證。

**失效**
: 通常是另一個請求通過快取的一個結果。例如，如果與快取的回應關聯的 URL 隨後獲得 POST、PUT 或 DELETE 請求，則快取的回應將失效。

許多 CDN 和網路裝置製造商已經用動態快取取代了這個標準的 HTTP 快取控制。

## 法律問題

1998 年，數字千年著作權法增加了美國法典（17 U.S.C. §: 512）的規定，放棄追究以快取為目的的系統運營商的著作權責任。

## Web 快取軟體

以下是專門的 Web 快取伺服器軟體列表：

## 參見

* 內容傳遞網路（CDN）
* 代理伺服器
* 網路加速器

## 注釋

## 延伸閱讀

* Ari Luotonen, _Web Proxy Servers_ (Prentice Hall, 1997) ISBN 0-13-680612-0
* Duane Wessels, _Web Caching_ (O'Reilly and Associates, 2001). ISBN 1-56592-536-X
* Michael Rabinovich and Oliver Spatschak, _Web Caching and Replication_ (Addison Wesley, 2001). ISBN 0-201-61570-3

## 外部連結

* Caching Tutorial for Web Authors and Webmasters
* Web Caching and Content Delivery Resources
* Web Caching （頁面存檔備份，存於網際網路檔案館）, Web caching in general with some references to SQUID
HTTP报文主体

**HTTP 報文主體**是在 HTTP 頭欄位之後（如果存在頭欄位）所傳輸的資料（在 HTTP/0.9 中，不傳送頭欄位）。

## HTTP 報文

請求 / 回應報文由以下內容組成：

* 請求行，例如：GET /logo.gif HTTP/1.1 或狀態碼行，例如：HTTP/1.1 200 OK，
* HTTP 頭欄位
* 空行
* 可選的 HTTP 報文主體資料

請求 / 狀態行和標題必須以 <CR> <LF> 結尾（即 Enter 後跟一個換行符）。 空行必須只包含 <CR> <LF>，而不能包含其他空格。

此條目即闡述了「可選的 HTTP 報文主體資料」。

## 回應樣例

這是一個網路伺服器的回應樣例:

## 參見

* HTTP
* HTTP 壓縮
* HTTP 頭欄位
* HTTP 狀態碼
* Web 快取
HTTP持久连接

**HTTP 持久連接**（英語：**HTTP persistent connection**，也稱作 **HTTP keep-alive** 或 **HTTP connection reuse**）是使用同一個 TCP 連接來傳送和接收多個 HTTP 請求 / 應答，而不是為每一個新的請求 / 應答打開新的連接的方法。

## 操作

在 HTTP 1.0 中，沒有官方的 keepalive 操作。通常是在現有協定上添加一個指數。如果瀏覽器支援 keep-alive，它會在請求的包頭中添加：

```
Connection: Keep-Alive
```

然後當伺服器收到請求，作出回應的時候，它也添加一個頭在回應中：

```
Connection: Keep-Alive
```

這樣做，連接就不會中斷，而是保持連接。當客戶端傳送另一個請求時，它會使用同一個連接。這一直繼續到客戶端或伺服器端認為對談已經結束，其中一方中斷連接。

在 HTTP 1.1 中所有的連接預設都是持續連接，除非特殊聲明不支援。 HTTP 持久連接不使用獨立的 keepalive 資訊，而是僅僅允許多個請求使用單個連接。然而，Apache 2.0 httpd 的預設連接過期時間僅有 15 秒 ，Apache 2.2 僅有 5 秒。 短的過期時間的優點是能夠快速的傳輸多個 web 頁組件，而不會繫結多個伺服器行程或執行緒太長時間。

## 優勢

* 較少的 CPU 和記憶體的使用（由於同時打開的連接的減少了）
* 允許請求和應答的 HTTP 管線
* 降低擁塞控制 （TCP 連接減少了）
* 減少了後續請求的延遲（無需再進行握手）
* 報告錯誤無需關閉 TCP 連接

根據 RFC 2616 （47 頁），使用者客戶端與任何伺服器和代理伺服器之間不應該維持超過 2 個連結。代理伺服器應該最多使用 2×N 個持久連接到其他伺服器或代理伺服器，其中 N 是同時活躍的使用者數。這個指引旨在提高 HTTP 回應時間並避免阻塞。

## 劣勢

對於現在的廣泛普及的寬頻連接來說，Keep-Alive 也許並不像以前一樣有用。web 伺服器會保持連接若干秒（Apache 中預設 15 秒），這與提高的效能相比也許會影響效能。

對於單個檔案被不斷請求的服務（例如圖片存放網站），Keep-Alive 可能會極大的影響效能，因為它在檔案被請求之後還保持了不必要的連接很長時間。

## Web 瀏覽器中的使用

網景領航員（4.05 版本以後）和 Internet Explorer（4.01 版本以後）支援使用持久連結連結 Web 伺服器和代理伺服器。

網景不使用過時時間來關閉持久連接。而是對所有空閒的持久連結進行排隊。當需要打開一個新的持久連結，但連接到不同的伺服器上時，瀏覽器使用最近最少使用演算法終止一個空閒的持久連結。

Internet Explorer 支援持久連結，IE 6 和 IE 7 預設使用 2 個持久連結，而 IE 8 預設使用 6 個持久連結。持久連結在不活躍 60 秒後過時，可以在 Windows 登錄檔中修改。

Mozilla Firefox 支援持久連結。可以客製化同時的持久連接的最大個數（每個伺服器，每個代理伺服器，總數）。連接在不活躍 300 秒（5 分鐘）後過時（組態中可以修改）。

Opera 4.0 版本開始支援持久連結。可以組態同時的持久連接的最大個數（每個伺服器，總數）。

## 參考文獻

## 外部連結

* RFC 2616 (HTTP/1.1), 8.1 Persistent Connections（頁面存檔備份，存於網際網路檔案館）
* Persistent Connection Behavior of Popular Browsers (dated)（頁面存檔備份，存於網際網路檔案館）
* Apache Keep-Alive Support（頁面存檔備份，存於網際網路檔案館）
HTTP服务器

**網頁伺服器**（英語：Web server）一詞有兩個意思：

1. 一台負責提供網頁的電腦，主要是各種程式語言構建而成，通過超文字傳輸協定（英語：HTTP）傳給客戶端（一般是指網頁瀏覽器）。
2. 一個提供網頁的伺服器程式。

每一台網頁伺服器（第 1 個意思）會執行最少一個網頁伺服器程式（第 2 個意思）。作為第 1 個意思，大陸地區稱為網站伺服器。此外，也通稱作 **Web 伺服器**。

## 常見軟體

現在市面上普遍的超文字傳輸協定伺服器有：

* Apache Software Foundation 的 Apache HTTP Server
* Microsoft Corporation 的 Internet Information Server (IIS)
* Google LLC（Alphabet Inc. 子公司）的 Google Web Server
* NGINX, Inc. （頁面存檔備份，存於網際網路檔案館）（已被 F5 Networks, Inc. 收購）的 NGINX
  * 淘寶網（隸屬於阿里巴巴集團）改良自 NGINX 的 Tengine
* lighttpd
* Cherokee
* Microsoft Corporation 的 FrontPage

## 一般功能

雖然每個網頁伺服器程式有很多不同，但有一些共同的特點：每一個網頁伺服器程式都需要從網路接受 HTTP 請求，然後提供 HTTP 回覆給請求者。HTTP 回覆一般包含一個 HTML 檔案，有時也可以包含純文字檔案、圖像或其他類型的檔案。

一般來說這些檔案都儲存在網頁伺服器的本地檔案系統裡，而 URL 和本地檔名都有一個階級組織結構的，伺服器會簡單的把 URL 對照到本地檔案系統中。當正確安裝和設定好網頁伺服器軟體，伺服器管理員會從伺服器軟體放置檔案的地方指定一個本地路徑名為根目錄。

例如，在「example.funnycorp.com」伺服器上設定了伺服器軟體，並把伺服器軟體的根目錄設定為「/home/public/web/」，當一個瀏覽者輸入 URL 「http://example.funnycorp.com/lips/raspberry.html」，「example.funnycorp.com」上的伺服器軟體就會讀取「/home/public/web/lips/raspberry.html」這個檔案。

## 市場佔有率

### 2017 年 10 月

以下是由 W3Techs 提供最新的網頁伺服器在網路上的市場佔有率統計數據：

只有不到 1% 的網站使用其它網頁伺服器。

### 2016 年 9 月

以下是由 Netcraft 公司提供的網頁伺服器市場佔有率統計數據：

Apache、IIS 和 Nginx 的是網際網路上最常用的 Web 伺服器。

## 參考文獻

## 外部連結

* 最新的網頁伺服器統計可在這個網址中找到：Netcraft 網頁伺服器調查 （頁面存檔備份，存於網際網路檔案館）（英文）

## 參見

* 虛擬主機
* 網頁伺服器比較
* 應用程式伺服器
*
HTTP流水线

**HTTP 管線**（英語：HTTP pipelining）是將多個 HTTP 請求（request）整批送出的技術，而在傳送過程中不需先等待伺服器的回應。

請求結果管線使得 HTML 網頁載入時間動態提升，特別是在具體有高延遲的連接環境下，如衛星上網。在寬頻連接中，加速不是那麼顯著的，因為需要伺服器端要遵循 HTTP/1.1 協定，必須按照客戶端傳送的請求順序來回覆請求，這樣整個連接還是先進先出的，隊頭阻塞（HOL blocking）可能會發生，造成延遲。未來的 HTTP/2.0 或者 SPDY 中的異步操作將會解決這個問題。因為它可能將多個 HTTP 請求填充在一個 TCP 數據包內，HTTP 管線需要在網路上傳輸較少的 TCP 數據包，減少了網路負載。

管線機制須透過永久連線（persistent connection）完成，並且只有 GET 和 HEAD 等要求可以進行管線，非冪等的方法，例如 POST 將不會被管線化。連續的 GET 和 HEAD 請求總可以管線化的。一個連續的冪等請求，如 GET，HEAD，PUT，DELETE，是否可以被管線化取決於一連串請求是否依賴於其他的。此外，初次建立連線時也不應啟動管線機制，因為對方（伺服器）不一定支援 HTTP/1.1 版本的協定。

HTTP 管線化同時依賴於客戶端和伺服器的支援。遵守 HTTP/1.1 的伺服器支援管線化。這並不是意味著伺服器需要提供管線化的回覆，而只是要求在收到管線化的請求時候不會失敗。

## 實作

### 實作在網頁伺服器

### 實作在瀏覽器
HTTP隧道

**HTTP 隧道**用於在被限制的網絡連接（包括防火牆、NAT 和 ACL）以及其他限制的情況下在兩台計算機之間建立網絡連結。該隧道通常由位於 DMZ 中的代理伺服器中介創建。

隧道還可以使用受限網絡通常不支持的協議進行通信。

## HTTP CONNECT 方式

HTTP 隧道的常見形式是標準 HTTP CONNECT 方式。在這種機制下，客戶端要求 HTTP 代理伺服器將 TCP 連接轉發到所需的目的地。然後伺服器繼續代表客戶端進行連接。伺服器建立連接後，代理伺服器將繼續代理與客戶端之間的 TCP 流。只有初始連接請求是 HTTP，之後伺服器將僅代理建立的 TCP 連接。

正是這種機制讓使用 HTTP 代理的客戶端可以訪問 TLS 網站（即 HTTPS）。

### 建立隧道示例

客戶端連接到代理伺服器，並通過指定埠和要連接的主機建立隧道。 該埠用於指示請求的協議。

如果代理允許連接，並且代理已連接到指定的主機，則代理將返回 2XX 成功響應。

現在客戶端將通過代理訪問遠程主機。 發送到代理伺服器的所有數據都將原樣轉發到遠程主機，並且客戶端可以使用遠程主機支持的任何協議進行通信。

在下面的示例中，客戶端在初始 CONNECT 請求中通過埠號開始 SSH 通信。

```
SSH-2.0-OpenSSH_4.3\r\n
... ggg
```

## 不使用 CONNECT 的 HTTP 隧道

HTTP 隧道也可以僅使用常用的 HTTP 請求方法（如 POST，GET，PUT 和 DELETE）來實現。這類似於同步 HTTP 上的雙向流（BOSH）中使用的方法。

如示例程序，特殊的 HTTP 伺服器在受保護的網絡外部運行，而客戶端程序在受保護的網絡內部的計算機上運行。

當客戶端發送任何網絡流量時，客戶端都會將流量數據重新打包為 HTTP 請求，並將數據發送到外部伺服器，該外部伺服器會提取並執行客戶端的原始網絡請求。

外部伺服器收到此請求的響應後，將其重新打包為 HTTP 響應，並發送回客戶端。

由於所有流量都封裝在常規的 GET 和 POST 請求和響應中，因此該方法適用於大多數代理、防火牆及內網。

## 另見

* ICMP tunnel
* Pseudo-wire
* Tunnel broker
* Virtual private network (VPN)
* Virtual extensible LAN
* Network virtualization using generic routing encapsulation

## 參考文獻
HTTrack

**HTTrack** 是一個自由、開源的網路爬蟲以及離線瀏覽器。它的作者是澤維爾・羅奇（Xavier Roche），在 GNU 通用公眾授權條款（GPL）下釋出。

使用者可以通過 HTTrack 把網際網路上的網站頁面下載到本地電腦上。在預設設定下，HTTrack 對網站頁面的下載結果是按照原始站點相對連結的結構來組織的。用網頁瀏覽器打開這個被下載下來的網站（也稱作鏡像）的頁面，就可以離線瀏覽了。

HTTrack 也能對已經鏡像過的站點進行更新。或者是對中斷了的工作斷點續傳。可以通過選項和過濾器（include/exclude）組態 HTTrack 的方方面面。它還整合有幫助系統。它有一個基本的命令列版本和兩個 GUI（為 Windows 設計的 WinHTTrack 和為 Unix-like 系統設計的 WebHTTrack）；命令列版本可以和 Shell 指令碼（Shell script）以及 cron 聯用。

HTTrack 使用網路爬蟲下載網站。對於有 robots.txt 的網站，如果不在程式執行時取消限制，預設設定下的程式不會把網站完全鏡像。HTTrack 能跟隨基本的 JavaScript，或者 Applet、Flash 中的連結，但是對於複雜的連結（使用函式和表達式建立的連結）或者伺服器端的 Image Map 則無能為力。

## 安裝與使用

在許多 Unix-like 系統下，只需要用包管理工具安裝 httrack 即可。例如 Debian 使用

> 
>  sudo aptitude install httrack
> 
> 

一個使用例子：

> 
> 
>  httrack "http://www.all.net/" -O "/tmp/www.all.net" "+\*.all.net/\*" -v
> 
> 

它的意思是：以 http://www.all.net/ 为起始 URL，输出到 /tmp/www.all.net 文件夹，范围是 www.all.net 域名下的所有文件，并显示所有错误信息（verbose）。更詳細的資訊請看官網上的 Users Guide。

## 參見

* robots.txt
* 離線瀏覽
* 砍站

## 註腳

## 外部連結

* 官方網站
HTV

**HTV** 可以指：

* 八戶電視（Hachinohe Cable Television）：日本青森縣的一家有線電視公司。
* Harlech 電視（Harlech Television）：英國獨立電視台在威爾斯與西英格蘭的分台。
* 赫斯特電視（Hearst Television）：赫斯特國際集團旗下的一家美國電視台。
* H-II 運載飛船（H-II Transfer Vehicle）：日本的一型無人貨運飛船。
* 廣島電視台（Hiroshima Telecasting）：日本廣島縣的一家電視台。
* 西班牙裔電視台（Hispanic Television）：特納廣播公司旗下的一個拉丁美洲有線電視頻道。
* 胡志明市電視台（Ho Chi Minh City Television）：越南胡志明市的一家電視台。
* 杭州電視台（Hangzhou Television）：中國大陸浙江省杭州市公營電視台。
HTV-X

**新型太空站補給機**（日語：新型宇宙ステーション補給機），又稱「**HTV-X 貨運飛船**」，是日本宇宙航空研究開發機構（JAXA）正在設計和研發中的一型無人貨運飛船。計劃將用於取代其前身「**HTV 貨運飛船**」，向國際太空站定期補給必要的維持物資以及器材。

## 參考文獻
HTV-X货运飞船

**新型太空站補給機**（日語：新型宇宙ステーション補給機），又稱「**HTV-X 貨運飛船**」，是日本宇宙航空研究開發機構（JAXA）正在設計和研發中的一型無人貨運飛船。計劃將用於取代其前身「**HTV 貨運飛船**」，向國際太空站定期補給必要的維持物資以及器材。

## 參考文獻
HTV_Award

**HTV Award（**其他名字：**Giải thưởng truyền hình HTV**）是 2006 年發起並自 2007 年開始舉辦的年度獎項，該獎項由胡志明市電視台發起和組織，旨在表彰屬於胡志明市的藝術家。領域：電影、戲劇和音樂是今年 HTV 觀眾最喜歡的領域。每個類別將包括 5 名候選人，由觀眾決定哪些藝術家將在頒獎晚會上獲得榮譽，頒獎晚會在 HTV 上通過撰寫留言或在網站上在線投票的方式隆重而隆重地舉行。

頒獎典禮通常在三月至五月舉行。第 10 屆頒獎典禮於 2016 年 4 月 23 日在 Phan Dinh Phung 體育館舉行。大約前 5 季，頒獎典禮在胡志明市電視劇院舉行，從第 6 季開始，頒獎典禮在 Phan Dinh Phung 體育館舉行。

## 參考文獻
HTV货运飞船

**H-II 運輸載具**（H-II Transfer Vehicle，**HTV**）也稱為白鸛號（KOUNOTORI），是一艘用來補給國際太空站的無人太空船。日本宇宙航空研究開發機構（JAXA）自 1990 年代初期即斷斷續續的設計和建造 HTV；最先預定於 2001 年首次發射使用，後延後至 2009 年 9 月發射。至後、日本已於日本時間 2009 年 9 月 11 日凌晨 2 時 1 分，由種子島宇宙中心發射 HTV 補給船，搭載於日本最新型 H-IIB 運載火箭一號機上，前往國際太空站進行運補物資任務。

此外，在二號機發射前，JAXA 進行了名稱公募活動，最後於 2010 年 11 月 11 日發表結果，系列名稱定名為「白鸛」（こうのとり，KOUNOTORI，日本傳說中的幸運之鳥）

## 尺寸

HTV 太空船長度約 10 公尺，直徑 4.4 公尺，最大重量 16.5 公噸，比俄國進步號太空船長度 7.23 公尺，直徑 2.72 公尺，最大重量 7.2 噸；HTV 的巨大酬載量達 6 公噸，是進步號酬載量的 2 倍以上。

## 運作過程

HTV 太空船主要用於向國際太空站供應大型實驗設備與裝置也能進行食物、水的補給。本身具有 28 具姿態調整火箭引擎與 4 具軌道修正主火箭引擎，與國際太空船會合對接是採用日本在 1997 年 ETS-7 技術實驗衛星演進而來的抓握對接技術，HTV 利用裝置在電器艙的「近傍通訊系統（proximity communication zone）」與「交會雷射雷達（Rendezvous laser radar）」來與國際太空站停泊、會合、對接的一系列動作。

白鸛號先被火箭送進 51.6 度傾角的低地軌道後，經過三次軌道變動提升高度，近傍通訊系統一進入國際太空站 23 公里範圍內，先跟希望號太空實驗室上建立通訊連結，接著透過「相對 GPS 航行（relative GPS navigation）­」導引飛行，沿著 V-BAR 航路，抵達國際太空站後方 5 公里的「接近起始點（Approach Initiation point）」，再以拋物線飛行軌道飛抵國際太空站下方 500 公尺的交會點（Rendezvous Insertion point），之後轉換成會合雷射雷達導引，藉由太空船上的交會雷射雷達發出雷射至希望號下方的「交會反射器（Rendezvous laser radar reflector）」導引太空船沿著 R-BAR 航路接近國際太空站，太空船飛抵預先決定的把持帶（Berthing Box /Capture Box）區域時，該處在接合處下方 10 公尺的位置，關閉所有主引擎與姿態調整引擎保持相對停止的「自由飄移狀態（free drift）」，讓加拿大機械臂捉住 HTV 太空船與國際太空站上的「共同接合結構（Commen Berthing Mechanism）」對接，正因為它省去了俄國 APAS 那種狹小直徑的對接裝置，直接透過口徑較大型的 CBM 接合，使得 HTV 太空船的接口是唯一可以運輸國際標準機架（International Standard Payload Rack）尺寸的太空船，具備通行大型艙內實驗裝置到國際太空站的艙室內以及具有非加壓艙運送艙外設備機器的能力。

2018 年 11 月 11 日，由白鸛 7 號首度搭載直徑 80 公分左右的回收囊，並成功將國際太空站上的科學實驗成果，成功送返地球。

## 結構設計

**加壓艙組**
: 放置食物、水等太空人生活用補給品以及大型艙內實驗設備，位於與太空站的對接處。除了 HTV，俄羅斯進步號與歐洲 ATV 也都有運輸物資到 ISS 上，但是 HTV 太空船採用日本獨自開發的會合對接技術，使用近傍通訊系統 PROX 與會合雷達來接近國際太空站，以保持 "相對停止" 方式進行對接。這使得 HTV 可以擁有較大口徑的對接口來停泊。

　
: HTV 接合口是 1.27 乘以 1.27 公尺大小的正方形，所以是唯一一個可讓國際太空站標準貨架通過，執行運輸在 ISS 內部加壓空間裡使用大型實驗設備酬載的太空船。至於歐洲 ATV 與俄羅斯聯盟 / 進步號則使用俄國 Hybrid docking system，會受限於接合口直徑只有 0.8 公尺，無法運輸大型實驗裝置。另外 HTV 加壓艙組也跟國際太空站一樣維持一大氣壓與攝氏 20 度 C 的溫度，國際太空站乘員可以在不穿太空衣下，直接進入加壓艙組內部搬運物資實驗設備。加壓艙模組也配備 12 具姿態調整用引擎。

**無加壓艙組**
: 放置國際太空站站外機械與希望號實驗平台使用儀器的區域，使用機械臂吊出放置。HTV 是當今唯一可以運送 ISS 艙外實驗裝置與機器組件的太空船。

**電氣艙**
: HTV 無加壓艙組的後部是容納航行電子的電氣艙是 HTV 的大腦。電器艙由導航控制、通訊、資料處理與電力供應四個子系統組成。這些子系統支持 HTV 太空船自動與遠距離會合飛行，被 H2B 火箭送進軌道後，HTV 使用相對 GPS 航行系統與會合雷射雷達來接近 ISS，太空船會在一預先決定的區域停止，該區域又稱為 "Berthing Box"，也就是在接合處下方 10 公尺的位置，然後加拿大機械臂將捉住它與 ISS 接合。電器艙也分配由 HTV 機身上的太陽能板產生的電力或電池電力給 HTV 其他艙組使用。

**推進艙組**
: 推進艙組配備有 4 具軌道變動的主引擎與 16 具姿態調整用引擎，在每次飛行任務時推進艙組可以攜帶 2.4 噸燃料；而在控制軌道高度提升與會合機動變軌時所需的火箭引擎燃料將由電器艙組發布指令控制。

**近傍通訊系統（Proximity Communication System / PROX）：**

三菱電機開發、安裝於希望號太空實驗室，由 "PROX 天線"、"PROX-GPS 天線"、"PROX 溝通設備（PROX communication equipment）" 與 "硬體指令面板（Hardware Command Panel / HCP）" 構成；當太空船在 V-BAR 與拋物線軌道飛至太空站下方時的導引稱為『相對 GPS 航行（Relative GPS navigation）』。

**會合雷射雷達與反射器（Rendezvous laser radar & reflector）：**

發出雷射光的傳感器安裝在太空船上，接收會合雷射的反射器則安裝於希望號加壓模組的下方，當太空船從 R-BAR 接近太空站時使用，此階段的導引又稱為『會合雷射航行（Rendezvous Sensor navigation）』。

## 發射結果

## 注釋

## 參考文獻

## 外部連結

* Project overview of H-II Transfer Vehicle.（頁面存檔備份，存於網際網路檔案館）, JAXA （英文）（日語）
* HTV/H-IIB launch Special site（頁面存檔備份，存於網際網路檔案館）, JAXA （英文）（日語）
HU

**HU**、**Hu** 或 **hu** 可以指：

* 海南航空的 IATA 航空公司代碼
* 匈牙利語的 ISO 639 alpha-2 代碼
* .hu，匈牙利的國家頂級域名
* 胡先驌，中國植物學家，Hu 是其標準命名人縮寫。
* 胡錦濤，前中共中央總書記、中國國家領導人，在西方媒體中常僅以其姓稱呼。
* 亨氏單位（Hounsfield scale，簡稱 HU），阻射率的數量尺度單位。
HU-210

**HU-210**（英語：HU-210），分子式 C25H38O3，是一種人工合成的大麻素，由耶路撒冷希伯來大學的拉斐爾・梅舒朗團隊在 1988 年開發。

## 參考文獻

## 外部連結
HUB

**集線器**（Ethernet hub）是指將多條乙太網路雙絞線或光纖集合連接在同一段物理媒介下的裝置。集線器是運作在 OSI 模型中的實體層，可以讓其連結的裝置工作在同一網段。集線器上有多個 I/O 埠，訊號從任意一個埠進入後，會從其他埠出現。中繼器（Repeater hub）也會參與衝突檢測（collision detection），在檢測到衝突時向所有通訊埠轉發擁塞訊號。除了標準的 8P8C（「RJ45」）水晶頭，一些集線器也支援 BNC 或 AUI（附加單元介面）來連接傳統 10BASE2 或 10BASE5 網路。

由於集線器會把收到的任何數位訊號，經過再生或放大，再從集線器的所有埠送出，這會造成訊號之間碰撞的機會很大，而且訊號也可能被竊聽，並且這代表所有連到集線器的裝置，都是屬於同一個碰撞網域以及廣播網域，因此大部份集線器已被交換機取代。

## 技術資訊

#### 實體層功能

集線器相比於交換機更為簡單，它可以被視作有多個埠的中繼器，從一個埠接受位元位（或符號），再從其他埠送出。它對實體層封包有所感知，可以檢測到其開始、掛起及衝突。在檢測到衝突時會傳送擁塞訊號以傳播這一事件。集線器不能對經過它的網路流量做更進一步地檢查與管理：任何進入的封包都會被廣播到其他埠。集線器 / 中繼器無法儲存資料 —— 封包必須在接收時被傳送，一旦發生衝突，就會丟包（傳送端應當能夠偵測到，並重新傳送）。基於此，集線器只能以半雙工模式工作。因此，由於衝突域更廣，相比於使用更複雜的網路裝置，使用集線器的資料網路更容易出現封包衝突。

## 集線器的種類

* 被動型集線器（Passive Hub），集線器不需連接電源，因此網路訊號隨距離衰減，只適用於短距離的網路連接。
* 主動型集線器（Active Hub），集線器需連接電源，可加強訊號強度（整波放大）。
* 除此之外，有的集線器可能具有 Up Link 的插孔，可串接成樹狀區域網路。

## 參見

* 網路位址轉換
* 橋接器
* 路由器
* 數據機
* Wi-Fi
* 無線接取器
* 網際網路歷史

## 參考文獻

## 外部連結

* Hub Reference （頁面存檔備份，存於網際網路檔案館）
HUB娛家戲劇台電視劇集列表_(2019年)

本列表列出 2019 年由新加坡 HUB 娛家戲劇台所播放的劇集。

## 星期一至五（非黃金時段）

### 韓劇時段

新加坡時間逢星期一至五 17:45-19:00 播出，逢星期一至五 09:30-10:45 重播；所有劇集為首播。

## 星期一至日

### 中國大陸、台灣電視劇時段

新加坡時間每日 19:00-20:00 播出，逢星期二至六 01:30-02:30／星期日、一 01:15-02:15 及星期一至五 08:30-09:30／星期六、日 08:15-09:15 重播；所有劇集為首播。

## 星期一至五（黃金時段）

### 第二線劇集

新加坡時間逢星期一至五 20:00-21:00 播出，逢星期二至六 03:00-04:00、星期一至五 10:45-11:45、星期六 10:15-14:00 重播；所有劇集為首播。

### 第三線劇集

新加坡時間逢星期一至五 21:00-22:00 播出，逢星期二至六 04:00-05:00、星期一至五 11:45-12:45、星期日 10:15-14:00 重播；所有劇集為首播。

### 第一線劇集

新加坡時間逢星期一至五 22:00-22:30 播出，逢星期二至六 02:30-03:00、05:00-05:30、星期一至五 12:45-13:15 重播；所有劇集為首播。

## 星期五

### 日劇時段

新加坡時間逢星期五 22:30-23:30 播出，逢星期六 05:30-06:30、星期一 13:15-14:15 重播；所有劇集為首播。

## 星期六、日（黃金時段）

### 中國大陸電視劇時段

新加坡時間逢星期六、日 20:00-21:45 播出，逢星期日、一 03:15-05:00、星期六、日 16:15-18:00 重播；所有劇集為首播（**每次播映兩集**）。

## 星期六

### 韓劇時段（土耀）

新加坡時間逢星期六 21:45-00:00 播出，逢星期日 05:00-07:15、星期六 14:00-16:15 重播；所有劇集為首播（**每次播映兩集**）。

## 星期日

### 韓國速密達

新加坡時間逢星期日 21:45-00:00 播出，逢星期一 05:00-07:15、星期日 14:00-16:15 重播；所有劇集為首播（**每次播映兩集**）。

## 星期一

### 午夜劇集時段

新加坡時間逢星期一 22:30-00:15 播出，逢星期二 05:30-07:15、13:15-15:00 重播（**每次播映兩集**）。

## 星期二至四

### 午夜劇集時段

新加坡時間逢星期二至四 22:30-00:15 播出，逢星期三至五 05:30-07:15、13:15-15:00 重播。

## 參考文獻

## 外部連結
HUB娱家戏剧台

**HUB 娛家戲劇台**（英文：**HUB VV Drama**；前身 Variety Vision，1992 年 4 月 1 日開播，1995 年 5 月 31 日停播）是新加坡星和視界的電視劇頻道，主要節目包括 TVB 港劇、中國大陸劇、台劇及韓劇。星和娛家戲劇台的節目以國語播映，部分節目設雙聲道。

此頻道為慶祝其成立 20 周年，在新加坡標準時間周五 22:30 增加日劇時段。

## 相關

* 星和無線電視大獎

## 參考

## 外部連結

* tvbi（頁面存檔備份，存於網際網路檔案館）
* 海外版台劇八點檔 （頁面存檔備份，存於網際網路檔案館）
HUB戏剧首选

**HUB 戲劇首選**的英文名為 **HUB Drama First** 是新加坡星和有線電視的 860 頻道，該頻道與香港同步播出最新、最熱播的香港 TVB 劇集，該頻道備有粵語及華語雙聲道服務，同時也備有英文字幕服務。

2018 年 9 月起，HUB 戲劇首選轉型為亞洲戲劇點播，不僅提供與香港同步上線最新及熱播 TVB 劇集 (提供粵語原聲及國語配音)，更提供來自中國，臺灣，日本及韓國最新劇集，劇集上線後，則安排到 HUB 娛家戲劇台及 HUB 都會台播放。

該頻道由星和電視 (星和視界) 擁有的，該電視台還有 HUB Sensasi，HUB Sports Arena, HUB Sports，HUB 都會台和 HUB 娛家戲劇台等頻道。

## 相關

星和無線電視大獎 2014

## 外部連結

tvbi（頁面存檔備份，存於網際網路檔案館）

## 參考
HUB都會台

**HUB 都會台**（英語：_HUB E City_）是新加坡收費媒體公司星和視界旗下的電視頻道之一，該頻道以中文廣播為主，播出的節目包含綜藝節目、電視劇、以及電視動畫。另外星和視界的 826 頻道（HUB 都會 + 2）顯示 + 2，表示他們會在 2 小時後播出 825 頻道的相同節目，但在 2015 年 7 月 28 日無通告之下面臨關閉。

該頻道由星和電視（星和視界）擁有的，該電視台自辦頻道還有 HUB Sensasi、HUB Sports 1-3、HUB 娛家戲劇台等頻道。

除此之外，星和視界用戶可從 2011 年 4 月 25 日至 2012 年 12 月 31 日免費觀賞，後來延長至 2013 年 12 月 31 日，但在無通告之下四度延長，並不設期限，後來第 825 頻道不僅屬於付費頻道，但第 111 頻道直至現在成為固定免費頻道。

## 參考資料

## 參見

* 星和娛家戲劇台

## 外部連結

星和視界官網

* 海外版台劇八點檔 （頁面存檔備份，存於網際網路檔案館）
HUDSON

**哈德森**或**哈德遜**（Hudson）可以指：

* 哈德遜灣，加拿大的大型海灣。
* 哈德遜河，美國紐約州的大河。
* 哈德遜汽車，已結業的美國汽車製造商。
* Hudson Soft，一家日本遊戲軟體公司（1973 年－2012 年）。
* Hudson (軟體) 一個使用 java 寫的持續集成軟體
* 哈德遜夫人，小說夏洛克・福爾摩斯系列裡的登場人物。
* 哈德遜 (夜行神龍)，電視動畫夜行神龍系列裡的登場角色。
* 哈德遜研究所，一個美國保守派智庫。
* 哈德森 (伊利諾伊州)
* 哈德森 (愛荷華州)
* 哈德森 (姓氏)
HUDSON_SOFT

**Hudson Soft**（日語：株式会社ハドソン _kabushiki-gaisha Hadoson_），是一家已被併購的日本電子遊戲發行商，主要業務為遊戲軟體開發與銷售。2012 年，成為科樂美數位娛樂的事業品牌，公司法人消滅。

## 歷史

1973 年 5 月 18 日，Hudson 由工藤裕司和工藤浩兩兄弟創立於札幌市豐平區，他們喜歡火車，所以將公司命名為「Hudson Locomotives」（命名源於日本國鐵 C62 型蒸汽機車所使用的軸配備「Hudson」）。Hudson 最初以銷售電信設備和藝術照片為主要業務。

1975 年 9 月，Hudson 開始銷售個人電腦相關產品。

1978 年 3 月，Hudson 開始製作和銷售電子遊戲.

1984 年，Hudson 加入任天堂 FC 遊戲機陣營，為 FC 首批第三方軟體銷售商。在 FC 推出的遊戲《超級運動員》（_Lode Runner_）銷售量達 150 萬份。同時，該公司繼續為 NEC PC-8801、MSX、ZX Spectrum 等其他平台開發遊戲。

1984 年 11 月，公司重組為 Hudson Soft Co., Ltd.。

1985 年，FC 遊戲機上的《轟炸超人》發售並且獲得巨大成功。

1987 年 7 月，Hudson 開發了 "C62 System"，並與 NEC 合作開發 PC Engine 遊戲主機。這是 FC 以外在日本最成功的，但 TurboGrafx-16 在北美市場份額比任天堂的超級任天堂和 SEGA 的 Genesis 都要少。

1989 年，Hudson 在香港成立「和盛電腦技術有限公司」（Hudson ERA Soft Co., Ltd.），並連續三年在香港灣仔修頓球場舉辦遊戲展及比賽。

1992 年，Hudson ERA 於香港開發首款帶有中文語言選擇的 PC Engine 遊戲軟體《忍者龍劍傳》，同時協助 TVB 拍攝電視劇《都市的童話》。

1994 年，由 Hudson 獨立開發的 32 位元半導體晶片 "HuC62" 在 NEC 的 PC-FX 遊戲平台上使用。

1995 年 11 月 17 日，Hudson ERA 解散。

2000 年 12 月，Hudson Soft Co., Ltd. 在大阪證券交易所股票上市。2001 年 8 月，科樂美（Konami）購買了 Hudson 5.6 百萬份額的股票，並成為了該公司的最大股東。收購的同時，Hudson 獲得了 Konami Computer Entertainment Studio 的札幌分部，命名為 Hudson Studio。

2005 年 4 月，Konami 成為 Hudson 的主要股東. Hudson 繼續自主生產，但與 Konami 的合作更緊密。

2010 年－2011 年期間，Hudson 大量員工轉投到任天堂的子公司 NDcube 工作室，其負責人是 Hudson 創始人工藤裕司。

2011 年 1 月，Hudson 完全成為 Konami 的子公司。

2012 年 3 月 1 日，Hudson 併入科樂美數位娛樂，品牌保留，公司法人消滅。

2014 年 1 月 1 日，Hudson 品牌消滅、併入科樂美品牌，也關閉了官網，結束了約 40 年的歷史。

## 參考資料

## 外部連結

* （日語）Hudson 官方網站（已關閉。2013 年 12 月 8 日的存檔）
* Jap-Sai.com 上的 Hudson Soft 歷史
HUD_(電子遊戲)

電子遊戲領域中，**抬頭顯示器**（英語：heads-up display，中國大陸譯作「**平視顯示器**」，簡稱「**HUD**」）或**狀態欄**（英語：status bar）是用戶介面的一部分，以視覺方式提示遊戲狀態。其名源自現代航空器的抬頭顯示器。

抬頭顯示器一般同時顯示多項資訊，如主人公的生命值、道具，以及遊戲進度（如得分、關卡、剩餘時間）。

## 參考文獻
HUGO_BOSS

**雨果博斯**（德語：**Hugo Boss AG**）是一個德國的時尚品牌，主攻高價位男裝成衣及配件，創辦人是雨果・斐迪南・博斯（1885–1948）。

## 歷史

雨果博斯創立於 1923 年，第一次世界大戰之後，發源地在德國斯圖加特南面的麥琴根（Metzingen），該處後來發展成為德國品牌工廠區。

雨果博斯創辦初期主要生產男裝，數年後，因德國經濟蕭條而接近破產。在 1930 年代至 1940 年代初，雨果博斯轉營為納粹黨生產衝鋒隊 、黨衛隊制服，及希特勒青年團的裝備。

在 1985 年，雨果博斯在德國成為上市公司，之後於 1991 年被義大利時裝集團 Marzotto 收購，由此博斯家族與雨果博斯品牌已無任何關係。

2018 年，流行音樂天王麥可・傑克森逝世十周年，雨果博斯與英國國家肖像館聯手在英國舉辦名為「Michael Jackson: On the Wall」展覽，探討麥可對當代藝術的啓發。

## 旗下品牌

對於 Boss 這個品牌，擁有以下 5 個子品牌：

* **Boss**: 商務、晚裝類
* **Boss Tailored** 高品質面料、手工藝
* **Boss Orange**: 休閒類
* **Boss Green**: 運動類
* '_Hugo_

## 經營數字

2007 財年該公司營業額為 16.32 億歐元，盈利 1.54 億歐元。西服生產位於他在德國 Metzingen，土耳其和美國的工廠。82% 的營業額由旗下知名男士品牌 Boss Black 所產生。全世界（截至：2006 年 12 月 31 日）擁有 210 家自有專賣店。

## 爭議事件

### 鏡子墜下事件

2015 年 9 月，雨果博斯（英國）被判罰款 120 萬英鎊，原因是一名兒童於 2013 年 6 月在牛津郡比斯特的一家商店因頭部受到致命傷害四天後死亡。事發原因是一面重達 120 公斤（250 磅）的鋼架試衣鏡落在他身上並導致其受傷。牛津刑事法院早些時候被告知，它「被擱置在一邊，沒有任何固定裝置」，而死因裁判官則認為這是一場遲早要發生的意外。 2015 年 6 月，雨果博斯（英國）承認其違反了《1974 年工作場所健康與安全法》和《1999 年工作場所健康與安全管理條例》。該公司的法律代表說：「這次事件的後果是令人難以想像的可怕。自事故發生以來，雨果・博斯竭盡所能，首先承認錯誤，表達真誠、由衷的懊悔，並表明做出正確決定的決心，確保不會重蹈覆轍。」

### 抵制新疆棉事件

2021 年 3 月發生新疆棉花爭議，雨果博斯 3 月 25 日晚在中國大陸的官方微博表示「將會繼續採購和支持新疆棉花」，雨果博斯總公司在 3 月 27 日凌晨發出英文聲明，澄清沒有採購新疆棉花，原料若然與新疆有關，會立即要求供應商改變原料來源。聲明同時表明該公司的立場是不容忍強迫勞動，官方微博的貼文亦已被移除。公司發言人韋斯特曼（Carolin Westermann）回覆《路透社》查詢時強調英文版的聲明才是官方立場，之前在中國的官方微博支持新疆棉訊息是未經授權的貼文。

## 外部連線

* _華盛頓郵報_, 1997 年 8 月 14 日；Page B01 [1] [2] （頁面存檔備份，存於網際網路檔案館）
* _彭博資訊_, 2006 年 8 月 25 日 Baldessarini sold [3] （頁面存檔備份，存於網際網路檔案館）

## 參考文獻
HUMAN_我生

《**Human 我生**》是香港男歌手古巨基的個人廣東音樂專輯，於 2006 年 8 月發行。

## 專輯簡介

全碟歌詞由著名詞人林夕執筆所填（除敢死隊由黃仲凱填詞），雷頌德監製。作曲方面包括台灣唱作人陶喆，本地作曲人陳輝陽、雷頌德，唱作人側田、王菀之等。

此碟一洗古巨基前兩年之「K 歌」形象，以清新感覺及「人生」概念為主題貫串全碟，細說人生過程及道理。古巨基更首次操刀擔任音樂電影及 MV 導演，邀來好友周慧敏擔任歌曲《愛得太遲》MV 的女主角。

專輯首批特別版 2CD+DVD，內容包括︰60 分鐘的音樂電影、MV、以及收錄在 Bonus CD 內的《愛得太遲》合唱版本。

此碟更為古巨基獲得多個大碟獎，包括：

* 叱吒樂壇至尊大碟獎
* 四台聯頒音樂大獎 - 大碟獎
* 新城勁爆大碟獎

### 歌曲《花灑》

由王菀之所作曲，一派上台即獲商台（903）支持，得到超過 200 的播放率。此曲更為三台冠軍歌，惜未能在 TVB 勁歌金榜中奪第一，成四台冠軍曲。不過最後在 TVB 的《2006 勁歌金曲優秀選第一回》中成為入選歌之一。一度令大眾認為此曲是古巨基 2006 年之年度作品。

### 歌曲《愛得太遲》

由楊鎮邦所作曲，一派台即引起回響。林夕藉此詞勸大家要珍惜眼前人，成功令大家共鳴。再一次成三台冠軍歌，惜又是未能在 TVB 勁歌金榜中奪第一，成四台冠軍曲。不過最後在 TVB 的《2006 勁歌金曲優秀選第二回》中成為入選歌之一。此歌的出現取替了花灑的年度作地位。最後此歌在四台年底頒獎禮中囊括所有歌曲大獎。

## 曲目

## 派台歌曲及成績

* 1st PLUG 花灑
* 2nd PLUG 愛得太遲
* 3rd PLUG 我生（叱吒）／重複犯錯（新城、無線、港台）
* 4th PLUG 愛美麗

## 相關獎項及提名

### 專輯《Human 我生》

* 2006 年度 IFPI 十大銷量廣東唱片

### 歌曲《愛得太遲》

* 第二十九屆十大中文金曲頒獎典禮 — 全球華人至尊金曲獎
* 2006 年度叱吒樂壇流行榜頒獎典禮 — 叱吒樂壇至尊歌曲大獎
* 2006 年度叱吒樂壇流行榜頒獎典禮 — 叱吒樂壇我最喜愛歌曲大獎
* 2006 年度十大勁歌金曲頒獎典禮 — 金曲金獎
* 2006 年度新城勁爆頒獎禮 — 新城勁爆播放指數大獎
* 2006 年度新城勁爆頒獎禮 — 新城勁爆年度歌曲大獎
* 2006 年度四台聯頒音樂大獎 — 歌曲獎
* 2006 年度 RoadShow 至尊音樂頒獎禮 —— 至尊歌曲 《愛得太遲》
* 2006 年度 SINA Music 樂壇民意指數頒獎禮 - 新歌試聽 — 全年最高收聽率歌曲
* 2006 年度 SINA Music 樂壇民意指數頒獎禮 - 我最喜愛至尊金曲
* 2006 雅虎香港 Yahoo！搜尋人氣大獎頒獎禮：「十大人氣歌曲和金曲」獎
* 2006 年度雪碧中國原創音樂流行榜頒獎禮：港台十大金曲
* 2006 年度雪碧中國原創音樂流行榜頒獎禮：全國至尊金曲大獎
* 2006 年度新城勁爆頒獎禮 —— 新城勁爆歌曲
* 2006 年度十大勁歌金曲頒獎典禮 - 十大勁歌金曲
* 2006 年度十大勁歌金曲頒獎典禮 - 最受歡迎廣告歌曲大獎 (銀獎)
* 第二十九屆十大中文金曲頒獎典禮 - 十大中文金曲獎
* 2006 年度 9+2 音樂先鋒榜頒獎典禮：十大金曲獎
* 2006 年度 9+2 音樂先鋒榜頒獎典禮：金曲金獎
* 第七屆華語音樂傳媒大獎 - 年度粵語歌曲
* 第四屆勁歌王頒獎典禮 - 至尊金曲大獎《愛得太遲》
* 第四屆勁歌王頒獎典禮 - 金曲獎（粵語）

### 歌曲《花灑》

* 2006 年度新城勁爆頒獎禮 —— 新城勁爆歌曲 -《花灑》
* 2006 勁歌金曲優秀選第二回 - 得獎歌曲《花灑》

## 參考來源
HUMAN株式會社

**HUMAN 株式會社**為 1983 年創立的遊戲軟體公司。

於 1990 年設立全世界第一所遊戲設計人才養成的專門學校「ヒューマンクリエイティブスクール」，並於 1991 年發售任天堂紅白機遊戲『埃及』之後，自有品牌的作品逐漸增多。1992 年與 NEC Home Electronics（NEC 旗下與 Hudson Soft 合資的子公司，簡稱 NEC HE）合併，成立 HuneX，為 NEC HE 的遊戲機（PC Engine、PC-FX）開發專用的遊戲軟體。

自 1998 年結束街機開發事業之後，公司赤字大幅提高。1999 年 11 月申請和議，翌年 1 月公司破產倒閉，3 月結束遊戲軟體部門，專門學校事業也於 2002 年 1 月倒閉。已被其他公司買下的「HUMAN CREATIVE SCHOOL」仍繼續營運，名稱接連改為「パソナソフトバンククリエイティブスクール」→「プロフェシオクリエイティブスクール」，最後於 2003 年 3 月結束營運。現存專門學校「Human Academy」（Human Group）為完全無關的其他公司。

Human Entertainment 破產後由 Spike 接手旗下遊戲軟體的著作權，2012 年與 CHUNSOFT 合併後目前由 Spike Chunsoft 持有。

## 重要遊戲作品

有許多系列由其他公司繼續開發續作。

* Clock Tower（時鐘塔、鐘樓驚魂）系列
* ザ・コンビニ系列
* セプテントリオン
* トワイライトシンドローム
* 猫侍
* 爆走デコトラ伝説
* パペットズー・ピロミィ
* フォーメーションサッカー系列
* ファイヤープロレスリング系列
* 御神楽少女探偵団
* ミザーナ・フォールズ
* ムーンライトシンドローム
* リモート・コントロール・ダンディ

## 過去社員

* 河野一二三
* 志倉千代丸
* 須田剛一
* 鳴澤賢一

## 外部連結

* 官方网站. [2015-02-05]. （原始內容存檔於 1999-04-30）. （日語）