Go 存储基础 — 内存结构体怎么写入文件？
作者 | 奇伢责编 | 欧阳姝黎概述讲了那么多存储的通用知识，从 Linux 的文件系统，块层，再到磁盘，都做了一些深入的分享。今天分享一个 Go 编程的使用技巧：怎么把内存...
作者 | 奇伢 责编 | 欧阳姝黎
概述
讲了那么多存储的通用知识，从 Linux 的文件系统，块层，再到磁盘，都做了一些深入的分享。今天分享一个 Go 编程的使用技巧：怎么把内存的结构体写入到磁盘？又怎么读出来？
大家可以先思考下。其实把这里本质就是 IO 操作，关键看数据是怎么来的。我们常见的数据要么来源于文件，来源于网络的包，而常常忽略到其实内存的结构体本身就是数据。不就是字节数组嘛，不就是 010101 嘛。本质都一样。
数据在磁盘上，是感知不到什么结构体的，就是 0101010 的数据，文件就只是字节数组而已（计算机的最小数据存储单元是 Byte ，字节）。想清楚这点就很清晰了，划重点，写入的时候关键在于怎么把结构体转变成字节数组，读取的时候关键在于怎么把字节数组转化成结构体。怎么做到这点？
说白了，就是结构体到字节数组的转化嘛，专业一点的术语叫做序列化与反序列化。
其实不光是内存到磁盘，内存到网络，只要是涉及到跨平台，跨介质，都是如此，你必须把数据转化成一个计算机体系通用的形态：字节数组。
字节是最小的存储单位，所有计算机的理解是一致的，这才是宇宙通用，没有歧义的最小单位。
序列化
序列化有复杂的，有简单的，但本质都是一样，因为目标一致就是字节数组。不同的方式诞生了不同的协议，最出名的大概是 json，pb 。
举个栗子，以下面的 Test 为例：
// 按照对齐原则，Test 变量占用 16 字节的内存
type Test struct {
F1 uint64
F2 uint32
F3 byte
}
json 协议
如下，是一个把结构体按照 json 的协议格式转化成字节数组（序列化）的调用。
package main
import (
"encoding/json"
"fmt"
)
// 按照对齐原则，Test 变量占用 16 字节的内存
type Test struct {
F1 uint64
F2 uint32
F3 byte
}
func main() {
t := Test{F1: 0x1234, F2: 0x4567, F3: 12,}
// 测试序列化
bs, err := json.Marshal(&t)
if err != nil {
panic("")
}
fmt.Printf("t -> []byte\t: %v\n", bs)
// 测试反序列化
t1 := Test{}
err = json.Unmarshal(bs, &t1)
if err != nil {
panic("")
}
fmt.Printf("[]byte -> t1\t: %v\n", t1)
}
输出：
$ go build -gcflags "-N -l" ./test_json_1.go
$ ./test_json_1
t -> []byte : [123 34 70 49 34 58 52 54 54 48 44 34 70 50 34 58 49 55 55 54 55 44 34 70 51 34 58 49 50 125]
[]byte -> t1 : {4660 17767 12}
这很简单，是的，这个也是我们经常用的姿势，但是我们的需求有各种各样的。
比如，Test 内存占用只有 16 个字节，但是 json 序列化完之后占用 30 个字节？我要求你这个 Test 结构体序列化成 16 字节的数组。你怎么做？你不能用 json 去做这个事情，因为你无法显式的控制序列化之后的样子，所以你只能自定义序列化。
自定义
自定义序列化规则怎么做呢？还是以 Test 举个例子：
package main
import (
"encoding/binary"
"errors"
"fmt"
)
// 按照对齐原则，Test 变量占用 16 字节的内存
type Test struct {
F1 uint64
F2 uint32
F3 byte
}
func (t *Test) Marshal() ([]byte, error) {
// 创建一个 16 字节的 buffer
buf := make([]byte, 16)
// 序列化
binary.BigEndian.PutUint64(buf[0:8], t.F1)
binary.BigEndian.PutUint32(buf[8:12], t.F2)
buf[12] = t.F3
return buf, nil
}
func (t *Test) Unmarshal(buf []byte) error {
if len(buf) != 16 {
return errors.New("length not match")
}
// 反序列化
t.F1 = binary.BigEndian.Uint64(buf[0:8])
t.F2 = binary.BigEndian.Uint32(buf[8:12])
t.F3 = buf[12]
return nil
}
func main() {
t := Test{F1: 0x1234, F2: 0x4567, F3: 12,}
// 测试序列化
bs, err := t.Marshal()
if err != nil {
panic("")
}
fmt.Printf("t -> []byte\t: %v\n", bs)
// 测试反序列化
t1 := Test{}
err = t1.Unmarshal(bs)
if err != nil {
panic("")
}
fmt.Printf("[]byte -> t1\t: %v\n", t1)
}
这样我们就能严格控制我们想要输出的序列化数组了。运行这个程序，输入如下：
$ go build -gcflags "-N -l" ./test_json.go
$ ./test_json
t -> []byte : [0 0 0 0 0 0 18 52 0 0 69 103 12 0 0 0]
[]byte -> t1 : {4660 17767 12}
千万不要觉得疑惑，你把这个输出转成 16 进制的输出，你就会发现其实是：
t -> []byte : [0 0 0 0 0 0 0x12 0x34 0 0 0x45 0x67 12 0 0 0]
[]byte -> t1 : {0x1234 0x4567 12}
这就是序列化和反序列化的本来样貌，其他各种序列化协议的都和这个是一样的。
但注意了，无论是哪种，这种相互转化一定是无损的才行，不能说 Test 这个结构体里面是 0x1234 ，经过你的序列化，再反序列化出来里面的值变成 0x3333 了，这是不行的。
字节序：大小端
细心的小伙伴肯定注意到了，我使用了 binary.BigEndian.Uint64 这个函数，这个函数是把一个 64 位的整形转化成一个大端序的字节数组。这里就引出了一个概念，什么是大端序？小端序又是什么？一般有什么遵守惯例呢？
划重点：字节的大小端是只针对多字节的基础类型才需要考虑的。
举个栗子，现在有一个 uint32 的整数 0x11 22 33 44，计算机怎么存储？磁盘怎么存储呢？
我们之前说过，计算机的存储单元是字节。一个 uint32 是 4 字节，你怎么摆放这 4 个字节呢？
直观的想法，有两种方式喽（左到右，低地址 -> 高地址）。
第一种摆放姿势：0x11 0x22 0x33 0x44
第二种摆放姿势：0x44 0x33 0x22 0x11
第一种就是所谓的大端序，第二种就是所谓的小端序。
划重点：最高有效位 在 低地址，那就是大端序，最低有效位 在 低地址那就是小端序。
现实世界中，大部分机器处理器体系是小端序，比如 x86，有的机器是大端序，比如 PowerPC 970 等。
关于大小端的其实是有一些惯例：
机器 CPU 处理一般基本都是小端；
网络传输、磁盘存储默认大端；
大端序更符合人的习惯，这个很容易理解吧，比如你把 0x11223344，按照大端序打印出来的每个字节是 0x11 0x22 0x33 0x44 ，小端序则是 0x44 0x33 0x22 0x11 ，你说哪个好看些？
所以呢，自定义序列化的时候，千万注意大小端。因为这里可能引入不兼容的坑。比如如果你不显式把一个整型序列化成一个大端序，那按照默认的方式存储到磁盘，到时候你读取上来的时候，到底是按照大端还是还是小端反序列化呢？这就是坑。
最原始的办法
结构体转化成字节数组一定要序列化这么高级姿势吗？
不一定呀。结构体本身就是内存块，本身就是字节数组，所以把结构体地址强转成 []byte 的地址是简单也最原始的"序列化"方式
强转类型
package main
import (
"fmt"
"unsafe"
)
// 按照对齐原则，Test 变量占用 16 字节的内存
type Test struct {
F1 uint64
F2 uint32
F3 byte
}
func Struct2Bytes(p unsafe.Pointer, n int) []byte {
return ((*[4096]byte)(p))[:n]
}
func main() {
t := Test{F1: 0x1234, F2: 0x4567, F3: 12}
bytes := Struct2Bytes(unsafe.Pointer(&t), 16)
fmt.Printf("t -> []byte\t: %v\n", bytes)
}
输出：
$ ./test_direct
t -> []byte : [52 18 0 0 0 0 0 0 103 69 0 0 12 0 0 0], len:16
发现没，这个是小端序的输出（前面说过了，机器默认的字节序是小端序）。
文件读写
到这里已经非常简单了，因为前面我们已经把结构体和字节数组互转的方法详细介绍了。写入文件的是字节数组，从文件读出来的是文件数组。就是这样简单。
写一个结构体的步骤如下：
先把结构体搞成字节数组的形态；
然后写入
读一个结构体的步骤如下：
先从文件中读数据，读到一个字节 buffer 中；
强转成结构体
举个栗子：
package main
import (
"fmt"
"log"
"os"
"unsafe"
)
// 按照对齐原则，Test 变量占用 16 字节的内存
type Test struct {
F1 uint64
F2 uint32
F3 byte
}
func Struct2Bytes(p unsafe.Pointer, n int) []byte {
return ((*[4096]byte)(p))[:n]
}
func main() {
t := Test{F1: 0x1234, F2: 0x4567, F3: 12}
// 强转类型
bytes := Struct2Bytes(unsafe.Pointer(&t), 16)
fmt.Printf("t -> []byte\t: %v\n", bytes)
fd, err := os.OpenFile("test_bytes.txt", os.O_RDWR|os.O_CREATE, 0666)
if err != nil {
log.Fatalf("create failed, err:%v\n",err)
}
// 结构体写入文件
_, err = fd.Write(bytes)
if err != nil {
log.Fatalf("write failed, err:%v\n", err)
}
t1 := Test{}
// 强转出一个 16 字节的内存 buffer 来
t1Bytes := Struct2Bytes(unsafe.Pointer(&t1), 16)
// 从文件中把数据读出来
_, err = fd.ReadAt(t1Bytes, 0)
if err != nil {
log.Fatalf("read failed, err:%v\n", err)
}
fmt.Printf("t1 -> []byte\t: %v\n", t1Bytes)
}
输出如下：
$ ./test_direct
t -> []byte : [52 18 0 0 0 0 0 0 103 69 0 0 12 0 0 0]
t1 -> []byte : [52 18 0 0 0 0 0 0 103 69 0 0 12 0 0 0]
变量 t 和 变量 t1 完全一致。完美撒花。最后再看一眼文件的样子：
$ hexdump -C test_bytes.txt
00000000 34 12 00 00 00 00 00 00 67 45 00 00 0c 00 00 00 |4.......gE......|
00000010
发现了吗？其实就是你结构体直接强转成 Byte 数组的样子，小端序的样子。
总结
好啦，我们简单总结下知识点，你学会了吗：
文件，从某个存储组成来看，本质是字节数组；
内存结构体在磁盘文件中的读写本质要经过字节数组的转化；
结构体变成字节数组我们叫做序列化，字节数组转化成结构体我们叫做反序列化；
序列化有复杂的，有简单的，本质都是一样，因为目标一致就是字节数组。不同的方式诞生了不同的协议，最出名的大概是 json，pb；
结构体本身就是内存块，本身就是字节数组，所以把结构体地址强转成 []byte 的地址是简单也最原始的序列化方式；
结构体强转类型是要注意的，在遇到多字节类型（比如整型）必须要字节序大小端的兼容性问题；
考虑数据大小端兼容性问题的时候，又不想用 json 这种复杂的序列化，那么最好的就是自定义序列化规则啦；
hexdump 这个工具用过没？非常好用，查看文件二进制数据；
《新程序员001：开发者黄金十年》
2001 年创刊，20 年技术见证
人人都是开发者 家家都是技术公司
20年前，《新程序员》创刊时，我们的心愿是全面关注程序员成长，中国将拥有新一代世界级的程序员。20年后的今天，我们有了新的使命：助力中国IT技术人成长，成就一亿技术人！
更多推荐
0
0- 0
已为社区贡献12386条内容
所有评论(0)