因此我认为，.NET Framework 1.0 或 1.1 版类库中存在任何 Windows 所没有的功能限制都不足为怪。毕竟，32 位的 Windows（不管何种版本）是一个成熟的操作系统，为广大客户服务了十多年。相比之下，.NET Framework 却是一个新事物。

随着越来越多的开发人员将生产应用程序转到托管代码，开发人员更频繁地研究底层操作系统以图找出一些关键功能显得很自然 — 至少目前是如此。

值得庆幸的是，公共语言运行库 (CLR) 的 interop 功能（称为平台调用 (P/Invoke)）非常完善。在本专栏中，我将重点介绍如何实际使用 P/Invoke 来调用 Windows API 函数。当指 CLR 的 COM Interop 功能时，P/Invoke 当作名词使用；当指该功能的使用时，则将其当作动词使用。我并不打算直接介绍 COM Interop，因为它比 P/Invoke 具有更好的可访问性，却更加复杂，这有点自相矛盾，这使得将 COM Interop 作为专栏主题来讨论不太简明扼要。

走进 P/Invoke

首先从考察一个简单的 P/Invoke 示例开始。让我们看一看如何调用 Win32 MessageBeep 函数，它的非托管声明如以下代码所示：

BOOL MessageBeep(

  UINT uType   // beep type

);

为了调用 MessageBeep，您需要在 C# 中将以下代码添加到一个类或结构定义中：

[DllImport("User32.dll")]

static extern Boolean MessageBeep(UInt32 beepType);

令人惊讶的是，只需要这段代码就可以使托管代码调用非托管的 MessageBeep API。它不是一个方法调用，而是一个外部方法定义。（另外，它接近于一个来自 C 而 C# 允许的直接端口，因此以它为起点来介绍一些概念是有帮助的。）来自托管代码的可能调用如下所示：

MessageBeep(0);

请注意，现在 MessageBeep 方法被声明为 static。这是 P/Invoke 方法所要求的，因为在该 Windows API 中没有一致的实例概念。接下来，还要注意该方法被标记为 extern。这是提示编译器该方法是通过一个从 DLL 导出的函数实现的，因此不需要提供方法体。

说到缺少方法体，您是否注意到 MessageBeep 声明并没有包含一个方法体？与大多数算法由中间语言 (IL) 指令组成的托管方法不同，P/Invoke 方法只是元数据，实时 (JIT) 编译器在运行时通过它将托管代码与非托管的 DLL 函数连接起来。执行这种到非托管世界的连接所需的一个重要信息就是导出非托管方法的 DLL 的名称。这一信息是由 MessageBeep 方法声明之前的 DllImport 自定义属性提供的。在本例中，可以看到，MessageBeep 非托管 API 是由 Windows 中的 User32.dll 导出的。

到现在为止，关于调用 MessageBeep 就剩两个话题没有介绍，请回顾一下，调用的代码与以下所示代码片段非常相似：

[DllImport("User32.dll")]

static extern Boolean MessageBeep(UInt32 beepType);

最后这两个话题是与数据封送处理 (data marshaling) 和从托管代码到非托管函数的实际方法调用有关的话题。调用非托管 MessageBeep 函数可以由找到作用域内的extern MessageBeep 声明的任何托管代码执行。该调用类似于任何其他对静态方法的调用。它与其他任何托管方法调用的共同之处在于带来了数据封送处理的需要。

C# 的规则之一是它的调用语法只能访问 CLR 数据类型，例如 System.UInt32 和 System.Boolean。C# 显然不识别 Windows API 中使用的基于 C 的数据类型（例如 UINT 和 BOOL），这些类型只是 C 语言类型的类型定义而已。所以当 Windows API 函数 MessageBeep 按以下方式编写时

BOOL MessageBeep( UINT uType )

外部方法就必须使用 CLR 类型来定义，如您在前面的代码片段中所看到的。需要使用与基础 API 函数类型不同但与之兼容的 CLR 类型是 P/Invoke 较难使用的一个方面。因此，在本专栏的后面我将用完整的章节来介绍数据封送处理。

样式

在 C# 中对 Windows API 进行 P/Invoke 调用是很简单的。但如果类库拒绝使您的应用程序发出嘟声，应该想方设法调用 Windows 使它进行这项工作，是吗？

是的。但是与选择的方法有关，而且关系甚大！通常，如果类库提供某种途径来实现您的意图，则最好使用 API 而不要直接调用非托管代码，因为 CLR 类型和 Win32 之间在样式上有很大的不同。我可以将关于这个问题的建议归结为一句话。当您进行 P/Invoke 时，不要使应用程序逻辑直接属于任何外部方法或其中的构件。如果您遵循这个小规则，从长远看经常会省去许多的麻烦。

图 1 中的代码显示了我所讨论的 MessageBeep 外部方法的最少附加代码。图 1 中并没有任何显著的变化，而只是对无包装的外部方法进行一些普通的改进，这可以使工作更加轻松一些。从顶部开始，您会注意到一个名为 Sound 的完整类型，它专用于 MessageBeep。如果我需要使用 Windows API 函数 PlaySound 来添加对播放波形的支持，则可以重用 Sound 类型。然而，我不会因公开单个公共静态方法的类型而生气。毕竟这只是应用程序代码而已。还应该注意到，Sound 是密封的，并定义了一个空的私有构造函数。这些只是一些细节，目的是使用户不会错误地从 Sound 派生类或者创建它的实例。

图 1 中的代码的下一个特征是，P/Invoke 出现位置的实际外部方法是 Sound 的私有方法。这个方法只是由公共 MessageBeep 方法间接公开，后者接受 BeepTypes 类型的参数。这个间接的额外层是一个很关键的细节，它提供了以下好处。首先，应该在类库中引入一个未来的 beep 托管方法，可以重复地通过公共 MessageBeep 方法来使用托管 API，而不必更改应用程序中的其余代码。

该包装方法的第二个好处是：当您进行 P/Invoke 调用时，您放弃了免受访问冲突和其他低级破坏的权利，这通常是由 CLR 提供的。缓冲方法可以保护您的应用程序的其余部分免受访问冲突及类似问题的影响（即使它不做任何事而只是传递参数）。该缓冲方法将由 P/Invoke 调用引入的任何潜在的错误本地化。

