从LINUX移植过来的文件在KEIL下的使用需要注意的一个细节 Windows, LINUX, 换行符

m1_ljp

从LINUX移植过来的文件(.c和.h)在KEIL下使用时需要注意：

          这些文件在WINDOWS下以记事本打开时显示时不会正常显示回车换行，这是由于在Linux下的换行是\n，而在Windows下的换行是\r\n。而在KEIL下是无法看出的，一般只是表现为中文注释是乱码。结果是KEIL在模拟仿真时会出现问题。

         可将此文件用UE另存，在“换行符”一栏中选择DOS换行符即可在记事本打开显示时正确显示回车换行符！

网络搜索到的相关解释：

        在Linux下的换行是\n，而在Windows下的换行是\r\n。不经过处理的话，两者的文件在显示的时候会出现问题，比如一个Linux的文本文件用Windows记事本打开的时候不会换行格式很乱，一个Windows文件在Linux下用VI打开的话会出现^M字符等。

       TF-8编码的优点：
　　 UTF-8编码可以通过屏蔽位和移位操作快速读写。字符串比较时strcmp()和wcscmp()的返回

结果相同，因此使排序变得更加容易。字节FF和FE在UTF-8编码中永远不会出现，因此他们可以用来

表明UTF-16或UTF-32文本（见BOM） UTF-8 是字节顺序无关的。它的字节顺序在所有系统中都是一

样的，因此它实际上并不需要BOM。
　　 UTF-8编码的缺点：
　　 你无法从UNICODE字符数判断出UTF-8文本的字节数，因为UTF-8是一种变长编码它 需要用2

个字节编码那些用扩展ASCII字符集只需1个字节的字符 ISO Latin-1 是UNICODE的子集，但不是

UTF-8的子集 8位字符的UTF-8编码会被email网关过滤，因为internet信息最初设计为7为ASCII码。

因此产生了UTF-7编码。 UTF-8 在它的表示中使用值100xxxxx的几率超过50%， 而现存的实现如ISO

2022， 4873， 6429， 和8859系统，会把它错认为是C1控制码。因此产生了UTF-7.5编码。
　　 修正的UTF-8：
　　 java使用UTF-16表示内部文本，并支持用于字符串串行化的非标准的修正UTF-8编 码。标

准UTF-8和修正的UTF-8有两点不同：修正的UTF-8中，null字符编码成2个字节（11000000 10000000

） 而不是标准的1个字节（00000000），这样作可以保证编码后的字符串中不会嵌入null字符。因

此如果在类C语言中处理字符串，文本不会在第一个null字符时截断（C字符串以null结尾）。在标

准UTF-8编码中，超出基本多语言范围（BMP - Basic Multilingual Plain）的字符被编码为4字节

格式，但是在修正的UTF-8编码中，他们由代理编码对（surrogate pairs）表示，然后这些代理编

码对在序列中分别重新编码。结果标准UTF-8编码中需要4个字节的字符，在修正后的UTF-8编码中将

需要6个字节。