查看原文
其他

Go 存储基础 — 内存结构体怎么写入文件?

奇伢 奇伢云存储 2021-09-08
坚持思考,就会很酷


概述


讲了那么多存储的通用知识,从 Linux 的文件系统,块层,再到磁盘,都做了一些深入的分享。今天分享一个 Go 编程的使用技巧:怎么把内存的结构体写入到磁盘?又怎么读出来?

大家可以先思考下。其实把这里本质就是 IO 操作,关键看数据是怎么来的。我们常见的数据要么来源于文件,来源于网络的包,而常常忽略到其实内存的结构体本身就是数据。不就是字节数组嘛,不就是 010101 嘛。本质都一样。

数据在磁盘上,是感知不到什么结构体的,就是 0101010 的数据,文件就只是字节数组而已(计算机的最小数据存储单元是 Byte ,字节)。想清楚这点就很清晰了,划重点,写入的时候关键在于怎么把结构体转变成字节数组,读取的时候关键在于怎么把字节数组转化成结构体。怎么做到这点?

说白了,就是结构体到字节数组的转化嘛,专业一点的术语叫做序列化与反序列化

其实不光是内存到磁盘,内存到网络,只要是涉及到跨平台,跨介质,都是如此,你必须把数据转化成一个计算机体系通用的形态:字节数组。

字节是最小的存储单位,所有计算机的理解是一致的,这才是宇宙通用,没有歧义的最小单位。


序列化


序列化有复杂的,有简单的,但本质都是一样,因为目标一致就是字节数组。不同的方式诞生了不同的协议,最出名的大概是 json,pb 。

举个栗子,以下面的 Test 为例:

// 按照对齐原则,Test 变量占用 16 字节的内存
type Test struct {
 F1 uint64
 F2 uint32
 F3 byte
}


 1   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 去做这个事情,因为你无法显式的控制序列化之后的样子,所以你只能自定义序列化。


 2   自定义


自定义序列化规则怎么做呢?还是以 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([]byte16)
 // 序列化
 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 的地址是简单也最原始的"序列化"方式


 1   强转类型


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

发现没,这个是小端序的输出(前面说过了,机器默认的字节序是小端序)。


文件读写


到这里已经非常简单了,因为前面我们已经把结构体和字节数组互转的方法详细介绍了。写入文件的是字节数组,从文件读出来的是文件数组。就是这样简单。

写一个结构体的步骤如下:

  1. 先把结构体搞成字节数组的形态;
  2. 然后写入

读一个结构体的步骤如下:

  1. 先从文件中读数据,读到一个字节 buffer 中;
  2. 强转成结构体

举个栗子:

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 数组的样子,小端序的样子。


总结



好啦,我们简单总结下知识点,你学会了吗:

  1. 文件,从某个存储组成来看,本质是字节数组;
  2. 内存结构体在磁盘文件中的读写本质要经过字节数组的转化;
  3. 结构体变成字节数组我们叫做序列化,字节数组转化成结构体我们叫做反序列化;
  4. 序列化有复杂的,有简单的,本质都是一样,因为目标一致就是字节数组。不同的方式诞生了不同的协议,最出名的大概是 json,pb;
  5. 结构体本身就是内存块,本身就是字节数组,所以把结构体地址强转成 []byte 的地址是简单也最原始的序列化方式;
  6. 结构体强转类型是要注意的,在遇到多字节类型(比如整型)必须要字节序大小端的兼容性问题;
  7. 考虑数据大小端兼容性问题的时候,又不想用 json 这种复杂的序列化,那么最好的就是自定义序列化规则啦;
  8. hexdump 这个工具用过没?非常好用,查看文件二进制数据;

~完~


往期推荐




往期推荐



存储进阶—怎么才能保证 IO 数据的安全?

存储基础 —— 磁盘 IO 为什么总叫你对齐?

读者问答:Go 编程怎么也有踩内存?

Go 存储基础 — 文件 IO 的姿势





坚持思考,方向比努力更重要。关注我:奇伢云存储

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存