将私有外部方法隐藏在公共包装后面的第三同时也是最后的一个好处是，提供了向该方法添加一些最小的 CLR 样式的机会。例如，在图 1 中，我将 Windows API 函数返回的 Boolean 失败转换成更像 CLR 的异常。我还定义了一个名为 BeepTypes 的枚举类型，它的成员对应于同该 Windows API 一起使用的定义值。由于 C# 不支持定义，因此可以使用托管枚举类型来避免幻数向整个应用程序代码扩散。

包装方法的最后一个好处对于简单的 Windows API 函数（如 MessageBeep）诚然是微不足道的。但是当您开始调用更复杂的非托管函数时，您会发现，手动将 Windows API 样式转换成对 CLR 更加友好的方法所带来的好处会越来越多。越是打算在整个应用程序中重用 interop 功能，越是应该认真地考虑包装的设计。同时我认为，在非面向对象的静态包装方法中使用对 CLR 友好的参数也并非不可以。

DLL Import 属性

现在是更深入地进行探讨的时候了。在对托管代码进行 P/Invoke 调用时，DllImportAttribute 类型扮演着重要的角色。DllImportAttribute 的主要作用是给 CLR 指示哪个 DLL 导出您想要调用的函数。相关 DLL 的名称被作为一个构造函数参数传递给 DllImportAttribute。

如果您无法肯定哪个 DLL 定义了您要使用的 Windows API 函数，Platform SDK 文档将为您提供最好的帮助资源。在 Windows API 函数主题文字临近结尾的位置，SDK 文档指定了 C 应用程序要使用该函数必须链接的 .lib 文件。在几乎所有的情况下，该 .lib 文件具有与定义该函数的系统 DLL 文件相同的名称。例如，如果该函数需要 C 应用程序链接到 Kernel32.lib，则该函数就定义在 Kernel32.dll 中。您可以在 MessageBeep 中找到有关 MessageBeep 的 Platform SDK 文档主题。在该主题结尾处，您会注意到它指出库文件是 User32.lib；这表明 MessageBeep 是从 User32.dll 中导出的。

可选的 DllImportAttribute 属性

除了指出宿主 DLL 外，DllImportAttribute 还包含了一些可选属性，其中四个特别有趣：EntryPoint、CharSet、SetLastError 和 CallingConvention。

EntryPoint 在不希望外部托管方法具有与 DLL 导出相同的名称的情况下，可以设置该属性来指示导出的 DLL 函数的入口点名称。当您定义两个调用相同非托管函数的外部方法时，这特别有用。另外，在 Windows 中还可以通过它们的序号值绑定到导出的 DLL 函数。如果您需要这样做，则诸如“#1”或“#129”的 EntryPoint 值指示 DLL 中非托管函数的序号值而不是函数名。

CharSet 对于字符集，并非所有版本的 Windows 都是同样创建的。Windows 9x 系列产品缺少重要的 Unicode 支持，而 Windows NT 和 Windows CE 系列则一开始就使用 Unicode。在这些操作系统上运行的 CLR 将Unicode 用于 String 和 Char 数据的内部表示。但也不必担心 — 当调用 Windows 9x API 函数时，CLR 会自动进行必要的转换，将其从 Unicode转换为 ANSI。

如果 DLL 函数不以任何方式处理文本，则可以忽略 DllImportAttribute 的 CharSet 属性。然而，当 Char 或 String 数据是等式的一部分时，应该将 CharSet 属性设置为 CharSet.Auto。这样可以使 CLR 根据宿主 OS 使用适当的字符集。如果没有显式地设置 CharSet 属性，则其默认值为 CharSet.Ansi。这个默认值是有缺点的，因为对于在 Windows 2000、Windows XP 和 Windows NT® 上进行的 interop 调用，它会消极地影响文本参数封送处理的性能。

应该显式地选择 CharSet.Ansi 或 CharSet.Unicode 的 CharSet 值而不是使用 CharSet.Auto 的唯一情况是：您显式地指定了一个导出函数，而该函数特定于这两种 Win32 OS 中的某一种。ReadDirectoryChangesW API 函数就是这样的一个例子，它只存在于基于 Windows NT 的操作系统中，并且只支持 Unicode；在这种情况下，您应该显式地使用 CharSet.Unicode。

有时，Windows API 是否有字符集关系并不明显。一种决不会有错的确认方法是在 Platform SDK 中检查该函数的 C 语言头文件。（如果您无法肯定要看哪个头文件，则可以查看 Platform SDK 文档中列出的每个 API 函数的头文件。）如果您发现该 API 函数确实定义为一个映射到以 A 或 W 结尾的函数名的宏，则字符集与您尝试调用的函数有关系。Windows API 函数的一个例子是在 WinUser.h 中声明的 GetMessage API，您也许会惊讶地发现它有 A 和 W 两种版本。

SetLastError 错误处理非常重要，但在编程时经常被遗忘。当您进行 P/Invoke 调用时，也会面临其他的挑战 — 处理托管代码中 Windows API 错误处理和异常之间的区别。我可以给您一点建议。

如果您正在使用 P/Invoke 调用 Windows API 函数，而对于该函数，您使用 GetLastError 来查找扩展的错误信息，则应该在外部方法的 DllImportAttribute 中将 SetLastError 属性设置为 true。这适用于大多数外部方法。

这会导致 CLR 在每次调用外部方法之后缓存由 API 函数设置的错误。然后，在包装方法中，可以通过调用类库的 System.Runtime.InteropServices.Marshal 类型中定义的 Marshal.GetLastWin32Error 方法来获取缓存的错误值。我的建议是检查这些期望来自 API 函数的错误值，并为这些值引发一个可感知的异常。对于其他所有失败情况（包括根本就没意料到的失败情况），则引发在 System.ComponentModel 命名空间中定义的 Win32Exception，并将 Marshal.GetLastWin32Error 返回的值传递给它。如果您回头看一下图 1 中的代码，您会看到我在 extern MessageBeep 方法的公共包装中就采用了这种方法。

