前言
最近在做交通优化分析工具的产品时，有一个需求是用户上传一份包含路段信息的csv文件，后端需要解析csv的文件内容并将信息插入数据库中。这是一个常规的操作，也不复杂，但是在实现的过程中却踩到了一个utf-8 BOM的坑，随手记录一下。
实现方式
完整的实现方式如下：
- 在spring中通过
MultipartFile file这个对象来接受前端传过来的文件 - 获取
file对象的InputStream输入流 - 将上一步的输入流和定义好的DTO对象传给opencsv的
CsvToBeanBuilder方法,CsvToBeanBuilder方法会自动解析输入流中的内容并生成对应的DTO List - 最后根据业务需求，生成相应的DO对象存入数据库
前面有坑
csv文件样例：
path_id,path_name
1,文一路
2,文二路DTO定义：
@Data
public class CsvDTO {
@CsvBindByName(column = " path_id", required = true)
private String pathId;
@CsvBindByName(column = "path_name")
private String pathName;
}其中,
@CsvBindByName注解中的require = true表明这是一个必须存在的字段
当我上传了这个样例文件后，代码报错了:
java.lang.RuntimeException: Error capturing CSV header!
...
Caused by: com.opencsv.exceptions.CsvRequiredFieldEmptyException: Header is missing required fields [PATH_ID]. The list of headers encountered is [ path_id,rid,path_name].我上传的csv文件里明明有path_id这个字段，为什么报的错是字段找不到。这个错误十分的迷惑，以至于我拼命的在找csv文件的首行有什么问题。
找了半天之后没有发现什么问题，于是我就换了个思路，毕竟csv文件只是用逗号分隔的纯文本，我可以自己手写一个csv文件，于是我在编辑器里敲了一个新的csv出来，重新上传。结果代码正常的跑完了，没有报错。
那么问题会在哪里
我分别用excel打开这2个csv文件，结果发现
一开始的样例文件
手打的csv文件
看到这样的结果想起来在Windows上经常遇到的文件乱码问题，原因是文件头不存在BOM，那时是用notepad++来转换格式：
那么我现在遇到的这个报错会不会是因为文件头存在BOM呢？
为了验证这个想法，我把服务器接收到的文件内容按字符打出来：
果真，文件的第一个字符不是p，而是\uFEFF，正是utf-8 BOM。
于是，这个问题的答案已经有了，我指定了path_id列必须存在，而opencsv按“逗号分隔”的标准定义，认为文件里有一列叫\uFEFFpath_id，却找不到path_id，于是就报错了。而报错的迷惑性在于\uFEFF是不可见字符，其实报错的时候有打出来，只是看不见而已：
The list of headers encountered is [ path_id,rid,path_name].
^ 看似空格，其实是\uFEFF解决问题
问题的原因已经找到，接下来就是如何解决这个问题，一般到这个时候的解决办法也不会太复杂，一种方法是每次读文件的时候做一个判断是否存在BOM，如果存在就去掉，然后把结果再交给opencsv处理。另一种方法是apache提供了一个BOMInputStream类，能自动识别是否存在BOM以及去除BOM：
// ...
BOMInputStream bomInputStream = new BOMInputStream(file.getInputStream());
new CsvToBeanBuilder(new InputStreamReader(bomInputStream))
// ...改完之后，服务器就能欢快的接收各种带BOM和不带BOM的文件了。
