从回车换行到字符编码

将csv数据导入mysql时发现一个有趣的问题
行段的结束符是以\r\n而非一贯的字符串思维中的换行为\n
于是乎就换行、回车整理了一些思路
网上的说法是这样的:
回车: Carriage Return
新行：New Line
Linux中\n表示回车+换行；
Windows中\r\n表示回车+换行。（文件以\r\n结尾）
Mac中\r表示回车+换行。
这也成为了不同系统下文件不能直接打开的原因之一

个人就windows下的情况进行了一些测试
当我们按下回车键时，实际上相当于输入了"\r\n"（nodepad++的扩展查找可以印证）
在开发环境中输入"\n"或"\r"时，
控制台输出都表现为换行，当我们从负责输出的控制台将结果复制出来时,发现对应的字符串中原本的"\n"或"\r"被转化为了"\r\n"
而当我们在开发环境中获取相对应的字符串时，或是直接在本地文本下或是在数据库中进行输出，依旧对应"\n"或"\r"
在Git Bash（Windows下的Linux模仿环境）中创建文本输入回车，最终Windows得到的文件为"\n"，复制粘贴出来转换为"\r\n"

下面是结论
1.Windows下剪切切板可以兼容任何类型的二进制编码所对应的字符，对于字符更是完全的复制粘贴，在对"\r"或"\n"的克隆时剪切板均视为"\r\n"，当然同样的字符在不同编码格式下对应的二进制编码不同
2.系统文件在跨平台的过程中，二进制编码不变，类型(假设不转格式)不变，将产生相同的字符，由于系统对回车字符的解释不同，导致文件可能无法正确执行。
3.对同一个系统的同一个二进制编码，以不同编码类型，这是乱码原因。
4.在编码转换过程中，以java web为例，我们获取的（请求参数）是二进制编码，同时获知它的编码格式（gb2312），
再以己方的编码格式（UTF-8）进行转换，达到字符相同（相当于复制粘贴过程），那么server中的文本从头到尾都以UTF-8编辑，最后在以UTF-8统一编译执行。