CallingConvention 我将在此介绍的最后也可能是最不重要的一个 DllImportAttribute 属性是 CallingConvention。通过此属性，可以给 CLR 指示应该将哪种函数调用约定用于堆栈中的参数。CallingConvention.Winapi 的默认值是最好的选择，它在大多数情况下都可行。然而，如果该调用不起作用，则可以检查 Platform SDK 中的声明头文件，看看您调用的 API 函数是否是一个不符合调用约定标准的异常 API。

通常，本机函数（例如 Windows API 函数或 C- 运行时 DLL 函数）的调用约定描述了如何将参数推入线程堆栈或从线程堆栈中清除。大多数 Windows API 函数都是首先将函数的最后一个参数推入堆栈，然后由被调用的函数负责清理该堆栈。相反，许多 C-运行时 DLL 函数都被定义为按照方法参数在方法签名中出现的顺序将其推入堆栈，将堆栈清理工作交给调用者。

幸运的是，要让 P/Invoke 调用工作只需要让外围设备理解调用约定即可。通常，从默认值 CallingConvention.Winapi 开始是最好的选择。然后，在 C 运行时 DLL 函数和少数函数中，可能需要将约定更改为 CallingConvention.Cdecl。

数据封送处理

数据封送处理是 P/Invoke 具有挑战性的方面。当在托管和非托管代码之间传递数据时，CLR 遵循许多规则，很少有开发人员会经常遇到它们直至可将这些规则记住。除非您是一名类库开发人员，否则在通常情况下没有必要掌握其细节。为了最有效地在 CLR 上使用 P/Invoke，即使只偶尔需要 interop 的应用程序开发人员仍然应该理解数据封送处理的一些基础知识。

在本月专栏的剩余部分中，我将讨论简单数字和字符串数据的数据封送处理。我将从最基本的数字数据封送处理开始，然后介绍简单的指针封送处理和字符串封送处理。

封送数字和逻辑标量

Windows OS 大部分是用 C 编写的。因此，Windows API 所用到的数据类型要么是 C 类型，要么是通过类型定义或宏定义重新标记的 C 类型。让我们看看没有指针的数据封送处理。简单起见，首先重点讨论的是数字和布尔值。

当通过值向 Windows API 函数传递参数时，需要知道以下问题的答案：

有时答案很明显，但有时却不明显。Windows API 以各种方式重新定义了基本的 C 数据类型。图 2 列出了 C 和 Win32 的一些公共数据类型及其规范，以及一个具有匹配规范的公共语言运行库类型。

通常，只要您选择一个其规范与该参数的 Win32 类型相匹配的 CLR 类型，您的代码就能够正常工作。不过也有一些特例。例如，在 Windows API 中定义的 BOOL 类型是一个有符号的 32 位整型。然而，BOOL 用于指示 Boolean 值 true 或 false。虽然您不用将 BOOL 参数作为 System.Int32 值封送，但是如果使用 System.Boolean 类型，就会获得更合适的映射。字符类型的映射类似于 BOOL，因为有一个特定的 CLR 类型 (System.Char) 指出字符的含义。

在了解这些信息之后，逐步介绍示例可能是有帮助的。依然采用 beep 主题作为例子，让我们来试一下 Kernel32.dll 低级 Beep，它会通过计算机的扬声器发生嘟声。这个方法的 Platform SDK 文档可以在 Beep 中找到。本机 API 按以下方式进行记录：

BOOL Beep(

  DWORD dwFreq,      // Frequency

  DWORD dwDuration   // Duration in milliseconds

);

在参数封送处理方面，您的工作是了解什么 CLR 数据类型与 Beep API 函数所使用的 DWORD 和 BOOL 数据类型相兼容。回顾一下图 2 中的图表，您将看到 DWORD 是一个 32 位的无符号整数值，如同 CLR 类型 System.UInt32。这意味着您可以使用 UInt32 值作为送往 Beep 的两个参数。BOOL 返回值是一个非常有趣的情况，因为该图表告诉我们，在 Win32 中，BOOL 是一个 32 位的有符号整数。因此，您可以使用 System.Int32 值作为来自 Beep 的返回值。然而，CLR 也定义了 System.Boolean 类型作为 Boolean 值的语义，所以应该使用它来替代。CLR 默认将 System.Boolean 值封送为 32 位的有符号整数。此处所显示的外部方法定义是用于 Beep 的结果 P/Invoke 方法：

[DllImport("Kernel32.dll", SetLastError=true)]

static extern Boolean Beep(

   UInt32 frequency, UInt32 duration);

指针参数

许多 Windows API 函数将指针作为它们的一个或多个参数。指针增加了封送数据的复杂性，因为它们增加了一个间接层。如果没有指针，您可以通过值在线程堆栈中传递数据。有了指 针，则可以通过引用传递数据，方法是将该数据的内存地址推入线程堆栈中。然后，函数通过内存地址间接访问数据。使用托管代码表示此附加间接层的方式有多 种。

在 C# 中，如果将方法参数定义为 ref 或 out，则数据通过引用而不是通过值传递。即使您没有使用 Interop 也是这样，但只是从一个托管方法调用到另一个托管方法。例如，如果通过 ref 传递 System.Int32 参数，则在线程堆栈中传递的是该数据的地址，而不是整数值本身。下面是一个定义为通过引用接收整数值的方法的示例：

void FlipInt32(ref Int32 num){

   num = -num;

}

这里，FlipInt32 方法获取一个 Int32 值的地址、访问数据、对它求反，然后将求反过的值赋给原始变量。在以下代码中，FlipInt32 方法会将调用程序的变量 x 的值从 10 更改为 -10：

Int32 x = 10;

FlipInt32(ref x);

在托管代码中可以重用这种能力，将指针传递给非托管代码。例如，FileEncryptionStatus API 函数以 32 位无符号位掩码的形式返回文件加密状态。该 API 按以下所示方式进行记录：

BOOL FileEncryptionStatus(

  LPCTSTR lpFileName,  // file name

  LPDWORD lpStatus     // encryption status

);

请注意，该函数并不使用它的返回值返回状态，而是返回一个 Boolean 值，指示调用是否成功。在成功的情况下，实际的状态值是通过第二个参数返回的。它的工作方式是调用程序向该函数传递指向一个 DWORD 变量的指针，而该 API 函数用状态值填充指向的内存位置。以下代码片段显示了一个调用非托管 FileEncryptionStatus 函数的可能外部方法定义：

