duancai7568 2014-07-26 04:17
浏览 48
已采纳

Go:使用gob软件包将数据保存到文件以供以后使用是否安全?

I'm currently saving a struct to file so it can be loaded and later used by implementing gob, as follows:

func (t *Object) Load(filename string) error {

    fi, err := os.Open(filename)
    if err !=nil {
        return err
    }
    defer fi.Close()

    fz, err := gzip.NewReader(fi)
    if err !=nil {
        return err
    }
    defer fz.Close()

    decoder := gob.NewDecoder(fz)
    err = decoder.Decode(&t)
    if err !=nil {
        return err
    }

    return nil
}

func (t *Object) Save(filename string) error {

    fi, err := os.Create(filename)
    if err !=nil {
        return err
    }
    defer fi.Close()

    fz := gzip.NewWriter(fi)
    defer fz.Close()

    encoder := gob.NewEncoder(fz)
    err = encoder.Encode(t)
    if err !=nil {
        return err
    }

    return nil
}

My concern is that Go might be updated in a way that changes the way that gobs of data are encoding and decoded. If this happens then the version of my app compiled with the new version of Go would not be able to load files saved from the previous version. This would be a major issue but I'm not sure if its a realistic concern or not.

So does anyone know if I can consider it safe to save and load gob encoding data like this and expect it to still work when Go is updated?

If not, what would be the best alternative? Would my function still work if I changed gob.NewDecoder and gob.NewEncoder to xml.NewDecoder and xml.NewEncoder? (Does the XML encoder encode and decode structs in the same way as gob, i.e. without me having to tell it what they look like?)

  • 写回答

1条回答 默认 最新

  • donglvhe7591 2014-07-26 05:27
    关注

    The documentation for the type GobEncoder does mention:

    Note: Since gobs can be stored permanently, It is good design to guarantee the encoding used by a GobEncoder is stable as the software evolves.
    For instance, it might make sense for GobEncode to include a version number in the encoding.

    But that applies to custom encoder.

    For the one provided with go, the compatibility is guarantee at source level: Backwards-incompatible changes will not be made to any Go 1 point release.

    That should mean gob should continue to work as it does now.

    A different and robust solution exists with projects like "ugorji/go/codec":

    High Performance and Feature-Rich Idiomatic Go Library providing encode/decode support for different serialization formats.

    Supported Serialization formats are:

    But unless you need those specific formats, gob should be enough.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 metadata提取的PDF元数据,如何转换为一个Excel
  • ¥15 关于arduino编程toCharArray()函数的使用
  • ¥100 vc++混合CEF采用CLR方式编译报错
  • ¥15 coze 的插件输入飞书多维表格 app_token 后一直显示错误,如何解决?
  • ¥15 vite+vue3+plyr播放本地public文件夹下视频无法加载
  • ¥15 c#逐行读取txt文本,但是每一行里面数据之间空格数量不同
  • ¥50 如何openEuler 22.03上安装配置drbd
  • ¥20 ING91680C BLE5.3 芯片怎么实现串口收发数据
  • ¥15 无线连接树莓派,无法执行update,如何解决?(相关搜索:软件下载)
  • ¥15 Windows11, backspace, enter, space键失灵