通常情况下，浏览器会通过以下三种的方式来设置解析网页时所使用的编码：

• 浏览器自带的编码工具或者插件
  • 原本 chrome 本身是自带有网页的编码工具的，但是从 chrome 55 开始这个工具就被移除了，但是现在有很多关于更改网页编码的 chrome 插件，都很好用

• 通过服务器 response 中 Content-type header 的 charset 属性

• 通过网页上所设置的 <meta charset="xxx"> 或者 <meta http-equiv="Content-Type" content="text/html; charset=xxx"> 
   

这三种方式的优先级为：自带的编码工具或者插件 > Content-type header > meta charse

所以说，不管服务器 response 中 Content-type header 的 charset 属性与网页上的 meta charset 的值是什么，只要通过浏览器自带的编码工具或插件来设置当前网页编码的话，浏览器就会强制使用编码工具或插件所设置的编码来解析网页内容，如果这个时候编码工具或插件所设置的编码与网页本身的编码不一致的话很有可能会出现乱码现象（之所有说是很有可能，因为包含在 ASCII 里的那些字符一般来说都会被其他常用的编码所兼容，所以英文字母一般来说是不会产生乱码现象的）。

假设说我有一个网页采用的是 UTF-8，但是我把这个网页所返回的 Contenty-type header 设置为： Content-Type: text/html; charset=GBK ，这时候即使我在这个网页上使用了 <meta charset="utf-8"/>  的话，浏览器仍然将会优先采用 GBK 来解析这个网页。

• 假设 Content-type 的 charset 不存在的话，其实 HTTP 协议是建议说这时候要把 charset 的默认值当成 ISO-8859-1。但是因为当前有一部分的服务器没有办法去设置或返回 Content-Type header 的 charset 的值， 所以对于大多数的浏览器或者说 agent 而言，在 charset 值为空的情况下是不会轻易去设定 charset 的默认值。
• 还有一个要注意，如果 Content-Type header 中 charset 的值是不合法的话（也就是不存在的 charset 值，比如说我随便将 charset 的值设置为 “abc”），在这种情况下，浏览器将会忽略这个 charset 值，这就跟 charset 值不存在是一样的。

在 Content-Type header 中 charset 的值不存在或者是不合法的编码的情况下，浏览器就会根据页面上的  <meta charset="utf-8"/>  中所指定的编码来解析页面的内容。

所以说，如果浏览器是直接打开本地的 HTML 页面的话，这个时候浏览器就是通过 meta charset 来判断页面所使用的编码的。

还有一种情况，如果 response 的 Content-Type 与 网页上的 meta 中都没有指定 charset 的话， 这个时候浏览器就会按照系统当前默认的编码来解析网页的内容。

• 不过如果是直接打开一个没有标注有 meta charset 的本地 HTML 文件的话，浏览器并不会按照系统当前默认的编码来解析网页的内容，我猜测它是直接根据 BOM 来判断当前 HTML 文件的编码。