重入性和不可重入性

使用可重入函数进行更安全的信号处理
何时如何利用可重入性避免代码出现 bug
如
果要对函数进行并发访问，不管是通过线程还是通过进程，您都可能会遇到函数不可重入所导致的问题。在本文中，通过示例代码了解如果可重入性不能得到保证会产生何种异常，尤其要注意信号。引入了五条可取的编程经验，并对提出的编译器模型进行了讨论，在这个模型中，可重入性由编译器前端处理。
在早期的编程中，不可重入性对程序员并不构成威胁；函数不会有并发访问，也没有中断。在很多较老的
C 语言实现中，函数被认为是在单线程进程的环境中运行。
不过，现在，并发编程已普遍使用，您需要意识到这个缺陷。本文描述了在并行和并发程序设计中函数的不可重入性导致的一些潜在问题。信号的生成和处理尤其增加了额外的复杂性。由于信号在本质上是异步的，所以难以找出当信号处理函数触发某个不可重入函数时导致的
bug。
本文：
定义了可重入性，并包含一个可重入函数的 POSIX 清单。
给出了示例，以说明不可重入性所导致的问题。
指出了确保底层函数的可重入性的方法。
讨论了在编译器层次上对可重入性的处理。
什么是可重入性？
可
重入（reentrant）函数可以由多于一个任务并发使用，而不必担心数据错误。相反，不可重入（non-reentrant）函数不能由超过一个任务所共享，除非能确保函数的互斥（或者使用信号量，或者在代码的关键部分禁用中断）。可重入
函数可以在任意时刻被中断，稍后再继续运行，不会丢失数据。可重入函数要么使用本地变量，要么在使用全局变量时保护自己的数据。
可重入函数：
不为连续的调用持有静态数据。
不返回指向静态数据的指针；所有数据都由函数的调用者提供。
使用本地数据，或者通过制作全局数据的本地拷贝来保护全局数据。
绝不调用任何不可重入函数。
不要混淆可重入与线程安全。在程序员看来，这是两个独立的概念：函数可以是可重入的，是线程安全的，或者二者皆是，或者二者皆非。不可重入的函数不能由多个线程使用。另外，或许不可能让某个不可重入的函数是线程安全的。
IEEE Std 1003.1 列出了 118 个可重入的 UNIX®
函数，在此没有给出副本。参见 参考资料 中指向 unix.org 上此列表的链接。
出于以下任意某个原因，其余函数是不可重入的：
它们调用了 malloc 或 free。
众所周知它们使用了静态数据结构体。
它们是标准 I/O 程序库的一部分。
信号和不可重入函数
信号（signal）
是软件中断。它使得程序员可以处理异步事件。为了向进程发送一个信号，内核在进程表条目的信号域中设置一个位，对应于收到的信号的类型。信号函数的
ANSI C 原型是：
void (*signal (int sigNum, void (*sigHandler)(int))) (int);
或者，另一种描述形式：
typedef void sigHandler(int);
SigHandler *signal(int, sigHandler *);
当进程处理所捕获的信号时，正在执行的正常指令序列就会被信号处理器临时中断。然后进程继续执行，但现在执行的是信号处理器中的指令。如果信号处理器返回，则进程继续执行信号被捕获时正在执行的正常的指令序列。
现
在，在信号处理器中您并不知道信号被捕获时进程正在执行什么内容。如果当进程正在使用
malloc 在它的堆上分配额外的内存时，您通过信号处理器调用
malloc，那会怎样？或者，调用了正在处理全局数据结构的某个函数，而在信号处理器中又调用了同一个函数。如果是调用
malloc，则进程会被严重破坏，因为 malloc
通常会为所有它所分配的区域维持一个链表，而它又可能正在修改那个链表。
甚至可以在需要多个指令的 C
操作符开始和结束之间发送中断。在程序员看来，指令可能似乎是原子的（也就是说，不能被分割为更小的操作），但它可能实际上需要不止一个处理器指令才能完成操作。例如，看这段
C 代码：
temp += 1;
在 x86 处理器上，那个语句可能会被编译为：
mov ax,[temp]
inc ax
mov [temp],ax
这显然不是一个原子操作。
这个例子展示了在修改某个变量的过程中运行信号处理器可能会发生什么事情：
清单 1. 在修改某个变量的同时运行信号处理器
#include <signal.h>
#include <stdio.h>
struct two_int
{
int a, b;
}
data;
void signal_handler(int signum)
{
printf ("%d, %d\n", data.a, data.b);
alarm (1);
}
int main (void)
{
static struct two_int
zeros = { 0, 0 },
ones = { 1, 1 };
signal (SIGALRM, signal_handler);
data = zeros;
alarm (1);
while (1)
{
data = zeros;
data = ones;
}
}
这个程序向 data 填充 0，1，0，1，一直交替进行。同时，alarm
信号处理器每一秒打印一次当前内容（在处理器中调用 printf
是安全的，当信号发生时它确实没有在处理器外部被调用）。您预期这个程序会有怎样的输出？它应该打印
0,0 或者 1,1。但是实际的输出如下所示：
0, 0 1, 1 (Skipping some output...) 0, 1 1, 1 1, 0 1, 0 ...
在 大部分机器上，在 data
中存储一个新值都需要若干个指令，每次存储一个字。如果在这些指令期间发出信号，则处理器可能发现
data.a 为 0 而 data.b 为
1，或者反之。另一方面，如果我们运行代码的机器能够在一个不可中断的指令中存储一个对象的值，那么处理器将永远打印
0,0 或 1,1。
使用信号的另一个新增的困难是，只通过运行测试用例不能够确保代码没有信号
bug。这一困难的原因在于信号生成本质上异步的。
不可重入函数和静态变量
假定信号处理器使用了不可重入的
gethostbyname。这个函数将它的值返回到一个静态对象中：
static struct hostent host;
/* result stored here*/
它每次都重新使用同一个对象。在下面的例子中，如果信号刚好是在 main 中调用
gethostbyname
期间到达，或者甚至在调用之后到达，而程序仍然在使用那个值，则它将破坏程序请求的值。
清单 2. gethostbyname 的危险用法
main()
{
struct hostent *hostPtr;
signal(SIGALRM, sig_handler);
hostPtr = gethostbyname(hostNameOne);
}
void sig_handler()
{
struct hostent *hostPtr;
/* call to gethostbyname may clobber the value stored during the
call inside the main() */
hostPtr = gethostbyname(hostNameTwo);
}
不过，如果程序不使用 gethostbyname
或者任何其他在同一对象中返回信息的函数，或者如果它每次使用时都会阻塞信号，那么就是安全的。
很多库函数在固定的对象中返回值，总是使用同一对象，它们全都会导致相同的问题。如果某个函数使用并修改了您提供的某个对象，那它可能就是不可重入的；如果两个调用使用同一对象，那么它们会相互干扰。
当使用流（stream）进行 I/O 时会出现类似的情况。假定信号处理器使用 fprintf
打印一条消息，而当信号发出时程序正在使用同一个流进行 fprintf
调用。信号处理器的消息和程序的数据都会被破坏，因为两个调用操作了同一数据结构：流本身。
如果使用第三方程序库，事情会变得更为复杂，因为您永远不知道哪部分程序库是可重入的，哪部分是不可重入的。对标准程序库而言，有很多程序库函数在固定的对象中返回值，总是重复使用同一对象，这就使得那些函数不可重入。
近来很多提供商已经开始提供标准 C
程序库的可重入版本，这是一个好消息。对于任何给定程序库，您都应该通读它所提供的文档，以了解其原型和标准库函数的用法是否有所变化。
确保可重入性的经验
理解这五条最好的经验将帮助您保持程序的可重入性。
经验 1
返回指向静态数据的指针可能会导致函数不可重入。例如，将字符串转换为大写的
strToUpper 函数可能被实现如下：
清单 3. strToUpper 的不可重入版本
char *strToUpper(char *str)
{
/*Returning pointer to static data makes it non-reentrant */
static char buffer[STRING_SIZE_LIMIT];
int index;
for (index = 0; str[index]; index++)
buffer[index] = toupper(str[index]);
buffer[index] = '\0';
return buffer;
}
通过修改函数的原型，您可以实现这个函数的可重入版本。下面的清单为输出准备了存储空间：
清单 4. strToUpper 的可重入版本
char *strToUpper_r(char *in_str, char *out_str)
{
int index;
for (index = 0; in_str[index] != '\0'; index++)
out_str[index] = toupper(in_str[index]);
out_str[index] = '\0';
return out_str;
}
由进行调用的函数准备输出存储空间确保了函数的可重入性。注意，这里遵循了标准惯例，通过向函数名添加"_r"后缀来命名可重入函数。
经验 2
记忆数据的状态会使函数不可重入。不同的线程可能会先后调用那个函数，并且修改那些数据时不会通知其他正在使用此数据的线程。如果函数需要在一系列调用期间维持某些数据的状态，比如工作缓存或指针，那么调用者应该提供此数据。
在下面的例子中，函数返回某个字符串的连续小写字母。字符串只是在第一次调用时给出，如
strtok 子例程。当搜索到字符串末尾时，函数返回 \0。函数可能如下实现：
清单 5. getLowercaseChar 的不可重入版本
char getLowercaseChar(char *str)
{
static char *buffer;
static int index;
char c = '\0';
/* stores the working string on first call only */
if (string != NULL)
{
buffer = str; index = 0;
}
/* searches a lowercase character */
while(c=buff[index])
{
if(islower(c))
{
index++;
break;
}
index++;
}
return c;
}
这个函数是不可重入的，因为它存储变量的状态。为了让它可重入，静态数据，即
index，需要由调用者来维护。此函数的可重入版本可能类似如下实现：
清单 6. getLowercaseChar 的可重入版本
char getLowercaseChar_r(char *str, int *pIndex)
{
char c = '\0';
/* no initialization - the caller should have done it */
/* searches a lowercase character */
while(c=buff[*pIndex])
{
if(islower(c))
{
(*pIndex)++;
break;
}
(*pIndex)++;
}
return c;
}
经验 3
在大部分系统中，malloc 和 free
都不是可重入的，因为它们使用静态数据结构来记录哪些内存块是空闲的。实际上，任何分配或释放内存的库函数都是不可重入的。这也包括分配空间存储结果的函数。
避
免在处理器分配内存的最好方法是，为信号处理器预先分配要使用的内存。避免在处理器中释放内存的最好方法是，标记或记录将要释放的对象，让程序不间断地检查是否有等待被释放的内存。不过这必须要小心进行，因为将一个对象添加到一个链并不是原子操作，如果它被另一个做同样动作的信号处理器打断，那么就会"丢失"一个对象。不过，如果您知道当信号可能到达时，程序不可能使用处理器那个时刻所使用的流，那么就是安全的。如果程序使用的是某些其他流，那么也不会有任何问题。
经验 4
为了编写没有 bug 的代码，要特别小心处理进程范围内的全局变量，如 errno 和
h_errno。考虑下面的代码：
清单 7. errno 的危险用法
if (close(fd) < 0)
{
fprintf(stderr, "Error in close, errno: %d", errno);
exit(1);
}
假定信号在 close 系统调用设置 errno
变量到其返回之前这一极小的时间片段内生成。这个生成的信号可能会改变 errno
的值，程序的行为会无法预计。
如下，在信号处理器内保存和恢复 errno 的值，可以解决这一问题：
清单 8. 保存和恢复 errno 的值
void signalHandler(int signo)
{
int errno_saved;
/* Save the error no. */
errno_saved = errno;
/* Let the signal handler complete its job */ ... ...
/* Restore the errno*/
errno = errno_saved;
}
经验 5
如果底层的函数处于关键部分，并且生成并处理信号，那么这可能会导致函数不可重入。通过使用信号设置和信号掩码，代码的关键区域可以被保护起来不受一组特定信号的影响，如下：
保存当前信号设置。
用不必要的信号屏蔽信号设置。
使代码的关键部分完成其工作。
最后，重置信号设置。
下面是此方法的概述：
清单 9. 使用信号设置和信号掩码
sigset_t newmask, oldmask, zeromask; ...
/* Register the signal handler */
signal(SIGALRM, sig_handler);
/* Initialize the signal sets */
sigemtyset(&newmask);
sigemtyset(&zeromask);
/* Add the signal to the set */
sigaddset(&newmask, SIGALRM);
/* Block SIGALRM and save current signal mask in set variable
'oldmask' */
sigprocmask(SIG_BLOCK, &newmask, &oldmask);
/* The protected code goes here ... ... */
/* Now allow all signals and pause */
sigsuspend(&zeromask);
/* Resume to the original signal mask */ s
igprocmask(SIG_SETMASK, &oldmask, NULL);
/* Continue with other parts of the code */
忽略 sigsuspend(&zeromask);
可能会引发问题。从消除信号阻塞到进程执行下一个指令之间，必然会有时钟周期间隙，任何在此时间窗口发生的信号都会丢掉。函数调用
sigsuspend
通过重置信号掩码并使进程休眠一个单一的原子操作来解决这一问题。如果您能确保在此时间窗口中生成的信号不会有任何负面影响，那么您可以忽略
sigsuspend 并直接重新设置信号。
在编译器层次处理可重用性
我将提出一个在编译器层次处理可重入函数的模型。可以为高级语言引入一个新的关键字：
reentrant，函数可以被指定一个 reentrant 标识符，以此确保函数可重入，比如：
reentrant int foo();
此指示符告知编译器要专门处理那个特殊的函数。编译器可以将这个指示符存储在它的符号表中，并在中间代码生成阶段使用这个指示符。为达到此目的，编译器的前端设计需要有一些改变。此可重入指示符遵循这些准则：
不为连续的调用持有静态数据。
通过制作全局数据的本地拷贝来保护全局数据。
绝对不调用不可重入的函数。
不返回对静态数据的引用，所有数据都由函数的调用者提供。
准则 1
可以通过类型检查得到保证，如果在函数中有任何静态存储声明，则抛出错误消息。这可以在编译的语法分析阶段完成。
准 则
2，全局数据的保护可以通过两种方式得到保证。基本的方法是，如果函数修改全局数据，则抛出一个错误消息。一种更为复杂的技术是以全局数据不被破坏的方式生成中间代码。可以在编译器层实现类似于前面经验
4
的方法。在进入函数时，编译器可以使用编译器生成的临时名称存储将要被操作的全局数据，然后在退出函数时恢复那些数据。使用编译器生成的临时名称存储数据对编译器来说是常用的方法。
确保准则 3
得到满足，要求编译器预先知道所有可重入函数，包括应用程序所使用的程序库。这些关于函数的附加信息可以存储在符号表中。
最后，准则 4 已经得到了准则 2
的保证。如果函数没有静态数据，那么也就不存在返回静态数据的引用的问题。
提出的这个模型将简化程序员遵循可重入函数准则的工作，而且使用此模型可以预防代码出现无意的可重入性
bug。

