Windows Sockets：字节排序

核心提示：本文以及另外两篇相关文章解释 Windows Sockets 编程方面的一些问题，本文介绍字节排序，Windows Sockets：字节排序，其他问题在文章 Windows Sockets：阻塞和 Windows Sockets：转换字符串中介绍， 假如使用 CAsyncSocket 类或从其派生，而服务器并不理解这些

　　本文以及另外两篇相关文章解释 Windows Sockets 编程方面的一些问题。本文介绍字节排序。其他问题在文章 Windows Sockets：阻塞和 Windows Sockets：转换字符串中介绍。 假如使用 CAsyncSocket 类或从其派生，则您需要自己治理这些问题。假如您使用 CSocket 类或从其派生，则由 MFC 治理它们。

字节排序

不同的计算机结构有时使用不同的字节顺序存储数据。例如，基于 Intel 的计算机存储数据的顺序与 Macintosh (Motorola) 计算机相反。Intel 字节顺序称为“Little-Endian”，与网络标准“Big-Endian”顺序也相反。下表解 释这些术语。 Big-Endian 和 Little-Endian 字节排序 字节排序 含义 Big-Endian 最重要的字节在词的左端。 Little-Endian 最重要的字节在词的右端。 通常，您不必为在网络上发送和接收的数据的字节顺序转换担心，但在有些情况下，您必须转换字节顺序。

何时必须转换字节顺序

在下列情况中需要转换字节顺序：

• 传递的信息需要由网络解释（与发送到另一台计算机的数据相反）。例如，可能传递端口和地址，这些信息

必须为网络理解。

• 与之通信的服务器应用程序不是 MFC 应用程序（并且没有它的源代码）。假如两台计算机不共享相同的字节

排序，则需要字节顺序转换。

何时不必转换字节顺序

在下列情况下可以免去转换字节顺序的工作：

• 两端的计算机可以同意不交换字节，并且这两台计算机使用相同的字节顺序。
• 与之通信的服务器是 MFC 应用程序。
• 有与之通信的服务器的源代码，因此可以明确地判定是否必须转换字节顺序。
• 可以将服务器移植到 MFC。这样做相当轻易，所得到的通常是更小、更快的代码。

使用 CAsyncSocket 时，您必须自己治理任何必需的字节顺序转换。Windows Sockets 将“Big-Endian”字节顺 序模型标准化，并提供在该顺序和其他顺序之间转换的函数。然而，与 CSocket 一起使用的 CArchive 使用相 反的顺序（“Little-Endian”），但 CArchive 为您治理字节顺序转换的细节。通过在应用程序中使用这种标准 排序，或通过使用 Windows Sockets 字节顺序转换函数，可增强代码的可移植性。 最适合使用 MFC 套接字的情况是当编写通信的两端时：在两端都使用 MFC。假如正在编写将与非 MFC 应用程序 通信的应用程序（如 FTP 服务器），则在向存档对象传递数据前，您可能需要使用 Windows Sockets 转换例程 ntohs 、 ntohl 、 htons 和 htonl 自己治理字节交换。本文稍后将给出这些用于与非 MFC 应用程序通信的函数 示例。

注重 当通信的另一端不是 MFC 应用程序时，也必须避免将从 CObject 派生的 C++ 对象以流的形式输入存 档，因为接收端无法处理它们。请参见 Windows Sockets：使用带存档的套接字中的说明。

有关字节顺序的更多信息，请参见 Platform SDK 中的 Windows Sockets 规范。

字节顺序转换示例

下面的示例显示使用存档的 CSocket 对象的一个序列化函数。它还阐释了在 Windows Sockets API 中如何使用 字节顺序转换函数。 该示例显示这样的情形：您正在编写与非 MFC 服务器应用程序通信的客户程序，而您没有访问该服务器应用程序 源代码的权限。在这种情况下，必须假设非 MFC 服务器使用标准的网络字节顺序。相反，MFC 客户端应用程序对 CSocket 对象使用 CArchive 对象，而 CArchive 使用与网络标准相反的“Little-Endian”字节顺序。 假设要与之通信的非 MFC 服务器具有如下已建立的消息包协议： strUCt Message { long MagicNumber; unsigned short Command; short Param1; long Param2; };
上述内容用 MFC 术语表示则为： struct Message { long m_lMagicNumber; short m_nCommand; short m_nParam1; long m_lParam2; void Serialize
( CArchive& ar ); }; 在 C++ 中， struct 和类在本质上是一回事。 Message 结构可以有成员函数，如以上声明的 Serialize 成员函数。 Serialize 成员函数可能为如下形式： void Message::Serialize(CArchive& ar)
{
if (ar.IsStoring())
{
ar < < (DWord)htonl(m_lMagicNumber);
ar < < (WORD)htons(m_nCommand);
ar < < (WORD)htons(m_nParam1);
ar < < (DWORD)htonl(m_lParam2);
}
else
{
WORD w;
DWORD dw;
ar > > dw;
m_lMagicNumber = ntohl((long)dw);
ar > > w ;
m_nCommand = ntohs((short)w);
ar > > w;
m_nParam1 = ntohs((short)w);
ar > > dw;
m_lParam2 = ntohl((long)dw);
}
}
该示例要求进行数据字节顺序转换，因为一端的非 MFC 服务器应用程序的字节排序与另一端在 MFC 客户端应用程序中使用的 CArchive 明显不匹配。该示例阐释了 Windows Sockets 提供的几个字节顺序转换函数。下表描述了这些函数。 Windows Sockets 字节顺序转换函数 函数 作用 ntohs 将 16 位数量从网络字节顺序转换为主机字节顺序（从 Big-Endian 转换为 Little-Endian）。 ntohl 将 32 位数量从网络字节顺序转换为主机字节顺序（从 Big-Endian 转换为 Little-Endian）。 htons 将 16 位数量从主机字节顺序转换为网络字节顺序（从 Little-Endian 转换为 Big-Endian）。 htonl 将 32 位数量从主机字节顺序转换为网络字节顺序（从 Little-Endian 转换为 Big-Endian）。 此示例的另一个要点是，当通信另一端的套接字应用程序为非 MFC 应用程序时，必须避免出现如下列语句的操作： ar pMsg; 这里的 pMsg 是指向从 CObject 类派生的 C++ 对象的指针。这将发送多余的与对象关联的 MFC 信息，而服务器并不理解这些信息，因为只有服务器是 MFC 应用程序时才理解。 有关更多信息，请参见：

• Windows Sockets：使用 CAsyncSocket 类
• Windows Sockets：使用带存档的套接字
• Windows Sockets：背景知识
• Windows Sockets：流式套接字
• Windows Sockets：数据文报套接字