在此网页上http://taj.chass.ncsu.edu/Hindi.Less.05/dialog_script.html,在 Windows 和 Linux 上运行的 Firefox 和 Opera 显示源 html 中夹杂着垃圾字符(对我来说,它们显示为带有问号的黑色菱形),而不是呈现的网页。
在我尝试过的所有浏览器中,只有 Internet Explorer 可以正确显示页面。我非常希望能够在 Linux 上运行 Firefox 来使用该网站。为了尝试让页面正确显示,我尝试手动将字符编码设置为所有可用值,但没有任何成功。你们还有其他建议吗?
答案1
在 Firefox 中,使用
查看->字符编码->更多编码->UTF-16。
希望有所帮助。
大多数计算机文本被编码为ascii
或者8 位 Unicode(UTF-8)
有关 UTF-16 的更多信息,请查看这里。
一般来说,如果您�
在 Firefox 中看到,请使用一些“智能猜测”并尝试更改字符编码。通常这种方法有效,但偶尔,尤其是在使用 Linux Firefox 时,您可能会遇到字体问题。
答案2
虽然确实可以手动选择某种编码(访问其他网站时不要忘记禁用该编码),但实际上网站应该正确指定它。服务器或网页本身应该指定某些内容,否则浏览器只能做出最佳猜测。当然,如果编码是指定,那么 HTML 文档实际上应该使用该编码。网站从问题来看,如下所示:
要查看 Web 服务器是否指定了某些内容,需要查看所谓的标题. 使用在线服务网络嗅探器显示你将获得的标题:
HTTP/1.1 200 正常 日期:2009 年 8 月 17 日星期一 17:47:03 GMT 服务器:Apache 最后修改时间:2006 年 11 月 27 日星期一 23:38:49 GMT ETag:“758b0606-1a316-4234309151440” 接受范围:字节 内容长度:107286 连接:关闭 内容类型:text/html;字符集=utf-8(BOM UTF-16,litte-endian)
最后一行看起来有点奇怪:服务器怎么能声称某个东西既是 UTF-8 又是 UTF-16?的值charset
应该是其中之一挂号的与 IANA 一致(例如,UTF-8 没有任何注释)。但是,使用Wireshark数据包嗅探器而不是在线服务揭示了文本(BOM UTF-16,小端字节序)实际上是来自在线服务的评论,而不是由网络服务器发送的。
因此:Web 服务器声称它将向我们发送一个 UTF-8 编码的 HTML 文档。
但是,下面的 HTML 文档是错误的(已编辑以便于阅读):
ÿþ<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <头部> <title>第 5 课</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <link href="main.css" rel="stylesheet" type="text/css"> </head> ...
上面,指定内容类型的行应该是 中第一个出现的行<head>
,否则浏览器不知道如何处理 中的特殊字符<title>
。更重要的是,前两个奇数字符ÿþ
实际上是十六进制代码 FF 和 FE,就像已经提到的在线服务一样,它们是字节顺序标记对于 UTF-16,小端字节序。
因此:Web 服务器承诺发送 UTF-8,但随后它发送了指示 UTF-16 LE 的标记。接下来,在 HTML 文档中,它声称再次使用 UTF-8。
事实上,Wireshark 显示实际的 HTML 文档是 UTF-16 编码的。这意味着每个字符至少使用两个字节(八位字节)发送。例如 中的 6 个字符<html>
以 12 个十六进制字节的形式发送3C 00 68 00 74 00 6D 00 6C 00 3E 00
。但是,这个网站很可能是纯 ASCII,因为它似乎没有使用任何非 ASCII 字符。相反,HTML 源代码充满了数字字符引用(不合格品), 例如:
यह दिल्ली
शहर है।
浏览器会将上述内容显示为 यह दिल्ली शहर है।。但是,由于使用了 NCR 和 UTF-16,单个字符 य (统一码 U+092F) 在 中需要多达 14 个字节26 00 23 00 32 00 33 00 35 00 31 00 3B 00
,因为它是使用 NCR 编写的,य
而 NCR 本身的 7 个 ASCII 字符使用 UTF-16 编码。当不使用 NCR 时,在 UTF-8 中,这个单个 य 需要 3 个字节(E0 A4 AF
),而在 UTF-16 中则需要 2 个字节(09 2F
)。
对于此 HTML 源,使用 UTF-16 完全浪费带宽,并且服务器也没有使用任何压缩。