使用HTML符號實體而不是實際的符號

是否有任何特殊的原因，我應該使用HTML符號實體，而不是實際的符號（我的意思是我可以只鍵入一個）？例如符號/;它的HTML實體代碼是&#47。使用HTML符號實體而不是實際的符號

我應該在HTML代碼中使用符號代碼還是符號本身，爲什麼？

來源

2013-05-16 Evgeny Fedorenko

當您使用特殊字符時，您必須使用符號當您更改編碼時可能會被誤解（如ÇÃ和其他）。或者當你不想解釋字符時，就像如果你想要輸入
而不是打破一條線 – Lefsler

爲什麼這兩個答案都被低估？ – BoltClock

[應該何時使用HTML實體]的可能的重複（http://stackoverflow.com/questions/436615/when-should-one-use-html-entities） –

號

實體和字符引用是有益的，只有：

的字符在HTML特殊的意義在哪裏，你要使用的字符點（/永遠也不會知道，它只有無論如何，你不能有/作爲數據的地方的特殊含義）。
您無法鍵入字符（例如，因爲它沒有出現在鍵盤上）。
您不能將文件編碼爲UTF-8（或以包含它的其他編碼方式編碼...並且/以ASCII格式顯示）。

來源

2013-05-16 18:19:50 Quentin

沒有downvote，但是...因爲你「無法輸入字符」？如果你能找到它的數值，你可以複製並粘貼它。 Charmap等也很有用。 – deceze

-3

除非您知道您將始終使用相同的軟件和計算機系統來編輯您的HTML，否則您將不可避免地遇到無法編輯自己的代碼的情況（如果直接使用符號）您在文檔中指定的字符編碼或HTTP標頭。只有在完美的世界中，字符編碼才能正常傳輸，即使如此，Macintosh和Windows都無法正確傳輸。

如果我從任的Macintosh或Windows中真正支持所有可用的編碼系統軟件中打開了一個所謂的「正常」編碼的文件，我看到這樣的消息：

-=-J(DOS)**--F1 Top L3  (Text) ---------------------------------------- 
These default coding systems were tried to encode text 
in the buffer: 
    (iso-2022-7bit-dos (284 . 4194194) (379 . 4194194) (462 . 4194195) 
    (492 . 4194196) (635 . 4194195) (640 . 4194196) (642 . 4194195) (772 
    . 4194196) (833 . 4194195) (839 . 4194196) (857 . 4194195)) 
    (utf-8-dos (284 . 4194194) (379 . 4194194) (462 . 4194195) (492 
    . 4194196) (635 . 4194195) (640 . 4194196) (642 . 4194195) (772 
    . 4194196) (833 . 4194195) (839 . 4194196) (857 . 4194195)) 
However, each of them encountered characters it couldn't encode: 
    iso-2022-7bit-dos cannot encode these: \222 \222 \223 \224 \223 \224 \223 \224 \223 \224 ... 
    utf-8-dos cannot encode these: \222 \222 \223 \224 \223 \224 \223 \224 \223 \224 ... 

