有趣的.gz压缩格式 和 一个JRE1.6的小bug

昨晚，学院一位待人非常和善的老师过来，聊了下之前确定下来帮忙处理的一个小分析---使用TBtools的 eGenomeWalking 功能，基于已知序列，从重测序数据中提取reads并延伸或者启动子区域。

由于是兰科的某个物种，杂合度极高，大概延伸到1.1Kb的时候，卡住啦。TBtools的eRace这个功能，只是利用了单端数据，我想想，那么可以通过双端reads，直接依据reads在当前延伸获得的序列上，用NNNNNN作为gap，bridge，那么就可以跳过某个确实深度很低或者低度重复过分的区域。

原本想想是比较简单的，一端延伸，没得延伸就提取另一端对应的reads，然后整理，那不就行了？然而，需要重现建库，需要转换14Gb的.gz文件为Fasta文件，然后才能建库。

于是呢，我打开TBtools（在JRE1.6的环境下），开始建库，但是光速啊，几秒钟就转换完，一看就知道有问题。于是开始debug...从昨晚直到现在....如何都找不到问题....

经过了各种纠结，我切换到JRE1.8尝试了下（为什么会切换？因为这个数据曾经正常转换过，其次，我已经被JRE1.6坑了几次，一些行为上，在JRE1.8和1.6下也是不一致），我LGDC，居然，居然就可以了。那么很有可能，就是JRE的问题。

于是，我google了一下，

真的是bug，在1.6的某个版本也是fixed了..........但是这个bug，又不是绝对的bug。

只是不能读取粗暴的，cat *.gz > merged.gz 得到的压缩文件而已，那么是上游数据提供者的问题，还是下游接收者的问题？

好，思考就到这里了。

曾经在某本书上看到，写代码要注意

“输入时开放，输出是严格”

大概意思是，

1. 对于指定的格式，用户可能在可以忽略的任何信息上忽略，可以添加的位置上添加，所以写解析类或者方法的时候，必须都考虑全面，而输出时，则尽可能注意权衡，大多数软件的接受程度，如newick tree的各种信息有无；

2. 我们永远无法判断用户的输入到底是不是按照某个格式来，所以最好是提供各种接口，接受各种输入格式，比如树文件上的newick，nexus, phylip... 比如简单的GO注释信息，geneID\tGO_1,GO_2...，后面的GO号到底是tab分隔，逗号分隔，还是space分隔，或者分号分隔，GO号是否有GO:这个前缀，此外，是一个geneID一行，还是一个geneID多行....而输出的时候，则要严格，按照最大众化，最常用，适用于大多数软件的输出，这个我也理解不透彻咯。

最后，也是今天推送最重要的部分了。

1. 使用软件，最后使用作者推荐的环境，比如jre1.6 那么就用1.6，比如jre1.8 那么就用1.8

2. 不要粗暴的直接 cat *.gz > merged.gz，尤其是测序服务提供公司，在返回数据的时候，不要这样操作。这样不能保证下游用户使用的软件支持这种格式。