[DllImport("Advapi32.dll", CharSet=CharSet.Auto)]

static extern Boolean FileEncryptionStatus(String filename, 

   out UInt32 status);

该定义使用 out 关键字来为 UInt32 状态值指示 by-ref 参数。这里我也可以选择 ref 关键字，实际上在运行时会产生相同的机器码。out 关键字只是一个 by-ref 参数的规范，它向 C# 编译器指示所传递的数据只在被调用的函数外部传递。相反，如果使用 ref 关键字，则编译器会假定数据可以在被调用的函数的内部和外部传递。

托管代码中 out 和 ref 参数的另一个很好的方面是，地址作为 by-ref 参数传递的变量可以是线程堆栈中的一个本地变量、一个类或结构的元素，也可以是具有合适数据类型的数组中的一个元素引用。调用程序的这种灵活性使得 by-ref 参数成为封送缓冲区指针以及单数值指针的一个很好的起点。只有在我发现 ref 或 out 参数不符合我的需要的情况下，我才会考虑将指针封送为更复杂的 CLR 类型（例如类或数组对象）。

如果您不熟悉 C 语法或者调用 Windows API 函数，有时很难知道一个方法参数是否需要指针。一个常见的指示符是看参数类型是否是以字母 P 或 LP 开头的，例如 LPDWORD 或 PINT。在这两个例子中，LP 和 P 指示参数是一个指针，而它们指向的数据类型分别为 DWORD 或 INT。然而，在有些情况下，可以直接使用 C 语言语法中的星号 (*) 将 API 函数定义为指针。以下代码片段展示了这方面的示例：

void TakesAPointer(DWORD* pNum);

可以看到，上述函数的唯一一个参数是指向 DWORD 变量的指针。

当通过 P/Invoke 封送指针时，ref 和 out 只用于托管代码中的值类型。当一个参数的 CLR 类型使用 struct 关键字定义时，可以认为该参数是一个值类型。Out 和 ref 用于封送指向这些数据类型的指针，因为通常值类型变量是对象或数据，而在托管代码中并没有对值类型的引用。相反，当封送引用类型对象时，并不需要 ref 和 out 关键字，因为变量已经是对象的引用了。

如果您对引用类型和值类型之间的差别不是很熟悉，请查阅 2000 年 12 月 发行的 MSDN® Magazine，在 .NET 专栏的主题中可以找到更多信息。大多数 CLR 类型都是引用类型；然而，除了 System.String 和 System.Object，所有的基元类型（例如 System.Int32 和 System.Boolean）都是值类型。

封送不透明 (Opaque) 指针：一种特殊情况

有时在 Windows API 中，方法传递或返回的指针是不透明的，这意味着该指针值从技术角度讲是一个指针，但代码却不直接使用它。相反，代码将该指针返回给 Windows 以便随后进行重用。

一个非常常见的例子就是句柄的概念。在 Windows 中，内部数据结构（从文件到屏幕上的按钮）在应用程序代码中都表示为句柄。句柄其实就是不透明的指针或有着指针宽度的数值，应用程序用它来表示内部的 OS 构造。

少数情况下，API 函数也将不透明指针定义为 PVOID 或 LPVOID 类型。在 Windows API 的定义中，这些类型意思就是说该指针没有类型。

当一个不透明指针返回给您的应用程序（或者您的应用程序期望得到一个不透明指针）时，您应该将参数或返回值封送为 CLR 中的一种特殊类型 — System.IntPtr。当您使用 IntPtr 类型时，通常不使用 out 或 ref 参数，因为 IntPtr 意为直接持有指针。不过，如果您将一个指针封送为一个指针，则对 IntPtr 使用 by-ref 参数是合适的。

在 CLR 类型系统中，System.IntPtr 类型有一个特殊的属性。不像系统中的其他基类型，IntPtr 并没有固定的大小。相反，它在运行时的大小是依底层操作系统的正常指针大小而定的。这意味着在 32 位的 Windows 中，IntPtr 变量的宽度是 32 位的，而在 64 位的 Windows 中，实时编译器编译的代码会将 IntPtr 值看作 64 位的值。当在托管代码和非托管代码之间封送不透明指针时，这种自动调节大小的特点十分有用。

请记住，任何返回或接受句柄的 API 函数其实操作的就是不透明指针。您的代码应该将 Windows 中的句柄封送成 System.IntPtr 值。

您可以在托管代码中将 IntPtr 值强制转换为 32 位或 64 位的整数值，或将后者强制转换为前者。然而，当使用 Windows API 函数时，因为指针应是不透明的，所以除了存储和传递给外部方法外，不能将它们另做它用。这种“只限存储和传递”规则的两个特例是当您需要向外部方法传递 null 指针值和需要比较 IntPtr 值与 null 值的情况。为了做到这一点，您不能将零强制转换为 System.IntPtr，而应该在 IntPtr 类型上使用 Int32.Zero 静态公共字段，以便获得用于比较或赋值的 null 值。

封送文本

在编程时经常要对文本数据进行处理。文本为 interop 制造了一些麻烦，这有两个原因。首先，底层操作系统可能使用 Unicode 来表示字符串，也可能使用 ANSI。在极少数情况下，例如 MultiByteToWideChar API 函数的两个参数在字符集上是不一致的。

第二个原因是，当需要进行 P/Invoke 时，要处理文本还需要特别了解到 C 和 CLR 处理文本的方式是不同的。在 C 中，字符串实际上只是一个字符值数组，通常以 null 作为结束符。大多数 Windows API 函数是按照以下条件处理字符串的：对于 ANSI，将其作为字符值数组；对于 Unicode，将其作为宽字符值数组。

幸运的是，CLR 被设计得相当灵活，当封送文本时问题得以轻松解决，而不用在意 Windows API 函数期望从您的应用程序得到的是什么。这里是一些需要记住的主要考虑事项：

我们首先解答最后一个问题。大多数 Windows API 函数都带有 LPTSTR 或 LPCTSTR 值。（从函数角度看）它们分别是可修改和不可修改的缓冲区，包含以 null 结束的字符数组。“C”代表常数，意味着使用该参数信息不会传递到函数外部。LPTSTR 中的“T”表明该参数可以是 Unicode 或 ANSI，取决于您选择的字符集和底层操作系统的字符集。因为在 Windows API 中大多数字符串参数都是这两种类型之一，所以只要在 DllImportAttribute 中选择 CharSet.Auto，CLR 就按默认的方式工作。

