为何将两个uint8_t转换为uint16_t时输出为7e00而非007e？

核心原因：大小端字节序差异 #

你遇到的问题完全是**字节序（大小端）**导致的：

• 你的数组bytes在内存中的存储顺序确实是低地址存0x00、高地址存0x7E，和你预期的一致。
• 但你的运行环境是小端字节序架构：这种模式下，多字节类型（比如uint16_t）会把低字节放在内存低地址，高字节放在内存高地址。
• 当你把uint8_t*强制转成uint16_t*并读取时，系统会把低地址的0x00当作uint16_t的低字节，高地址的0x7E当作高字节，组合后就是0x7E00，这就是你看到的输出。

如果是大端字节序环境，才会输出你预期的0x007E——大端模式是高字节存在低地址、低字节在高地址。

安全且跨平台的转换方法 #

直接强制指针转换的做法不仅依赖平台字节序，还可能引发未对齐访问错误（比如在ARM等严格要求对齐的架构上，若bytes的起始地址不是uint16_t的对齐边界，会触发硬件异常）。推荐用以下两种方式实现稳定转换：

1. 手动移位拼接（推荐） #

明确指定每个字节的权重，不受平台字节序影响：

#include <stdio.h>
#include <stdint.h>

int main() {
    uint8_t bytes[] = {0, 126};
    // bytes[0]作为高字节左移8位，bytes[1]作为低字节
    uint16_t result = ((uint16_t)bytes[0] << 8) | bytes[1];
    printf("Hex: %x\n", result); // 输出Hex: 7e（即0x007E）
    return 0;
}

如果需要按小端规则转换（得到0x7E00），只需调换字节顺序：

uint16_t result_le = ((uint16_t)bytes[1] << 8) | bytes[0];

2. 使用标准库字节序转换函数 #

如果是处理网络字节序（大端）和主机字节序的转换，可以用ntohs/htons等函数，但需注意这些函数依赖系统头文件：

#include <arpa/inet.h> // Linux/UNIX环境需包含此头文件
// 先按主机字节序读取内存值，再转换为大端字节序
uint16_t result = ntohs(*(uint16_t*)bytes);

但这种方式依然存在对齐风险，不如手动移位可靠。

内容的提问来源于stack exchange，提问作者Ammar