使用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符号实体而不是实际的符号

回答

相关问题