关于u8BOM，LF,CRLF的认知。

首先说下遇到的问题。

工作需要，有一个json文件需要被签名后使用。

当时为了开发方便用记事本另存为u8然后签名，校验通过，用git push 到repository。

        这时候问题来了，发现本地build出来的apk对json文件签名的校验是没问题的，但是jenkins build出来的就是无法识别json文件的签名。

         来回的折腾后首先发现在linux下用vi打开会看到<FEFF>的标签。这个就是所谓的BOM。先来看下百度百科对BOM的定义：

Unicode规范中的BOM
Unicode规范中有一个BOM的概念。BOM——Byte Order Mark，就是字节序标记。在这里找到一段关于BOM的说明：
在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。
UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。
Windows就是使用BOM来标记文本文件的编码方式的。

UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的EF BB BF了。
这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。
可是，还是有很多软件不能识别BOM。

        也就是说，我当时用记事本另存为的u8 是带BOM的u8。这样以来提交上去的文件是带了BOM，在做签名校验的时候当然就会出问题了。

        于是在linux下cp了一份，去掉BOM然后提交jenkins的就可以通过签名校验了。

         什么？你以为故事到这里就结束了？耐心往下看~

         文件push上去之后，本地同步了代码，于是本地签名校验不过了。wtf。

         又折腾了半天，本地重新签名扔进去发现git可以被识别，然后add.commit.push. WTF！居然没识别有东西提交？！

         切新分支，再来一次，commit的时候发现有LF和CRLF的提醒。所以你们懂了，问题就出现在这里。

         首先来看下LF和CRLF。

在各操作系统下，文本文件所使用的换行符是不一样的。UNIX/Linux 使用的是 0x0A（LF），早期的 Mac OS 使用的是0x0D（CR），后来的 OS X 在更换内核后
与 UNIX 保持一致了。但 DOS/Windows 一直使用 0x0D0A（CRLF）作为换行符。Git提供了一个“换行符自动转换”功能。这个功能默认处于“自动模式”，当你
在签出文件时，它试图将 UNIX 换行符（LF）替换为 Windows 的换行符（CRLF）；当你在提交文件时，它又试图将 CRLF 替换为 LF。Git 的“换行符自动转换”功能听起来似乎很智能、很贴心，因为它试图一方面保持仓库内文件的一致性（UNIX 风格），一方面又保证本地
文件的兼容性（Windows 风格）。但遗憾的是，这个功能是有 bug 的，而且在短期内都不太可能会修正。

         这样以来。linux提交上去的/n的文件，在我pull下来之后会变成/r/n。签名校验当然过不去了。

         解决方案：暂无完美解决方案。我可以通过

         

    git config --global core.autocrlf false

         或者通过修改gitconfig来关掉自动转换，达到我当前的目的，可是一旦有人同时在linux环境下进行同文件的修改，就包含两种了。就会导致两边都不能用的问题。wtf。 

          所以暂时的方案是本地留存了json文件做build，不做提交。

         巨坑！有大佬知道完美解决方案的话可以交流交流。