然而，有些 API 函数或自定义的 DLL 函数采用不同的方式表示字符串。如果您要用到一个这样的函数，就可以采用 MarshalAsAttribute 修饰外部方法的字符串参数，并指明一种不同于默认 LPTSTR 的字符串格式。有关 MarshalAsAttribute 的更多信息，请参阅位于 MarshalAsAttribute Class 的 Platform SDK 文档主题。

现在让我们看一下字符串信息在您的代码和非托管函数之间传递的方向。有两种方式可以知道处理字符串时信息的传递方向。第一个也是最可靠的一个方法就 是首先理解参数的用途。例如，您正调用一个参数，它的名称类似 CreateMutex 并带有一个字符串，则可以想像该字符串信息是从应用程序向 API 函数传递的。同时，如果您调用 GetUserName，则该函数的名称表明字符串信息是从该函数向您的应用程序传递的。

除了这种比较合理的方法外，第二种查找信息传递方向的方式就是查找 API 参数类型中的字母“C”。例如，GetUserName API 函数的第一个参数被定义为 LPTSTR 类型，它代表一个指向 Unicode 或 ANSI 字符串缓冲区的长指针。但是 CreateMutex 的名称参数被类型化为 LTCTSTR。请注意，这里的类型定义是一样的，但增加一个字母“C”来表明缓冲区为常数，API 函数不能写入。

一旦明确了文本参数是只用作输入还是用作输入/输出，就可以确定使用哪种 CLR 类型作为参数类型。这里有一些规则。如果字符串参数只用作输入，则使用 System.String 类型。在托管代码中，字符串是不变的，适合用于不会被本机 API 函数更改的缓冲区。

如果字符串参数可以用作输入和/或输出，则使用 System.StringBuilder 类型。StringBuilder 类型是一个很有用的类库类型，它可以帮助您有效地构建字符串，也正好可以将缓冲区传递给本机函数，由本机函数为您填充字符串数据。一旦函数调用返回，您只 需要调用 StringBuilder 对象的 ToString 就可以得到一个 String 对象。

GetShortPathName API 函数能很好地用于显示什么时候使用 String、什么时候使用 StringBuilder，因为它只带有三个参数：一个输入字符串、一个输出字符串和一个指明输出缓冲区的字符长度的参数。

图 3 所示为加注释的非托管 GetShortPathName 函数文档，它同时指出了输入和输出字符串参数。它引出了托管的外部方法定义，也如图 3 所示。请注意第一个参数被封送为 System.String，因为它是一个只用作输入的参数。第二个参数代表一个输出缓冲区，它使用了 System.StringBuilder。

小结

本月专栏所介绍的 P/Invoke 功能足够调用 Windows 中的许多 API 函数。然而，如果您大量用到 interop，则会最终发现自己封送了很复杂的数据结构，甚至可能需要在托管代码中通过指针直接访问内存。实际上，本机代码中的 interop 可以是一个将细节和低级比特藏在里面的真正的潘多拉盒子。CLR、C# 和托管 C++ 提供了许多有用的功能；也许以后我会在本专栏介绍高级的 P/Invoke 话题。

同时，只要您觉得 .NET Framework 类库无法播放您的声音或者为您执行其他一些功能，您可以知道如何向原始而优秀的 Windows API 寻求一些帮助。

Figure 1 MessageBeep, Interop Done Well

namespace Wintellect.Interop.Sound{

   using System;

   using System.Runtime.InteropServices;

   using System.ComponentModel;



   sealed class Sound{

      public static void MessageBeep(BeepTypes type){

         if(!MessageBeep((UInt32) type)){

            Int32 err = Marshal.GetLastWin32Error();

            throw new Win32Exception(err);

         }

      }



      [DllImport("User32.dll", SetLastError=true)]

      static extern Boolean MessageBeep(UInt32 beepType);



      private Sound(){}

   }



   enum BeepTypes{ 

      Simple = -1,

      Ok                = 0x00000000,

      IconHand          = 0x00000010,

      IconQuestion      = 0x00000020,

      IconExclamation   = 0x00000030,

      IconAsterisk      = 0x00000040

   }

}

Figure 2 Non-Pointer Data Types

    

        

            
Win32 Types
Specification
CLR Type
        
    
    

        

            
char, INT8, SBYTE, CHAR†
            
8-bit signed integer
            
System.SByte
        
        

            
short, short int, INT16, SHORT
            
16-bit signed integer
            
System.Int16
        
        

            
int, long, long int, INT32, LONG32, BOOL†, INT 
            
32-bit signed integer
            
System.Int32
        
        

            
__int64, INT64, LONGLONG
            
64-bit signed integer
            
System.Int64
        
        

            
unsigned char, UINT8, UCHAR†, BYTE
            
8-bit unsigned integer
            
System.Byte
        
        

            
unsigned short, UINT16, USHORT, WORD, ATOM, WCHAR†, __wchar_t
            
16-bit unsigned integer
            
System.UInt16
        
        

            
unsigned, unsigned int, UINT32, ULONG32, DWORD32, ULONG, DWORD, UINT
            
32-bit unsigned integer
            
System.UInt32
        
        

            
unsigned __int64, UINT64, DWORDLONG, ULONGLONG
            
64-bit unsigned integer
            
System.UInt64
        
        

            
float, FLOAT
            
Single-precision floating point
            
System.Single
        
        

            
double, long double, DOUBLE
            
Double-precision floating point
            
System.Double
        
        

            
†In Win32 this type is an integer with a specially assigned meaning; in contrast, the CLR provides a specific type devoted to this meaning.
        
    

Figure 3 GetShortPathName Declarations

// ** Documentation for Win32 GetShortPathName() API Function

// DWORD GetShortPathName(

//   LPCTSTR lpszLongPath,      // file for which to get short path 

//   LPTSTR lpszShortPath,      // short path name (output)

//   DWORD cchBuffer            // size of output buffer

// );



[DllImport("Kernel32", CharSet = CharSet.Auto)]