Click on a character (or switch to this window by `C-x o' 
and select the characters by RET) to jump to the place it appears, 
where `C-u C-x =' will give information about it. 

Select one of the safe coding systems listed below, 
or cancel the writing with C-g and edit the buffer 
    to remove or modify the problematic characters, 
or specify any other coding system (and risk losing 
    the problematic characters). 

    thai-tis620

儘快記住，作爲您的服務器上的數據已關閉，例如放在電子郵件等中，但不能保證編碼傳遞一致，而且很可能不是。識別文檔的字節標記和其他不可見方法不能按照承諾的方式工作，更不用說瞬態方法，例如HTTP頭文件，只要文檔超出了您自己仔細配置的HTTP服務器的上下文就會丟失。

HTML的指導原則是它是一種純文本標記語言，如果使用得當，它可以與任何支持最基本文本的系統兼容。對於正常的7位US-ASCII字符集以外的任何字符，HTML文檔應該使用HTML實體。任何其他字符具有不同的二進制定義，具體取決於所使用的編碼，甚至可能在單字節和多字節表示之間有所不同。

在非HTML文檔中，您可以隨意使用原始符號，因爲當您將它們嵌入到原始文件格式或HTML中時，可以確保指定「正確」字符編碼，即將被你創作的系統和任何與之兼容的系統所認可。

來源

2013-05-16 18:37:37

可怕的意見。如果你在使用英文網站，這很容易說明，但是由於實體使得不可能處理文檔，所以指定某人將所有字符保存在日文文檔中，這很容易。我們已經過去了這個問題的時代，謝天謝地！ – deceze

@deceze這裏沒有「時代」。日語就像電腦和互聯網的母語一樣和英語一樣，可能更多。至少和你一樣，我會喜歡把我的語言和我的HTML混合在一起的便利性，但是我有經驗告訴我它是不可維護的。你的比喻中的錯誤是，你認爲直接在HTML源代碼中寫內容是很自然的。那個時代結束了。內容和HTML/CSS現在已經很漂亮地彼此分開了。請再讀一遍我的答案。 –

什麼是日文網站的「原生」格式？我*需要*從其他地方獲取內容，然後以編程方式在其周圍包裝HTML？那是你在說什麼？這是不可能的。您仍然會在*某種形式的源代碼*中使用日文字符，這意味着您至少需要在正確的編碼中正確處理該*文件。爲什麼不直接在HTML中？到目前爲止，我多年來從未有過混合日語/ HTML這樣的問題。 – deceze

無論應用於文檔的編碼如何，使用HTML實體引用都可以使實體按預期表示。這是好處。

與其嚴格使用所有非US-ASCII字符的實體，隨意使用支持文檔目標語言的文檔編碼，最好還支持其他語言（如UTF-8）。

但是，請避免使用任何系統特定的編碼，尤其是常規的Windows編碼。通常情況下，Windows-1252文本被髮送到ISO-8859-1標籤錯誤的其他系統。

在過去，對數字HTML實體的支持肯定比命名的HTML實體（基於我自己的第一人稱眼睛見證觀察）要少得多，但理論上數字HTML實體仍然是字符編碼獨立的「安全」，因爲數字值直接指向在UCS（http://en.wikipedia.org/wiki/Universal_Character_Set）中註冊並等同於其定義的字符名稱的代碼點。

警告：以下描述了我自己的經驗，並且您的可能會有所不同。

由客戶端傳送給我的HTML文檔，使用直接嵌入的符號進行處理常常被破壞，無法恢復。這可能是美國基礎設施的薄弱環節，也可能是我的客戶對如何發送文件缺乏瞭解。主要語言依賴非ASCII字符的國家的基礎設施和人員將更有可能支持和理解如何正確傳輸文檔而不會造成損壞。
如果您正在開發自己的網站並將自己的文件的最終副本上傳到您的服務器，那麼腐敗的風險非常小。
如果您無法控制您的文檔，從編輯它的角度來看，它可以爲用戶提供服務，那麼您就要承擔風險（也許不是今天，但肯定在近年來在美國，a可能不僅僅是風險）在過程中某些點不正確地轉換文檔並且永久損壞，而不管您嘗試查看哪種編碼。

來源

2013-05-16 20:19:18

數字字符引用始終指代UCS代碼點。因此，他們*解決了編碼兼容性問題。 – deceze

你在考慮油漆。我在想什麼是在油漆下。假設你知道UCS代碼點，那是真的。如果僅僅將所有（多個）字節值轉換爲數字，那不是UCS代碼點，而是一些隨機值。解碼器也是如此。我懷疑大多數瀏覽器在解碼數字實體時都有一個包含所有代碼點的120萬條數據庫。 –

在現實世界中總有妥協，這就是我所談論的世界。我相信你會說現在每個人都有軟件可以正確地做到這一點。好的。但是Stack Overflow適用於那些正在進行軟件編碼的人，而不是那些使用軟件來完成任何事情的人。我會重寫我的答案，以便它不會說「沒有兼容性好處」，而是「不是兼容性問題的靈丹妙藥」（或其他）。 –

使用HTML符號實體而不是實際的符號

回答

相關問題