如何解决为什么HTTP服务器需要知道文件名的编码？
简而言之，情况很简单，HTML文件的内容大部分是ASCII编码的，除了包含UTF-8字符的图像文件名。该图像名称从不显示。 ASCII是默认编码，因此我们不会在任何地方声明它。问题是，为什么图像无法加载？假设图像文件名的文件名和HTML代码中的八位字节相同，为什么图像未正确加载。 此外，如果我们明确告诉浏览器使用UTF-8编码，则该问题似乎已解决。为什么声明编码会影响http服务器获取文件的能力？
您可以在下面找到具体的技术细节和示例代码：
考虑简单的html文件“ index.html”：
<img src="cinturón.jpg"> </img>
以及目录中的以下文件：
~/root
|- index.html
|- cinturón.jpg
如果我运行“ firefox index.html”或在搜索栏中输入〜/ root / index.html，则图像会正确加载。
但是，如果我将文件推送到仅使用a classical setup将请求转发到文件系统的Nginx服务器，则图像将失败，直到我们通过头部meta标记的某些charset属性在html文件中声明编码元素。
<head>
<meta charset="UTF-8">
</head
此伪指令告诉浏览器（其余）文件的编码是什么，但是浏览器已经按照惯例将文件解释为ASCII，这就是它理解ascii标记的方式。而且我的文件名没有显示，因此浏览器实际上不需要知道文件名的编码。
例如，文件系统不支持编码，它们仅存储文件名（如在写入过程中给出的文件名），可能会对其进行哈希处理，然后比较读取时给出的文件名。唯一的要求是，读取和写入时的输入接口使用相同的编码，产生相同的八位位组序列。 在我的情况下，服务器和本地操作系统以及文件系统是相同的，并且文件是通过git复制的，它可以对它们的内容进行校验和以验证它们是否相同，因此可以确定文件系统中的文件名是跨环境完全相同。
在弄清楚浏览器的编码时，我仍然不知道为什么只加载图像，有两种可能。
A）我的指令导致我的浏览器更改其行为。 B）我的指令导致服务器更改其行为。
当浏览器将图像请求发送到服务器时会发生。 当服务器将html文件发送到服务器时，将发生B。这将要求nginx以某种方式解释HTML代码。我不认为HTTP服务器是阅读或理解HTML，所以这不太可能。
通过检查浏览器发送的请求，我可以看到在声明了UTF-8时浏览器发送了“ /cintur%C3%B3n.jpg”和“ /cintur%C3%83%C2%B3n.jpg”除此以外。 ％是转义字符。 C3、83 C2和B3是不同八位位组的十六进制。浏览器在声明编码时以2个八位位组的形式发送ó，而在未声明编码时以4个八位位组的形式发送。此时，异常情况会更清楚地显示出来，声明编码不应更改消息，而应更改其解释方式。
C3 B3是2个字节，代表utf-8中的ó字符，这是基本的多语言平面，即ascii之后的第二个块（在utf-8规范中也称为基本拉丁语）。我还没弄清楚C3 83 C2 B3是什么
在使用od（od -c index.html）静态检查index.html文件时，我们发现
“ c i n t u r 303 263 n。j p g”
其中303和263是八位字节，被解释为无符号八进制数。手动八进制转换为十六进制或使用-tx1选项运行od可以确认它们是B2和C3八位字节。因此，当驻留在服务器和本地计算机中的文件系统中时，html文件中的ó字符长2个字节。同样，我们知道在声明utf-8编码后，浏览器发送的请求中r和n字符之间有4个字节。
由于我头顶上方没有任何工具可以验证ó字符在我的浏览器中有多少个字节，所以我只假定它是4个字节长，接下来要回答的问题是服务器是否发送2字节ó或4字节ó。由于服务器日志已压缩并与其他数据包捕获混合在一起，因此无法找到。
将来我可能会发布其他调试信息，这时我可能会使用像dumanbox或C TCP套接字这样的哑http服务器。
解决方法
您的Nginx服务器在/etc/nginx/nginx.conf中设置的字符集是什么？如果将其设置为不理解'ó'字符（最有可能是ASCII）的字符集，则它将尝试将图像加载为cintur303263n.jpg，当然该文件在您的文件系统上不存在，因此会显示损坏的图像。如果服务器或浏览器被明确告知预期的字符集，则它将使用适当的编码并正确显示图像。
,文件名通过URI进行通信，URI由ASCII字符而不是八位字节组成。 Http服务器和浏览器要求编码为ASCII，这与许多其他编码字符不兼容。为了使用任何其他编码，您需要使用ASCII字符和特定的转义机制对其进行编码。
RFC 2616定义了http语法，文件名在请求消息中作为URI传输。依次在RFC 1630中定义URI。像大多数HTTP语法一样，URI仅允许7位ASCII字符（定义为RFC 20）。
ASCII用7位定义了128个字符，剩余的位被浪费了：
为具体起见，我们建议使用嵌入在8位字节中的标准7位ASCII，其高位始终为0
这意味着包含ó字符的消息将被视为非法，或者指示该流未填充第8位。 因此，任意八位位组不能作为URI传输。
URI定义强加了进一步的限制，这使得使用多字节编码特别不安全。最重要的是，空格（十六进制20）在作为HTTP请求发送时被视为URI的开始和结尾，因此，如果一个字符被编码为多个八位字节，并且其中一个与ASCII编码的空格相同，则在获取该资源时会遇到麻烦。
为防止此类麻烦，Web浏览器转义了受保护的字符和非ascii字符。如URI标准所定义：
需要能够代表许多人之间存在冲突 字符，包括直接包含在URI中的空格，以及 能够在字符有限的环境中使用URI 设置或某些字符容易损坏。这个 通过使用十六进制转义来解决冲突 可以应用于给定中禁止的任何字符的方法 上下文。
百分号（“％”，ASCII 25十六进制）用作转义符 编码方案中的字符，绝对不允许 其他。
不安全字符
以规范形式，某些字符，例如空格，控制键
字符，某些字符的ASCII代码在
中使用的方式有所不同 不同的国家字符变体7位集，以及全部8bit
ISO Latin-1集的DEL（7F十六进制）以外的字符，不应为
使用未编码。
超出DEL（7F十六进制）的字符不能作为八位字节发送而没有表示形式，URI应该以书面，笔和纸的形式表示。
可以使用来表示任何URI 7位ASCII字符，以便URI可以 如有必要，请使用钢笔和墨水通过。
7位基本集的简单性用于此目的，URI是供人类理解的，而不仅仅是机器，因此它们不能被视为八位字节，它们是ASCII字符。
简而言之，URI应该由ASCII字符组成，如果要使用其他字符集，则应使用％（十六进制25）和所需八位字节的ASCII编码十六进制值进行转义。然后，http服务器将需要查找％并适当地读取以下两个八位字节，并将其转换为单个八位字节。这是如此不切实际和复杂，以至于最明智的解决方案是禁止在URI中使用非ASCII字符。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。