’显示在我的页面上，而不是'。
我在标签和HTTP标头中都Content-Type设置了：UTF-8<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
另外，我的浏览器设置为Unicode (UTF-8)：
那么问题是什么，我该如何解决？
Answers:
确保浏览器和编辑器使用UTF-8编码而不是ISO-8859-1 / Windows-1252。
或使用’。
所以有什么问题，
这是一个’（RIGHT SINGLE QUOTATION MARK-U + 2019）字符，被解码为CP-1252而不是UTF-8。如果您检查编码表，那么你看到的这个人物是UTF-8字节组成的0xE2，0x80和0x99。如果检查CP-1252代码页的布局，则会看到每个字节代表各个字符â，€而™。
以及如何解决？
使用UTF-8代替CP-1252来读取，写入，存储和显示字符。
我在
<head>代码和HTTP标头中都将Content-Type设置为UTF-8 ：<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
这仅指示客户端使用哪种编码来解释和显示字符。这不会指示您自己的程序使用哪种编码来读取，写入，存储和显示字符。确切的答案取决于所使用的服务器端平台/数据库/编程语言。请注意，HTTP响应标头中的一组优先于HTML meta标记。仅当从本地磁盘文件系统而不是从HTTP打开页面时，才使用HTML元标记。
此外，我的浏览器设置为
Unicode (UTF-8)：
这仅强制客户端使用哪种编码来解释和显示字符。但是实际的问题是您已经’在向客户端发送（以UTF-8编码）了’。客户端’使用UTF-8编码正确显示。如果客户端被误导使用，例如ISO-8859-1，您可能会看到ââ¬â¢。
我正在将ASP.NET 2.0与数据库一起使用。
这很可能是您的问题所在。您需要使用独立的数据库工具来验证数据的外观。
如果 ’字符，则说明您未正确连接到数据库。您需要告诉数据库连接器使用UTF-8。
如果您的数据库包含’，那么就是您的数据库搞砸了。这些表很可能未配置为使用UTF-8。而是使用数据库的默认编码，该默认编码随配置而异。如果这是您的问题，那么通常只需更改表以使用UTF-8就足够了。如果您的数据库不支持该功能，则需要重新创建表。创建表时，最好设置表的编码。
您最有可能使用SQL Server，但这是一些MySQL代码（从本文复制）：
CREATE DATABASE db_name CHARACTER SET utf8;
CREATE TABLE tbl_name (...) CHARACTER SET utf8;
但是，如果您的表已经是UTF-8，则需要退后一步。谁或什么将数据放在那里。那就是问题所在。一个示例是HTML表单提交的值，该值被错误地编码/解码。
以下是一些更多链接，以了解有关此问题的更多信息：
我有一些文档…显示为…和ê正在显示为ê。这是它到达那里的方式（python代码）：
# Adam edits original file using windows-1252
windows = '\x85\xea'
# that is HORIZONTAL ELLIPSIS, LATIN SMALL LETTER E WITH CIRCUMFLEX
# Beth reads it correctly as windows-1252 and writes it as utf-8
utf8 = windows.decode("windows-1252").encode("utf-8")
print(utf8)
# Charlie reads it *incorrectly* as windows-1252 writes a twingled utf-8 version
twingled = utf8.decode("windows-1252").encode("utf-8")
print(twingled)
# detwingle by reading as utf-8 and writing as windows-1252 (it's really utf-8)
detwingled = twingled.decode("utf-8").encode("windows-1252")
assert utf8==detwingled为了解决这个问题，我使用了如下的python代码：
with open("dirty.html","rb") as f:
dt = f.read()
ct = dt.decode("utf8").encode("windows-1252")
with open("clean.html","wb") as g:
g.write(ct)（因为有人将闪烁的版本插入了正确的UTF-8文档中，所以我实际上只提取了闪烁的部分，将其展开并重新插入。为此，我使用了BeautifulSoup。）
比起Web服务器配置错误，您更有可能在内容创建过程中拥有Charlie。您还可以通过为utf-8文档选择Windows-1252编码来强制Web浏览器闪烁页面。您的网络浏览器无法整理Charlie保存的文档。
注意：任何其他单字节代码页（例如latin-1）而不是Windows-1252都可能发生相同的问题。
’（Unicode codepoint U+2019 RIGHT SINGLE QUOTATION MARK）以UTF-8编码为字节：
0xE2 0x80 0x99。
’（Unicode代码点U+00E2 U+20AC U+2122）以UTF-8编码为字节：
0xC3 0xA2 0xE2 0x82 0xAC 0xE2 0x84 0xA2。
这些是您的浏览器实际接收的字节，以便’在以UTF-8处理时产生。
这意味着您的源数据正在通过 在发送到浏览器之前两次字符集转换：
来源 ’字符（U+2019）首先被编码为UTF-8字节：
0xE2 0x80 0x99
然后，这些单个字节被其中之一误解并解码为Unicode代码点U+00E2 U+20AC U+2122。 Windows-125X字符集 1252、1254、1256和1258全部映射0xE2 0x80 0x99到U+00E2 U+20AC U+2122），然后这些代码点被编码为UTF-8字节：
0xE2-> U+00E2-> 0xC3 0xA2
0x80-> U+20AC->0xE2 0x82 0xAC
0x99 -> U+2122->0xE2 0x84 0xA2
您需要找到在步骤2中执行额外转换的位置并将其删除。
两次将字符串从Windows-1252转换为UTF-8时，有时会发生这种情况。
我们在Zend / PHP / MySQL应用程序中有此功能，其中类似的字符出现在数据库中，可能是由于MySQL连接未指定正确的字符集。我们不得不：
确保Zend和PHP正在UTF-8中与数据库通信（默认情况下未启用）
像这样用几个SQL查询修复损坏的字符...
UPDATE MyTable SET
MyField1 = CONVERT(CAST(CONVERT(MyField1 USING latin1) AS BINARY) USING utf8),
MyField2 = CONVERT(CAST(CONVERT(MyField2 USING latin1) AS BINARY) USING utf8);
根据需要对尽可能多的表/列执行此操作。
您也可以根据需要在PHP中修复其中一些字符串。请注意，由于字符已被编码两次，所以实际上我们需要从 UTF-8 反向转换回Windows-1252，这首先使我感到困惑。
mb_convert_encoding('’', 'Windows-1252', 'UTF-8'); // returns ’
您的字符编码不匹配；您的字符串使用一种编码（UTF-8）进行编码，而解释此页面的任何内容都使用另一种编码（例如ASCII）。
始终在http标头中指定编码，并确保此编码与框架的编码定义匹配。
示例HTTP标头：
Content-Type text/html; charset=utf-8
<configuration>
<system.web>
<globalization
fileEncoding="utf-8"
requestEncoding="utf-8"
responseEncoding="utf-8"
culture="en-US"
uiCulture="de-DE"
/>
</system.web>
</configuration>如果有人在WordPress网站上遇到此错误，则需要更改wp-config db charset：
define('DB_CHARSET', 'utf8mb4_unicode_ci');
代替：
define('DB_CHARSET', 'utf8mb4');
您必须具有从Word Document复制/粘贴文本的功能。Word文档使用智能引号。您可以将其替换为特殊字符（＆rsquo;）或直接在HTML编辑器中键入（'）。
我确定这可以解决您的问题。