static extern Int32 GetShortPathName(

   String path,                // input string

   StringBuilder shortPath,    // output string

   Int32 shortPathLength);     // StringBuilder.Capacity

    使用C/C++语言开发软件的程序员经常碰到这样的问题：有时候是程序编译没有问题，但是链接的时候总是报告函数不存在（经典的LNK 2001错误），有时候是程序编译和链接都没有错误，但是只要调用库中的函数就会出现堆栈异常。这些现象通常是出现在C和C++的代码混合使用的情况下或 在C++程序中使用第三方的库的情况下（不是用C++语言开发的），其实这都是函数调用约定（Calling Convention）和函数名修饰（Decorated Name）规则惹的祸。函数调用方式决定了函数参数入栈的顺序，是由调用者函数还是被调用函数负责清除栈中的参数等问题，而函数名修饰规则决定了编译器使 用何种名字修饰方式来区分不同的函数，如果函数之间的调用约定不匹配或者名字修饰不匹配就会产生以上的问题。本文分别对C和C++这两种编程语言的函数调 用约定和函数名修饰规则进行详细的解释，比较了它们的异同之处，并举例说明了以上问题出现的原因。

函数调用约定（Calling Convention）

    函数调用约定不仅决定了发生函数调用时函数参数的入栈顺序，还决定了是由调用者函数还是被调用函数负责清除栈中的参数，还原堆栈。函数调用约定有很多方 式，除了常见的__cdecl，__fastcall和__stdcall之外，C++的编译器还支持thiscall方式，不少C/C++编译器还支持 naked call方式。这么多函数调用约定常常令许多程序员很迷惑，到底它们是怎么回事，都是在什么情况下使用呢？下面就分别介绍这几种函数调用约定。

1.__cdecl

    编译器的命令行参数是/Gd。__cdecl方式是C/C++编译器默认的函数调用约定，所有非C++成员函数和那些没有用__stdcall或 __fastcall声明的函数都默认是__cdecl方式，它使用C函数调用方式，函数参数按照从右向左的顺序入栈，函数调用者负责清除栈中的参数，由 于每次函数调用都要由编译器产生清除（还原）堆栈的代码，所以使用__cdecl方式编译的程序比使用__stdcall方式编译的程序要大很多，但是 __cdecl调用方式是由函数调用者负责清除栈中的函数参数，所以这种方式支持可变参数，比如printf和windows的API wsprintf就是__cdecl调用方式。对于C函数，__cdecl方式的名字修饰约定是在函数名称前添加一个下划线；对于C++函数，除非特别使 用extern "C"，C++函数使用不同的名字修饰方式。

2.__fastcall

    编译器的命令行参数是/Gr。__fastcall函数调用约定在可能的情况下使用寄存器传递参数，通常是前两个 DWORD类型的参数或较小的参数使用ECX和EDX寄存器传递，其余参数按照从右向左的顺序入栈，被调用函数在返回之前负责清除栈中的参数。编译器使用 两个@修饰函数名字，后跟十进制数表示的函数参数列表大小，例如：@function_name@number。需要注意的是__fastcall函数调 用约定在不同的编译器上可能有不同的实现，比如16位的编译器和32位的编译器，另外，在使用内嵌汇编代码时，还要注意不能和编译器使用的寄存器有冲突。

3.__stdcall
 
    编译器的命令行参数是/Gz，__stdcall是Pascal程序的缺省调用方式，大多数Windows的API也是__stdcall调用约定。 __stdcall函数调用约定将函数参数从右向左入栈，除非使用指针或引用类型的参数，所有参数采用传值方式传递，由被调用函数负责清除栈中的参数。对 于C函数，__stdcall的名称修饰方式是在函数名字前添加下划线，在函数名字后添加@和函数参数的大小，例如：_functionname@number

4.thiscall

    thiscall只用在C++成员函数的调用，函数参数按照从右向左的顺序入栈，类实例的this指针通过ECX寄存器传递。需要注意的是thiscall不是C++的关键字，不能使用thiscall声明函数，它只能由编译器使用。

5.naked call

    采用前面几种函数调用约定的函数，编译器会在必要的时候自动在函数开始添加保存ESI，EDI，EBX，EBP寄存器的代码，在退出函数时恢复这些寄存器 的内容，使用naked call方式声明的函数不会添加这样的代码，这也就是为什么称其为naked的原因吧。naked  call不是类型修饰符，故必须和_declspec共同使用。

    VC的编译环境默认是使用__cdecl调用约定，也可以在编译环境的Project Setting...菜单－》C/C++ ＝》Code  Generation项选择设置函数调用约定。也可以直接在函数声明前添加关键字__stdcall、__cdecl或__fastcall等单独确定函 数的调用方式。在Windows系统上开发软件常用到WINAPI宏，它可以根据编译设置翻译成适当的函数调用约定，在WIN32中，它被定义为 __stdcall。 

函数名字修饰（Decorated Name）方式

    函数的名字修饰（Decorated Name）就是编译器在编译期间创建的一个字符串，用来指明函数的定义或原型。LINK程序或其他工具有时需要指定函数的名字修饰来定位函数的正确位置。 多数情况下程序员并不需要知道函数的名字修饰，LINK程序或其他工具会自动区分他们。当然，在某些情况下需要指定函数的名字修饰，例如在C++程序中， 为了让LINK程序或其他工具能够匹配到正确的函数名字，就必须为重载函数和一些特殊的函数（如构造函数和析构函数）指定名字装饰。另一种需要指定函数的 名字修饰的情况是在汇编程序中调用C或C++的函数。如果函数名字，调用约定，返回值类型或函数参数有任何改变，原来的名字修饰就不再有效，必须指定新的 名字修饰。C和C++程序的函数在内部使用不同的名字修饰方式，下面将分别介绍这两种方式。

1. C编译器的函数名修饰规则

    对于__stdcall调用约定，编译器和链接器会在输出函数名前加上一个下划线前缀，函数名后面加上一个“@”符号和其参数的字节数，例如_functionname@number。__cdecl调用约定仅在输出函数名前加上一个下划线前缀，例如_functionname。__fastcall调用约定在输出函数名前加上一个“@”符号，后面也是一个“@”符号和其参数的字节数，例如@functionname@number。   
 
