考虑char实际大小的linux socket编程答案

【问题标题】：linux socket programming with the consideration of real size of char考虑char实际大小的linux socket编程
【发布时间】：2012-03-21 15:35:07
【问题描述】：

我正在使用 Linux 套接字编程编写客户端和服务器程序。我对某事感到困惑。虽然 sizeof(char) 保证为 1，但我知道 char 的实际大小在不同的计算机中可能会有所不同。它可能是 8 位、16 位或其他大小。问题是如果客户端和服务器的字符大小不同怎么办。例如客户端字符大小为 8 位，服务器字符大小为 16 位。客户端调用 write(socket_fd, *c, sizeof(char)) 和服务器调用 read(socket_fd, *c, sizeof(char))。客户端是否发送 8 位而服务器想要接收 16 位？如果是真的，会发生什么？

另一个问题：在客户端和服务器之间传递文本是否对我有好处，因为我不需要考虑大端和小端的问题？

提前致谢。

【问题讨论】：

我相信所有提供 IP（例如 TCP/IP）套接字的系统都有 8 位 char（并且 8 位字节大小在 Internet 协议规范内），所以你不应该在实践中打扰.而且我不知道 Linux 已被移植到任何非 8 位字节和字符系统（这些在今天非常罕见）。 Linux 需要 char-s 是 8 位字节。
@Basile：协议规范故意避免使用字节，而是出于这个原因指定八位字节。
是的，但是八位字节的概念深深地构建在 TCP/IP 中，这是一种迂腐的说法，即在 Linux 上，字符必须是 8 位字节。

标签： linux sockets network-programming

【解决方案1】：

您正在与哪个系统通信，该系统在一个字节中有 16 位？在任何情况下，如果您想确切知道您有多少位 - 请改用 int8。

【讨论】：

或加#if CHAR_BITS != 8\n #error char should be 8 bits\n #endif
我只看到post 讨论了 char 的实际大小

【解决方案2】：

char 的 c 定义作为内存单元的大小与 Unicode 中使用的定义不同。

根据所使用的编码，Unicode 代码点最多需要 6 个字节的存储空间。

这是一个与不同架构之间的字节顺序和字长差异等略有不同的问题。

如果你想表达复杂的结构（包含 unicode 文本），它可能是一个实现消息协议的好主意，将消息编码为字节数组，可以通过任何通信通道发送。

一个简单的客户端/服务器机制是发送一个包含以下消息长度的固定大小的标头。在 c 中构建这样的东西是一个很好的练习... :-)

根据您想要做的事情，查看消息接口的现有技术可能是值得的；看看 Etch、Thrift、SWIG、*-rpc、asn1、soap、xml、json、corba 等。

【讨论】：

但这不仅仅是标准的 C，这对于 Linux 来说已经足够好，这是一个不同的故事......
感谢您提供信息丰富的评论 Basile... 我认为第一行是反对票，其余的答案，关于构建复杂消息交换的复杂性无关紧要？

【解决方案3】：

@Basile 是对的。一个 char 在 linux 中总是八位。我在 Linux Kernel Development 一书中发现了这一点。这本书还陈述了一些其他规则：

虽然没有规定 int 类型必须是 32 位，但它在 Linux 中所有当前支持的架构上。
short 类型也是如此，在所有当前架构上都是 16 位，尽管没有规则明确规定。
永远不要假设指针或长整数的大小，在 Linux 当前支持的机器上可以是 32 位或 64 位。
因为 long 的大小在不同的架构上有所不同，所以永远不要假设 sizeof(int) 等于 sizeof(long)。
同样，不要假设指针和 int 大小相同。

对于通过网络传递二进制数据还是文本数据的选择，《UNIX网络编程卷1》一书中给出了两种解决方案：

将所有数字数据作为文本字符串传递。
明确定义支持的数据类型的二进制格式（位数、大端或小端），并以此格式在客户端和服务器之间传递所有数据。 RPC 包通常使用这种技术。 RFC 1832 [Srinivasan 1995] 描述了与 Sun RPC 包一起使用的外部数据表示 (XDR) 标准。

【讨论】：