背景：一家供应商打出二维码，经扫码解析后，发现空格有问题，微信扫出的有问题，支付宝扫出的就没问题，不知道啥原因，上网上找些资料，还真是出乎意料。
还 有一种会被显示为?的空格
在于UTF-8这种编码里面，存在一个特殊的字符，其编码是“0xC2 0xA0”，转换成字符的时候，表现为一个空格，跟一般的半角空格（ASCII 0x20）一样，唯一的不同是它的宽度不会被压缩，因此比较多的被用于网页排版（如首行缩进之类）。而其他的编码方式如GB2312、Unicode之类并没有这样的字符，因此如果简单地进行编码转换，生成地GB2312/Unocode字符串中，这个字符就会被替换成为问号（ASCII ox3F）。此时如果进行写库、写文件之类，就会把问号直接写入了。当然此时会有一种山寨方式：直接替换问号为空格。可是这种方法，会把原本真正的问号也枪毙掉。
使用UTF-8进行HTMLDecode的时候，对于语句开头的（ ），就会被自动转换成为这个特殊的空格，可能是判断为放在开头的空格，一定是用来排版的。在转换为其他编码之前，这个特殊的空格受到的待遇与普通的半角空格是一致的，甚至也会被trim()去掉。
因此，碰到这个问题的原因有两种：一种是在UTF-8编码下进行了转换，产生了这个字符；还有一种就是网页中直接采用了这个字符进行排版。
知道了具体原因，就有正规的解决方法了。方法就是：在得到UTF-8字符串之后，先进行一个替换，把这个特殊的空格替换为普通的空格，如果是HTML串，建议替换为（ ）。java代码如下：
byte[] space = new byte[]{(byte) 0xc2,(byte) 0xa0};
String UTFSpace =new String( space,"UTF-8" );
result=result.replaceAll(UTFSpace, " ");
这样做，就不会把串里面本来应该有的问号错误的替换为空格。也不会看到讨厌的问号，能保存原来字符串的真面目了。 需要强调的是，替换之前不能进行编码转换，一定要继续使用UTF-8编码。如果已经转换成其他编码，那么错误就已经不可逆转了。没有办法再区分这个错误的问号和正常的问号之间的差别了。
后来统一把空格替换为正常的空格
续：
HTML提供了5种空格实体（space entity），它们拥有不同的宽度，非断行空格（ ）是常规空格的宽度，可运行于所有主流浏览器。其他几种空格（       ‌‍）在不同浏览器中宽度各异。
它叫不换行空格，全称No-Break Space，它是最常见和我们使用最多的空格，大多数的人可能只接触了 ，它是按下space键产生的空格。在HTML中，如果你用空格键产生此空格，空格是不会累加的（只算1个）。要使用html实体表示才可累加，
该空格占据宽度受字体影响明显而强烈。
 
它叫“半角空格”，全称是En Space，en是字体排印学的计量单位，为em宽度的一半。根据定义，它等同于字体度的一半（如16px字体中就是8px）。名义上是小写字母n的宽度。此空格传承空格家族一贯的特性：透明的，此空格有个相当稳健的特性，
就是其占据的宽度正好是1/2个中文宽度，而且基本上不受字体影响。
 
它叫“全角空格”，全称是Em Space，em是字体排印学的计量单位，相当于当前指定的点数。例如，1 em在16px的字体中就是16px。此空格也传承空格家族一贯的特性：透明的，此空格也有个相当稳健的特性，
就是其占据的宽度正好是1个中文宽度，而且基本上不受字体影响。
 
它叫窄空格，全称是Thin Space。我们不妨称之为“瘦弱空格”，就是该空格长得比较瘦弱，身体单薄，占据的宽度比较小。它是em之六分之一宽。
‌
它叫零宽不连字，全称是Zero Width Non Joiner，简称“ZWNJ”，是一个不打印字符，放在电子文本的两个字符之间，抑制本来会发生的连字，而是以这两个字符原本的字形来绘制。Unicode中的零宽不连字字符映射为“”（zero width non-joiner，U+200C），HTML字符值引用为： ‌
‍
它叫零宽连字，全称是Zero Width Joiner，简称“ZWJ”，是一个不打印字符，放在某些需要复杂排版语言（如阿拉伯语、印地语）的两个字符之间，使得这两个本不会发生连字的字符产生了连字效果。零宽连字符的Unicode码位是U+200D (HTML: ‍ ‍）。
此外，浏览器还会把以下字符当作空白进行解析：空格（ ）、制表位（	）、换行（
）和回车（
）还有（　）等等。
