今天使用python处理一个txt文件的时候，遇到几个特殊字符：ufeff、xa0、u3000，记录一下处理方法
代码：
with open(file_path, mode='r') as f:
s = f.read()
1.ufeff 字节顺序标记
去掉ufeff，只需改一下编码就行，把UTF-8编码改成UTF-8-sig
with open(file_path, mode='r', encoding='UTF-8-sig') as f:
s = f.read()
2.xa0 是不间断空白符
xa0 是不间断空白符
我们通常所用的空格是 x20 ，是在标准ASCII可见字符 0x20~0x7e 范围内。
而 xa0 属于 latin1 （ISO/IEC_8859-1）中的扩展字符集字符，代表空白符nbsp(non-breaking space)。
latin1 字符集向下兼容 ASCII （ 0x20~0x7e ）。通常我们见到的字符多数是 latin1 的，比如在 MySQL 数据库中。
去除xa0
str.replace(u'xa0', u' ')
3.u3000 是全角的空白符
根据Unicode编码标准及其基本多语言面的定义， u3000 属于CJK字符的CJK标点符号区块内，是空白字符之一。它的名字是 Ideographic Space ，有人译作表意字空格、象形字空格等。顾名思义，就是全角的 CJK 空格。它跟 nbsp 不一样，是可以被换行间断的。常用于制造缩进， wiki 还说用于抬头，但没见过。
去除u3000
str.replace(u'u3000',u' ')
去除空格和xa0、u3000
title.strip().replace(u'u3000', u' ').replace(u'xa0', u' ')
ps:关于 ufeff 的一些资料（引自维基百科）：
字节顺序标记（英语：byte-order mark，BOM）是位于码点U+FEFF的统一码字符的名称。当以UTF-16或UTF-32来将UCS/统一码字符所组成的字符串编码时，这个字符被用来标示其字节序。它常被用来当做标示文件是以UTF-8、UTF-16或UTF-32编码的记号。
字符U+FEFF如果出现在字节流的开头，则用来标识该字节流的字节序，是高位在前还是低位在前。如果它出现在字节流的中间，则表达零宽度非换行空格的意义，用户看起来就是一个空格。从Unicode3.2开始，U+FEFF只能出现在字节流的开头，只能用于标识字节序，就如它的名称——字节序标记——所表示的一样；除此以外的用法已被舍弃。取而代之的是，使用U+2060来表达零宽度无断空白。
在UTF-16中，字节顺序标记被放置为文件或字符串流的第一个字符，以标示在此文件或字符串流中，以所有十六比特为单位的字码的尾序（字节顺序）。
如果十六比特单位被表示成大尾序，这字节顺序标记字符在序列中将呈现0xFE，其后跟着0xFF（其中的0x用来标示十六进制）。
如果十六比特单位使用小尾序，这个字节序列为0xFF，其后接着0xFE。
而统一码中，值为U+FFFE的码位被保证将不会被指定成一个统一码字符。这意味着0xFF、0xFE将只能被解释成小尾序中的U+FEFF（因为不可能是大尾序中的U+FFFE）。
UTF-8则没有字节顺序的议题。UTF-8编码过的字节顺序标记则被用来标示它是UTF-8的文件。它只用来标示一个UTF-8的文件，而不用来说明字节顺序。[1]许多视窗程序（包含记事本）会添加字节顺序标记到UTF-8文件。然而，在类Unix系统（大量使用文本文件，用于文件格式，用于进程间通信）中，这种做法则不被建议采用。因为它会妨碍到如解译器脚本开头的Shebang等的一些重要的码的正确处理。它亦会影响到无法识别它的编程语言。如gcc会报告源码档开头有无法识别的字符。而在PHP中，如果没有激活输出缓冲（output buffering），它会使得页面内容开始被送往浏览器（即：用户头文件已被提交），这使PHP脚本无法指定用户头文件（HTTP Header）。字节顺序标记在UTF-8中被表示为序列EF BB BF，对大部分未准备好处理UTF-8的文本编辑器及网页浏览器而言，在ISO-8859-1的环境中则会显示。
虽然字节顺序标记亦可以用于UTF-32，但这个编码很少用于传输，其规则如同UTF-16。对于已于IANA注册的字符集UTF-16BE、UTF-16LE、UTF-32BE和UTF-32LE等来说，不可使用字节顺序标记。文档开头的U+FEFF会被解释成一个（已舍弃的）"零宽度无断空白"，因为这些字符集的名字已决定了其字节顺序。对于已注册字符集UTF-16和UTF-32来说，一个开头的U+FEFF则用来表示字节顺序。
done!