除錯 HTML
編寫 HTML 很棒，但如果出現問題，你無法找出程式碼中的錯誤怎麼辦？本文將介紹一些工具，可以幫助你查詢和修復 HTML 中的錯誤。
除錯並不可怕
在編寫任何型別的程式碼時，通常一切正常，直到遇到可怕的錯誤的那一刻——你做錯了什麼，導致程式碼無法執行——要麼完全無法執行，要麼無法按照你的預期執行。例如，以下顯示了嘗試 編譯 使用 Rust 語言編寫的簡單程式時報告的錯誤。
這裡，錯誤訊息相對容易理解——“未終止的雙引號字串”。如果你檢視程式碼，你可能會發現 println!(Hello, world!"); 邏輯上可能缺少雙引號。但是，隨著程式變得越來越大，錯誤訊息會迅速變得更加複雜，難以理解，即使是簡單的案例對於不瞭解 Rust 的人來說也可能看起來有點令人生畏。
然而，除錯並不一定很可怕——對任何程式語言或程式碼進行編寫和除錯感到舒適的關鍵是熟悉語言和工具。
HTML 和除錯
HTML 的理解並不像 Rust 那樣複雜。HTML 在瀏覽器解析並顯示結果之前不會被編譯成不同的形式（它被解釋，而不是編譯）。而且 HTML 的 元素 語法可以說比 Rust、JavaScript 或 Python 這樣的“真正的程式語言”更容易理解。瀏覽器解析 HTML 的方式比執行程式語言的方式更寬鬆，這既是好事，也是壞事。
寬鬆程式碼
那麼，我們所說的寬鬆是什麼意思呢？通常，當你犯程式碼錯誤時，你會遇到兩種主要的錯誤型別：
- 語法錯誤：這些是程式碼中的拼寫或標點錯誤，實際上會導致程式無法執行，就像上面顯示的 Rust 錯誤一樣。只要你熟悉該語言的語法並知道錯誤訊息的含義，這些錯誤通常很容易修復。
- 邏輯錯誤：這些錯誤是語法實際上正確，但程式碼不是你想要的那樣，這意味著程式執行不正確。這些錯誤通常比語法錯誤更難修復，因為沒有錯誤訊息可以引導你找到錯誤的來源。
HTML 本身不會出現語法錯誤，因為瀏覽器以寬鬆的方式解析它，這意味著即使存在語法錯誤，頁面也會顯示。瀏覽器內建規則來規定如何解釋編寫錯誤的標記，因此即使結果不符合預期，你也會獲得可以執行的東西。當然，這仍然是一個問題！
注意： HTML 以寬鬆的方式解析，因為在建立網頁時，人們決定允許人們釋出自己的內容比確保語法絕對正確更重要。如果一開始就更加嚴格，網頁可能不會像今天這樣流行。
主動學習：學習寬鬆程式碼
現在，是時候學習 HTML 程式碼的寬鬆性了。
- 首先，下載我們的 debug-example 演示 並將其儲存到本地。這個演示故意包含了一些內建錯誤供我們探索（HTML 標記被稱為格式錯誤，而不是格式良好）。
- 接下來，在瀏覽器中開啟它。你將看到類似這樣的內容：
- 這看起來不太好；讓我們看看原始碼，看看我們是否能找出原因（只顯示正文內容）html
<h1>HTML debugging examples</h1> <p>What causes errors in HTML? <ul> <li>Unclosed elements: If an element is <strong>not closed properly, then its effect can spread to areas you didn't intend <li>Badly nested elements: Nesting elements properly is also very important for code behaving correctly. <strong>strong <em>strong emphasized?</strong> what is this?</em> <li>Unclosed attributes: Another common source of HTML problems. Let's look at an example: <a href="https://www.mozilla.org/>link to Mozilla homepage</a> </ul> - 讓我們回顧一下問題
- 現在，讓我們看看瀏覽器渲染的標記，而不是原始碼中的標記。為此，我們可以使用瀏覽器開發者工具。如果你不熟悉如何使用瀏覽器的開發者工具，請花幾分鐘時間回顧 探索瀏覽器開發者工具。
- 在 DOM 檢查器中，你可以看到渲染後的標記是什麼樣的：
- 使用 DOM 檢查器，讓我們詳細地探索程式碼，看看瀏覽器是如何嘗試修復我們的 HTML 錯誤的（我們在 Firefox 中進行了審查；其他現代瀏覽器應該給出相同的結果）
- 段落和列表項被賦予了結束標籤。
- 我們不清楚第一個
<strong>元素應該在哪裡關閉，因此瀏覽器用自己的強標籤將每個單獨的文字塊包裝起來，一直到文件底部！ - 瀏覽器已修復不正確的巢狀，如下所示html
<strong> strong <em>strong emphasized?</em> </strong> <em> what is this?</em> - 缺少雙引號的連結已被完全刪除。最後一個列表項看起來像這樣html
<li> <strong> Unclosed attributes: Another common source of HTML problems. Let's look at an example: </strong> </li>
HTML 驗證
因此，從上面的例子可以看出，你真的需要確保你的 HTML 格式良好！但是怎麼做呢？在像上面這樣的小例子中，很容易搜尋這些行並找到錯誤，但對於一個龐大而複雜的 HTML 文件怎麼辦呢？
最好的策略是首先使用 Markup Validation Service 執行你的 HTML 頁面——該服務由 W3C 建立和維護，W3C 是負責維護定義 HTML、CSS 和其他 Web 技術規範的組織。這個網頁將 HTML 文件作為輸入，對其進行處理，並給你一個報告，告訴你 HTML 中有什麼問題。
為了指定要驗證的 HTML，你可以提供一個網頁地址，上傳一個 HTML 檔案，或直接輸入一些 HTML 程式碼。
主動學習：驗證 HTML 文件
讓我們使用我們的 示例文件 來嘗試一下。
- 首先，在另一個瀏覽器選項卡中載入 Markup Validation Service，如果它還沒有開啟。
- 切換到 Validate by Direct Input 選項卡。
- 複製示例文件的所有程式碼（不僅僅是正文），並將其貼上到 Markup Validation Service 中顯示的大型文字區域中。
- 按下Check按鈕。
這應該會給你一個錯誤列表和其他資訊。
解釋錯誤訊息
錯誤訊息通常很有用，但有時它們並不那麼有用；透過練習，你可以學會如何解釋這些訊息來修復程式碼。讓我們看一下這些錯誤訊息，看看它們是什麼意思。你會發現每條訊息都帶有一個行號和列號，以幫助你輕鬆地找到錯誤。
- “暗示結束標籤
li，但存在開放元素”（2 個例項）：這些訊息表明存在一個應該關閉的元素。結束標籤是暗示的，但實際上並不存在。行/列資訊指向結束標籤應該真正存在的行的下一行，但這已經是一個足夠好的線索，讓你知道問題出在哪裡。 - “未關閉的元素
strong”：這很容易理解——一個<strong>元素未關閉，行/列資訊直接指向它的位置。 - “結束標籤
strong違反巢狀規則”：這指出了巢狀錯誤的元素，行/列資訊指出了它們的位置。 - “在屬性值內遇到檔案結尾。忽略標籤”：這條訊息有點含糊；它指的是存在一個未正確格式化的屬性值，可能在檔案末尾附近，因為檔案末尾出現在屬性值內部。瀏覽器無法渲染連結這一事實應該可以讓我們很好地瞭解哪個元素存在問題。
- “遇到檔案結尾，但存在開放元素”：這有點模稜兩可，但基本上指的是存在需要正確關閉的開放元素。行號指向檔案的最後幾行，這條錯誤訊息帶有一行程式碼，指出了開放元素的示例
example: <a href="https://www.mozilla.org/>link to Mozilla homepage</a> ↩ </ul>↩ </body>↩</html>
注意：缺少結束引號的屬性可能會導致開放元素，因為文件的其餘部分將被解釋為屬性的內容。
- “未關閉的元素
ul”：這並不十分有用，因為<ul>元素已經正確關閉。這個錯誤是由於<a>元素未關閉而產生的，這是因為缺少結束引號。
如果你無法弄清楚每條錯誤訊息的含義，不用擔心——一個好主意是嘗試一次修復幾個錯誤。然後嘗試重新驗證你的 HTML，看看還剩下哪些錯誤。有時，修復一個早期錯誤也會消除其他錯誤訊息——多個錯誤通常是由單個問題造成的，形成多米諾骨牌效應。
當你看到輸出中出現以下橫幅時，就知道所有錯誤都已修復