UTF-8、Unicode和BOM问题

经常遇到的问题是，使用了BOM编码后，脚本执行错误，或使用fileStream读取并转换为XML会报错"The
markup in the document following the root element must be well-formed."。
一、介绍
UTF-8 是一种在web应用中经常使用的一种 Unicode 字符的编码方式，使用
UTF-8 的好处在于它是一种变长的编码方式，对于 ANSII
码编码长度为1个字节，这样的话在传输大量 ASCII
字符集的网页时，可以大量节约网络带宽。
UTF-8签名（UTF-8 signature）也叫做BOM（Byte Order
Mark），是UTF编码方案里用于标识编码的标准标记。BOM，是UTF编码方案里用于标识编码的标准标记，在UTF-16里本来是FF
FE，变成UTF-8就成了EF BB
BF。这个标记是可选的，因为UTF8字节没有顺序，所以它可以被用来检测一个字节流是否是UTF-8编码的。微软做这种检测，但有些软件不做这种检测，而把它当作正常字符处理。微软在自己的UTF-8格式的文本文件之前加上了EF
BB BF三个字节,
windows上面的notepad等程序就是根据这三个字节来确定一个文本文件是ASCII的还是UTF-8的,
然而这个只是微软暗自作的标记,
其它平台上并没有对UTF-8文本文件做个这样的标记。也就是说一个UTF-8文件可能有BOM，也可能没有BOM。
只有一个BOM，是不会有问题的。如果多个文件设置了签名，在二进制流中就会包含多个UTF-8签名，也就是导致XML转换失败的"root
element must be well-formed"原因。
二、查看和转换
既然一个UTF-8文件可能有BOM，也可能没有，那该如何区分呢？
只要用带十六进制编辑方式的软件，例如，用UltraEdit-32打开文件，切换到十六进制编辑模式，察看文件头部是否有EF
BB BF。有，则为带BOM方式。
Windows自带的notepad记事本，保存为UTF-8时，默认就带BOM。
转换的方法有很多，常见的UltraEdit-32或NotePad++都可以，以UltraEdit-32为例。打开文件后，选择"另存为"，在"格式"一栏中有如下选择：
另外，DreamWeaver CS3也有类似的选项，在"首选项"中，如果选择 Unicode
(UTF-8) 作为默认编码，则可以选择"包括 Unicode 签名
(BOM)"选项，以在文档中包括字节顺序标记 (BOM)。否则，不带BOM：
三、其他知识
所谓的unicode保存的文件实际上是utf-16，只不过恰好跟unicode的码相同而已,但在概念上unicode与utf是两回事，unicode是内存编码表示方案，而utf是如何保存和传输unicode的方案。utf-16还分高位在前
(LE)和高位在后(BE)两种。官方的utf编码还有utf-32，也分LE和BE。非unicode官方的utf编码还有utf-7，主要用于邮件传输。utf-8的单字节部分是和iso-8859-1兼容的，这主要是一些旧的系统和库函数不能正确处理utf-16而被迫出来的，而且对英语字符来说，也节省保存的文件空间（以非英语字符浪费空间为代价）。在iso-8859-1的时候，utf8和iso-8859-1都是用一个字节表示的，当表示其它字符的时候，utf-8会使用两个或三个字节。
一段关于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来标记文本文件的编码方式的。
PHP也不支持BOM。
PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。由于必须在<?或者<?php后面的代码才会作为PHP代码执行，所以这三个字符将会直接输出。如果插件的文件有这个问题，将会导致在后台页面里激活或者不激活插件后显示白屏，如果是模版文件有这个问题，将会导致这三个字符直接输出，造成页面上方有一个小空行。国外的英文插件和模版一般都是用的ASCII码的编码方式，不会有BOM，只有国内的插件和模版会由于作者的不知情造成问题。还有，大家修改模版的时候，由于输出页面使用UTF-8编码，那么修改模版的时候如果有加入中文字符的话，必须把文件转成UTF-8编码才能正常显示，这个时候如果所使用的编辑器自动加上了BOM的话，将会造成在页面上输出这三个字符，显示效果就要看浏览器了，一般是一个空行或是一个乱码。

