偶尔出现这个角色，我似乎无法在ascii表中找到它。我想在数据发送到数据库之前对数据进行过滤，但我必须先知道它是什么。也许有人可以告诉我。我正在使用一个所见即所得的编辑器，这就是它的来源。角色看起来很零星，但是当我做两个\ r或者退格时，它似乎经常出现。
这是角色
Â
好的，有人建议我在文档的头部更改内容类型为utf8，但我仍然在数据库中获取这些字符。这是我添加内容类型
后的测试adf af  aafd a a
aa a  afa aÂ
adf
答案 0 :(得分：16)
此字符很可能与UTF-8编码问题有关。在这个例子中，绝对建议阅读Joel的文章The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)。
在发送到数据库之前过滤掉这些字符几乎肯定是错误的。
在你提到的情况下，你可能正在处理字符U + 00A0，这是非中断空间的Unicode字符。该字符的位模式为：
1010 0000
在UTF-8编码之后，编码的字节看起来像
110x xxxx 10xx xxxx
其中'x'表示Unicode字符值的一位，因此U + 00A0编码为：
1100 0010 1010 0000
是0xC2 0xA0。巧合的是，第二个字符与您编码的原始字符（U + 00A0）的字节值相同，而第一个字符是您所看到的字符。
答案 1 :(得分：2)
这是一个“带有Circumflex的拉丁文资本A”，HTML代码ÂUnicodeU + 00C2
答案 2 :(得分：1)
当我遇到这个问题时，根据@ Greg的回答，对我有用的修复是：
0xC2 = 194,0xA0 = 160，
在php中：
$output=str_replace(chr(194).chr(160), " ", $html);
用Â重复 次。
答案 3 :(得分：0)
我是OP。我没有登录，但我回来分享解决方案。问题实际上是一个编码问题。我补充说：
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
在我这样做之后，我注意到我仍然在我的数据库中获得这些时髦的角色。然后我更改了数据库表上的编码，这也没有做任何事情。那只是离开了浏览器...我在浏览器中检查了编码并发现它使用的是ISO-8859-1。我将浏览器上的编码更改为utf-8，现在工作正常。 ：）
感谢所有贡献的人。
答案 4 :(得分：0)
我认为您看到的是我曾经遇到的错误。 ISO-8859-1实际上是西欧语言的Windows-1152（我认为它是1152）的一个子集。问题是，当Web服务器接受ISO-8859-1时，浏览器很乐意提交Windows-1152字符。这意味着浏览器发送的数据无效ISO-8859-1。至少在我的Windows安装中发生了这种情况。我在IE和Firefox中都看到过这种行为。
我遇到了一个wysiwyg编辑器的问题，用户会从Word文档中粘贴数据。本文档包含连字符和破折号。其中一个角色会被提交。另一个是垃圾，因为ISO-8859-1中不存在该字符（我永远不记得哪个是哪个）。
我们使用的.net框架也无济于事，因为它在转换为unicode时没有抱怨无效的ISO字符。