2. C++编译器的函数名修饰规则

    C++的函数名修饰规则有些复杂，但是信息更充分，通过分析修饰名不仅能够知道函数的调用方式，返回值类型，参数个数甚至参数类型。不管 __cdecl，__fastcall还是__stdcall调用方式，函数修饰都是以一个“?”开始，后面紧跟函数的名字，再后面是参数表的开始标识和 按照参数类型代号拼出的参数表。对于__stdcall方式，参数表的开始标识是“@@YG”，对于__cdecl方式则是“@@YA”，对于__fastcall方式则是“@@YI”。参数表的拼写代号如下所示：
X--void   
D--char   
E--unsigned char   
F--short   
H--int   
I--unsigned int   
J--long   
K--unsigned long（DWORD）
M--float   
N--double   
_N--bool
U--struct
....
指 针的方式有些特别，用PA表示指针，用PB表示const类型的指针。后面的代号表明指针类型，如果相同类型的指针连续出现，以“0”代替，一个“0”代 表一次重复。U表示结构类型，通常后跟结构体的类型名，用“@@”表示结构类型名的结束。函数的返回值不作特殊处理，它的描述方式和函数参数一样，紧跟着 参数表的开始标志，也就是说，函数参数表的第一项实际上是表示函数的返回值类型。参数表后以“@Z”标识整个名字的结束，如果该函数无参数，则以“Z”标识结束。下面举两个例子，假如有以下函数声明：

int Function1(char *var1,unsigned long);

其函数修饰名为“?Function1@@YGHPADK@Z”，而对于函数声明：

void Function2();

其函数修饰名则为“?Function2@@YGXXZ” 。

    对于C++的类成员函数（其调用方式是thiscall），函数的名字修饰与非成员的C++函数稍有不同，首先就是在函数名字和参数表之间插入以“@”字符引导的类名；其次是参数表的开始标识不同，公有（public）成员函数的标识是“@@QAE”,保护（protected）成员函数的标识是“@@IAE”,私有（private）成员函数的标识是“@@AAE”，如果函数声明使用了const关键字，则相应的标识应分别为“@@QBE”，“@@IBE”和“@@ABE”。如果参数类型是类实例的引用，则使用“AAV1”，对于const类型的引用，则使用“ABV1”。下面就以类CTest为例说明C++成员函数的名字修饰规则：

class CTest
{
......
private:
    void Function(int);
protected:
    void CopyInfo(const CTest &src);
public:
    long DrawText(HDC hdc, long pos, const TCHAR* text, RGBQUAD color, BYTE bUnder, bool bSet);
    long InsightClass(DWORD dwClass) const;
......
};

对于成员函数Function，其函数修饰名为“?Function@CTest@@AAEXH@Z”，字符串“@@AAE”表示这是一个私有函数。成员函数CopyInfo只有一个参数，是对类CTest的const引用参数，其函数修饰名为“?CopyInfo@CTest@@IAEXABV1@@Z”。 DrawText是一个比较复杂的函数声明，不仅有字符串参数，还有结构体参数和HDC句柄参数，需要指出的是HDC实际上是一个HDC__结构类型的指 针，这个参数的表示就是“PAUHDC__@@”，其完整的函数修饰名为“?DrawText@CTest@@QAEJPAUHDC__@@JPBDUtagRGBQUAD@@E_N@Z”。InsightClass是一个共有的const函数，它的成员函数标识是“@@QBE”，完整的修饰名就是“?InsightClass@CTest@@QBEJK@Z”。

无论是C函数名修饰方式还是C++函数名修饰方式均不改变输出函数名中的字符大小写，这和PASCAL调用约定不同，PASCAL约定输出的函数名无任何修饰且全部大写。

3.查看函数的名字修饰

    有两种方式可以检查你的程序中的函数的名字修饰：使用编译输出列表或使用Dumpbin工具。使用/FAc，/FAs或/FAcs命令行参数可以让编译器 输出函数或变量名字列表。使用dumpbin.exe /SYMBOLS命令也可以获得obj文件或lib文件中的函数或变量名字列表。此外，还可以使用 undname.exe 将修饰名转换为未修饰形式。

函数调用约定和名字修饰规则不匹配引起的常见问题

    函数调用时如果出现堆栈异常，十有八九是由于函数调用约定不匹配引起的。比如动态链接库a有以下导出函数：

long MakeFun(long lFun);

动态库生成的时候采用的函数调用约定是__stdcall，所以编译生成的a.dll中函数MakeFun的调用约 定是_stdcall，也就是函数调用时参数从右向左入栈，函数返回时自己还原堆栈。现在某个程序模块b要引用a中的MakeFun，b和a一样使用 C++方式编译，只是b模块的函数调用方式是__cdecl，由于b包含了a提供的头文件中MakeFun函数声明，所以MakeFun在b模块中被其它 调用MakeFun的函数认为是__cdecl调用方式，b模块中的这些函数在调用完MakeFun当然要帮着恢复堆栈啦，可是MakeFun已经在结束 时自己恢复了堆栈，b模块中的函数这样多此一举就引起了栈指针错误，从而引发堆栈异常。宏观上的现象就是函数调用没有问题（因为参数传递顺序是一样 的），MakeFun也完成了自己的功能，只是函数返回后引发错误。解决的方法也很简单，只要保证两个模块的在编译时设置相同的函数调用约定就行了。

    在了解了函数调用约定和函数的名修饰规则之后，再来看在C++程序中使用C语言编译的库时经常出现的LNK 2001错误就很简单了。还以上面例子的两个模块为例，这一次两个模块在编译的时候都采用__stdcall调用约定，但是a.dll使用C语言的语法编 译的（C语言方式），所以a.dll的载入库a.lib中MakeFun函数的名字修饰就是“_MakeFun@4”。b包含了a提供的头文件中MakeFun函数声明，但是由于b采用的是C++语言编译，所以MakeFun在b模块中被按照C++的名字修饰规则命名为“?MakeFun@@YGJJ@Z”，编译过程相安无事，链接程序时c++的链接器就到a.lib中去找“?MakeFun@@YGJJ@Z”，但是a.lib中只有“_MakeFun@4”，没有“?MakeFun@@YGJJ@Z”，于是链接器就报告：

error LNK2001: unresolved external symbol ?MakeFun@@YGJJ@Z