UNICODE与ANSI的区别

什么是ANSI，什么又是UNICODE呢？其实这是两种不同的编码方式标准，ANSI中的字符采用8bit，而UNICODE中的字符采用16bit。（对于字符来说ANSI以单字节存放英文字符，以双字节存放中文等字符,而Unicode下，英文和中文的字符都以双字节存放）Unicode码也是一种国际标准编码，采用二个字节编码，与ANSI码不兼容。目前，在网络、Windows系统和很多大型软件中得到应用。8bit的ANSI编码只能表示256种字符，表示26个英文字母是绰绰有余的，但是表示汉字，韩国语等有着成千上万个字符的非西方字符肯定就不够了，正是如此才引入了UNICODE标准。
在软件开发中，特别是使用C语言的一些有关字符串处理的函数，ANSI和UNICODE是区分是用的，那么ANSI类型的字符和UNICODE类型的字符如何定义，如何使用呢？ANSI和UNICODE又如何转换呢？
一．定义部分：
ANSI：char str[1024]; 可用字符串处理函数：strcpy( ), strcat( ),
strlen( )等等。
UNICODE：wchar_t str[1024]；可用字符串处理函数
二．可用函数：
ANSI：即char，可用字符串处理函数：strcat( ),strcpy( ), strlen(
)等以str打头的函数。
UNICODE：即wchar_t
可用字符串处理函数：wcscat(),wcscpy(),wcslen()等以wcs打头的函数。
三．系统支持
Windows 98 ：只支持ANSI。
Windows 2k ：既支持ANSI又支持UNICODE。
Windows CE ：只支持UNICODE。
说明
1 在COM里面只支持UNICODE。
2．Windows 2000整个OS系统都是基于UNICODE的，为此在windows 2000
下使用ANSI是需要付出代价的，虽然在编码上不用任何的转换，但是这种转化是隐藏的，是占用系统资源的（CPU，内存）。
3 在Windows 98下必须使用UNICODE，则需要自己手动的编码切换。
四．如何区分：
在我们软件开发中往往需要即支持ANSI又支持UNICODE，不可能在要求类型转换的时候，重新改变字符串的类型，和使用于字符串上的操作函数。为此,
标准C运行期库和Windows 提供了宏定义的方式。
在C语言里面提供了
_UNICODE宏（有下划线），在Windows里面提供了UNICODE宏（无下划线），只要定了_UNICODE宏和UNICODE宏，系统就会自动切换到UNICODE版本，否则，系统按照ANSI的方式进行编译和运行。
只定义了宏并不能实现自动的转换，他还需要一系列的字符定义支持。
1. TCHAR
如果定义了UNICODE宏则TCHAR被定义为wchar_t。
typedef wchar_t TCHAR;
否则TCHAR被定义为char
typedef char TCHAR;
2．LPTSTR
如果定义了UNICODE宏则LPTSTR被定义为LPWSTR。（以前一直不知道LPWSTR是什么东东，终于明白了）
typedef LPTSTR LPWSTR;
否则TCHAR被定义为char
typedef LPTSTR LPSTR;
补充一下：
UTF-8是可以用于真正的流式传输的，Unicode是一种编码方案
我的理解是UTF-8是Unicode的一种具体实现。类似的实现还有UTF－16等等。

