从文件读取变长字节转int时memcpy及字节序处理的问题

I get exactly where you're stuck—leading zeros in your data bytes are throwing off the integer value because you're not accounting for their position relative to the rest of the bytes, and ntohs/ntohl only work for fixed-length values which doesn't fit your variable-length scenario. Let's break down the solution step by step:

Core Issue: Byte Order & Proper Assembly #

The problem isn't the leading zero itself—it's that you're placing the bytes into the integer in the wrong order. You need to explicitly respect whether your file's data uses big-endian (most significant byte first, common in network protocols and many standard file formats) or little-endian (least significant byte first, common on x86 systems) byte order.

Step 1: Read Bytes Safely #

First, read your length byte and then the corresponding data bytes into an unsigned byte buffer (unsigned avoids sign extension headaches later):

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

uint8_t read_length_byte(FILE* file) {
    uint8_t len;
    fread(&len, 1, 1, file);
    return len;
}

// ...

FILE* fp = fopen("your_file.bin", "rb");
uint8_t length = read_length_byte(fp);
uint8_t data_buffer[4] = {0}; // Max 4 bytes for 32-bit integers
fread(data_buffer, 1, length, fp);

Step 2: Assemble Bytes into Integer (By Byte Order) #

Choose the method that matches your file's byte order:

For Big-Endian Data (First Byte = Most Significant) #

This is the scenario where 0x00 followed by 0xA2 should become 0x00A2 (162 in decimal):

uint32_t result = 0;
for (int i = 0; i < length; i++) {
    result = (result << 8) | data_buffer[i];
}

Each iteration shifts the current result left by 8 bits (making space for the next byte) then ORs in the new byte—preserving leading zeros in the higher byte positions.

For Little-Endian Data (First Byte = Least Significant) #

If your file stores bytes in reverse order (e.g., 0xA2 followed by 0x00 should become 0x00A2):

uint32_t result = 0;
for (int i = 0; i < length; i++) {
    result |= (uint32_t)data_buffer[i] << (8 * i);
}

Here, each byte is shifted left by 8*i bits to place it in the correct position (first byte at 0 bits, second at 8 bits, etc.).

Why ntohs/ntohl Isn't the Right Fit #

Those functions convert fixed-length big-endian values (16 or 32 bits) to your system's native byte order. Since your length is variable (could be 1, 2, 3, or 4 bytes), they don't work directly—you'd have to pad your data to a fixed length first, which is more cumbersome than the loop approach above.

Test Example #

If you read length=2, data bytes 0x00 and 0xA2:

• Big-endian assembly gives 0x00A2 (162)
• Incorrect little-endian assembly would give 0xA200 (41472)—the wrong value you're seeing.

By explicitly handling the byte order with a purpose-built loop, you'll preserve all bytes (including leading zeros) in their correct positions and get the integer value you expect.

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