解决的方法和简单，就是要让b模块知道这个函数是C语言编译的，extern "C"可以做到这一点。一个采用C语言编译的库应该考虑到使用这个库的程序可能是C++程序（使用C++编译器），所以在设计头文件时应该注意这一点。通常应该这样声明头文件：

#ifdef _cplusplus
extern "C" {
#endif

long MakeFun(long lFun);

#ifdef _cplusplus
}
#endif

这样C++的编译器就知道MakeFun的修饰名是“_MakeFun@4”，就不会有链接错误了。

    许多人不明白，为什么我使用的编译器都是VC的编译器还会产生“error LNK2001”错误？其实，VC的编译器会根据源文件的扩展名选择编译方式，如果文件的扩展名是“.C”，编译器会采用C的语法编译，如果扩展名是 “.cpp”，编译器会使用C++的语法编译程序，所以，最好的方法就是使用extern "C"。

我们知道，在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出 256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从 0000000到11111111。

上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。

ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。

2、非ASCII编码

英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号，它就无法用ASCII码表示。 于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语中的é的编码为130（二进制10000010）。这样一来，这些欧洲国家使 用的编码体系，可以表示最多256个符号。

但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如，130在法语编码 中代表了é，在希伯来语编码中却代表了字母Gimel (ג)，在俄语编码中又会代表另一个符号。但是不管怎样，所有这些编码方式中，0—127表示的符号是一样的，不一样的只是128—255的这一段。

至于亚洲国家的文字，使用的符号就更多了，汉字就多达10万左右。一个字节只能表示256种符号，肯定是不够的，就必须使用多个字节表达一个符号。 比如，简体中文常见的编码方式是GB2312，使用两个字节表示一个汉字，所以理论上最多可以表示256x256=65536个符号。

中文编码的问题需要专文讨论，这篇笔记不涉及。这里只指出，虽然都是用多个字节表示一个符号，但是GB类的汉字编码与后文的Unicode和UTF-8是毫无关系的。

3.Unicode

正如上一节所说，世界上存在着多种编码方式，同一个二进制数字可以被解释成不同的符号。因此，要想打开一个文本文件，就必须知道它的编码方式，否则用错误的编码方式解读，就会出现乱码。为什么电子邮件常常出现乱码？就是因为发信人和收信人使用的编码方式不一样。

可以想象，如果有一种编码，将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是Unicode，就像它的名字都表示的，这是一种所有符号的编码。

Unicode当然是一个很大的集合，现在的规模可以容纳100多万个符号。每个符号的编码都不一样，比如，U+0639表示阿拉伯字母Ain，U+0041表示英语的大写字母A，U+4E25表示汉字“严”。具体的符号对应表，可以查询unicode.org，或者专门的汉字对应表。

4. Unicode的问题

需要注意的是，Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。

比如，汉字“严”的unicode是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。

这里就有两个严重的问题，第一个问题是，如何才能区别unicode和ascii？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号 呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必 然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。

它们造成的结果是：1）出现了unicode的多种存储方式，也就是说有许多种不同的二进制格式，可以用来表示unicode。2）unicode在很长一段时间内无法推广，直到互联网的出现。

5.UTF-8

互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。重复一遍，这里的关系是，UTF-8是Unicode的实现方式之一。

UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。

UTF-8的编码规则很简单，只有二条：

1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。

2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。

下表总结了编码规则，字母x表示可用编码的位。

Unicode符号范围 | UTF-8编码方式
(十六进制) | （二进制）
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

下面，还是以汉字“严”为例，演示如何实现UTF-8编码。

已知“严”的unicode是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800-0000 FFFF），因此“严”的UTF-8编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“严”的UTF-8编码是 “11100100 10111000 10100101”，转换成十六进制就是E4B8A5。

6. Unicode与UTF-8之间的转换

通过上一节的例子，可以看到“严”的Unicode码是4E25，UTF-8编码是E4B8A5，两者是不一样的。它们之间的转换可以通过程序实现。

在Windows平台下，有一个最简单的转化方法，就是使用内置的记事本小程序Notepad.exe。打开文件后，点击“文件”菜单中的“另存为”命令，会跳出一个对话框，在最底部有一个“编码”的下拉条。

里面有四个选项：ANSI，Unicode，Unicode big endian 和 UTF-8。

1）ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，如果是繁体中文版会采用Big5码）。

2）Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。

3）Unicode big endian编码与上一个选项相对应。我在下一节会解释little endian和big endian的涵义。

4）UTF-8编码，也就是上一节谈到的编码方法。

选择完”编码方式“后，点击”保存“按钮，文件的编码方式就立刻转换好了。

7. Little endian和Big endian

上一节已经提到，Unicode码可以采用UCS-2格式直接存储。以汉字”严“为例，Unicode码是4E25，需要用两个字节存储，一个字节 是4E，另一个字节是25。存储的时候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。

这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big- Endian)敲开还是从小头(Little-Endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。

因此，第一个字节在前，就是”大头方式“（Big endian），第二个字节在前就是”小头方式“（Little endian）。

那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？

Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。

如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。

8. 实例

下面，举一个实例。

打开”记事本“程序Notepad.exe，新建一个文本文件，内容就是一个”严“字，依次采用ANSI，Unicode，Unicode big endian 和 UTF-8编码方式保存。

然后，用文本编辑软件UltraEdit中的”十六进制功能“，观察该文件的内部编码方式。

1）ANSI：文件的编码就是两个字节“D1 CF”，这正是“严”的GB2312编码，这也暗示GB2312是采用大头方式存储的。

2）Unicode：编码是四个字节“FF FE 25 4E”，其中“FF FE”表明是小头方式存储，真正的编码是4E25。

3）Unicode big endian：编码是四个字节“FE FF 4E 25”，其中“FE FF”表明是大头方式存储。

4）UTF-8：编码是六个字节“EF BB BF E4 B8 A5”，前三个字节“EF BB BF”表示这是UTF-8编码，后三个“E4B8A5”就是“严”的具体编码，它的存储顺序与编码顺序是一致的。

9. 延伸阅读

* The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets（关于字符集的最基本知识）

* 谈谈Unicode编码

* RFC3629：UTF-8, a transformation format of ISO 10646（如果实现UTF-8的规定）