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 matlab数字图像处理频率域滤波
  • ¥15 在abaqus做了二维正交切削模型,给刀具添加了超声振动条件后输出切削力为什么比普通切削增大这么多
  • ¥15 ELGamal和paillier计算效率谁快?
  • ¥15 file converter 转换格式失败 报错 Error marking filters as finished,如何解决?
  • ¥15 ubuntu系统下挂载磁盘上执行./提示权限不够
  • ¥15 Arcgis相交分析无法绘制一个或多个图形
  • ¥15 关于#r语言#的问题:差异分析前数据准备,报错Error in data[, sampleName1] : subscript out of bounds请问怎么解决呀以下是全部代码:
  • ¥15 seatunnel-web使用SQL组件时候后台报错,无法找到表格
  • ¥15 fpga自动售货机数码管(相关搜索:数字时钟)
  • ¥15 用前端向数据库插入数据,通过debug发现数据能走到后端,但是放行之后就会提示错误