文件在不同的平台传输的编码转换

1.文件存储在磁盘上都是二进制流，物理上都是存储的二进制。

2.文件分为两种：文本文件（ASCII）和二进制文件（Binary）。其实，文本文件是特殊的二进制文件，在磁盘上存储的依然是二进制，

只不过存储的二进制是用ASCII或Unicode进行了编码的二进制。

二进制文件用内存中一样的数据保存，保存在硬盘上就是二进制。

二进制文件和文本文件的区别在于：在打开的时候，程序对其内容的解释上。

例子：

在eclipse中建立一个文件，敲下a，按下ctrl+s，这时候文件是有一个编码的，是eclipse默认的编码，假设是UTF-8。

a的UTF-8编码是97，那么实际上在磁盘上面存储的是97的二进制形式1100001。当你使用eclipse打开这个文件时，eclipse的文本编辑器会做一个反向转换，将二进制编码转换为字符a。

为什么能够转换成功？因为文件有一个文件头记录了文件的原始编码，例子中就是UTF-8，eclipse也知道要被转换为的目标编码，默认是UTF-8，这样就能够转换成功。

不只是eclipse，任何的文本编辑器其实都是同一个道理，它在打开文件的时候，都会进行编码转换，当然在转换的时候可能出现乱码，因为编辑器目标编码与原始编码的编码表可能不是一一对应的。

遇到的问题：文件被zBuild从GitHub下载到z/OS上，文件的编码发生了什么样的转换？

Z/OS上的编码默认的是IBM-1047。zBuild知道了目标编码是IBM-1047，文件的原始编码是UTF-8，这样就可以将UTF-8转换成IBM-1047了。

注意：文件在不同的平台传输的时候（例如github到z/OS），编码转换只会在文本文件上面发生，对于二进制文件是不会发生任何编码转换的。

一些jar包以及zip包，通常被当做二进制文件对待，这样，对于jar包和zip包，不进行转换，以免在不同的平台中传输的时候，造成数据丢失。

通过在.gitattributes 文件中加入*.jar binary。可以让git将所有的jar包当做二进制文件，这样一来，在将github上的代码拉取到z/OS上的时候，二进制文件就不会被当做文本文件，从而不会发生编码转换，jar包就不会出现破坏，出现打不开的情况。