UTF-8文件的Unicode签名BOM(Byte Order Mark)问题

近日在调测一个UTF8编码的中文Zen
Cart网站时遇到一件怪事，网页显示文字正常，用ie的察看源文件（记事本打开）却发现乱码，firefox没有这个问题。经在网上多方查证和多次测试，解决了这个问题，其实是UTF-8文件的Unicode签名BOM(Byte
Order Mark)问题。
BOM(Byte Order
Mark)，是UTF编码方案里用于标识编码的标准标记，在UTF-16里本来是FF
FE，变成UTF-8就成了EF BB
BF。这个标记是可选的，因为UTF8字节没有顺序，所以它可以被用来检测一个字节流是否是UTF-8编码的。微软做这种检测，但有些软件不做这种检测，而把它当作正常字符处理。
微软在自己的UTF-8格式的文本文件之前加上了EF BB BF三个字节,
windows上面的notepad等程序就是根据这三个字节来确定一个文本文件是ASCII的还是UTF-8的,
然而这个只是微软暗自作的标记,
其它平台上并没有对UTF-8文本文件做个这样的标记。
也就是说一个UTF-8文件可能有BOM，也可能没有BOM，那么怎么区分呢？三种方法。1，用UltraEdit-32打开文件，切换到十六进制编辑模式，察看文件头部是否有EF
BB
BF。2，用Dreamweaver打开，察看页面属性，看"包括Unicode签名BOM"前面是否有个勾。3，用Windows的记事本打开，选择
"另存为"，看文件的默认编码是UTF-8还是ANSI，如果是ANSI则不带BOM。
我找到Zen
Cart的模版文件中的html_header.php，发现文件果然不带BOM，用UltraEdit-32另存为的方式加上BOM后，再上传html_header.php，一切正常。
注意用Convertz把gb2312文件转换成UTF-8文件时，默认设置是不带BOM的。不带BOM可能出现上述乱码问题，但是带
BOM，对于php的include文件要小心，会在php字节流前面多出EF BB
BF，提前输出到显示器有可能会带来程序错误。一个解决方案是凡是被include的文件都保存为ANSI，主文件可以是UTF-8。要想把一个文件去掉
BOM，使用UlterEdit打开,
切换到十六进制编辑模式，把最前面三个字节(就是那该死的 EF BB
BF)替换为20，保存（注意关闭保存时自动备份的功能），再切换到默认编辑模式，把最前面的三个空格去掉就可以了。
另外还学到一些编码的小知识：所谓的unicode保存的文件实际上是utf-16，只不过恰好跟unicode的码相同而已,但在概念上unicode与utf是两回事，unicode是内存编码表示方案，而utf是如何保存和传输unicode的方案。utf-16还分高位在前
(LE)和高位在后(BE)两种。官方的utf编码还有utf-32，也分LE和BE。非unicode官方的utf编码还有utf-7，主要用于邮件传输。utf-8的单字节部分是和iso-8859-1兼容的，这主要是一些旧的系统和库函数不能正确处理utf-16而被迫出来的，而且对英语字符来说，也节省保存的文件空间（以非英语字符浪费空间为代价）。在iso-8859-1的时候，utf8和iso-8859-1都是用一个字节表示的，当表示其它字符的时候，utf-8会使用两个或三个字节。