268 lines
7.3 KiB
Go
Raw Normal View History

internal/msgfmt: use msgfmt package to format messages Port message formatting logic in testing/protocmp to internal/msgfmt and improve upon its output. This formatter is optimized for humanly readable output. It takes the best parts of both the JSON and proto text formats. The good of prototext: * It supports emitting unknown fields (useful for debugging). * It is relatively concise in the common-case since keys do not need to be represented as quoted strings (e.g., "key" vs key). The bad of prototext: * Requires relatively large dependency on encoding/prototext. * Our implementation lacks support for serializing packed lists. * Lacks support for readable maps. * Lacks support for readable Timestamp and Duration. The good of protojson: * First-class support for readable maps. * First-class support for readable Timestamp and Duration. The bad of protojson: * Requires relatively large dependency on encoding/protojson. * Lacks support for emitting unknown fields. * More verbose in the common-case as keys are quoted strings. The msgfmt package has the benefits of both protojson and prototext, but none of the detriments. It is a relatively simple implementation. This output is only intended for human consumption with no associated deserialization implementation. To avoid any illusion that this is identical to either the proto text or JSON formats, this always emits surrounding "{}" for top-level messages and the keys are not quoted strings. This CL does not use this format for generated Message.String methods as there is concerns about being inconsistent with the String methods as implemented in other languages. Having it be a seperate package makes it trivial to switch over to this if desired. Change-Id: I8b3581904d1624e84bf1b1954d2f01e5774b7f87 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/223752 Reviewed-by: Damien Neil <dneil@google.com>
2020-02-28 18:37:16 -08:00
// Copyright 2019 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Package msgfmt implements a text marshaler combining the desirable features
// of both the JSON and proto text formats.
// It is optimized for human readability and has no associated deserializer.
package msgfmt
import (
"bytes"
"fmt"
"math"
"reflect"
"sort"
"strconv"
"strings"
"time"
"google.golang.org/protobuf/encoding/protowire"
"google.golang.org/protobuf/internal/detectknown"
internal/msgfmt: use msgfmt package to format messages Port message formatting logic in testing/protocmp to internal/msgfmt and improve upon its output. This formatter is optimized for humanly readable output. It takes the best parts of both the JSON and proto text formats. The good of prototext: * It supports emitting unknown fields (useful for debugging). * It is relatively concise in the common-case since keys do not need to be represented as quoted strings (e.g., "key" vs key). The bad of prototext: * Requires relatively large dependency on encoding/prototext. * Our implementation lacks support for serializing packed lists. * Lacks support for readable maps. * Lacks support for readable Timestamp and Duration. The good of protojson: * First-class support for readable maps. * First-class support for readable Timestamp and Duration. The bad of protojson: * Requires relatively large dependency on encoding/protojson. * Lacks support for emitting unknown fields. * More verbose in the common-case as keys are quoted strings. The msgfmt package has the benefits of both protojson and prototext, but none of the detriments. It is a relatively simple implementation. This output is only intended for human consumption with no associated deserialization implementation. To avoid any illusion that this is identical to either the proto text or JSON formats, this always emits surrounding "{}" for top-level messages and the keys are not quoted strings. This CL does not use this format for generated Message.String methods as there is concerns about being inconsistent with the String methods as implemented in other languages. Having it be a seperate package makes it trivial to switch over to this if desired. Change-Id: I8b3581904d1624e84bf1b1954d2f01e5774b7f87 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/223752 Reviewed-by: Damien Neil <dneil@google.com>
2020-02-28 18:37:16 -08:00
"google.golang.org/protobuf/internal/detrand"
"google.golang.org/protobuf/internal/mapsort"
"google.golang.org/protobuf/proto"
"google.golang.org/protobuf/reflect/protoreflect"
"google.golang.org/protobuf/reflect/protoregistry"
)
// Format returns a formatted string for the message.
func Format(m proto.Message) string {
return string(appendMessage(nil, m.ProtoReflect()))
}
func appendValue(b []byte, v protoreflect.Value, fd protoreflect.FieldDescriptor) []byte {
switch v := v.Interface().(type) {
case bool, int32, int64, uint32, uint64, float32, float64:
return append(b, fmt.Sprint(v)...)
case string:
return append(b, strconv.Quote(string(v))...)
case []byte:
return append(b, strconv.Quote(string(v))...)
case protoreflect.EnumNumber:
return appendEnum(b, v, fd.Enum())
case protoreflect.Message:
return appendMessage(b, v)
case protoreflect.List:
return appendList(b, v, fd)
case protoreflect.Map:
return appendMap(b, v, fd)
default:
panic(fmt.Sprintf("invalid type: %T", v))
}
}
func appendEnum(b []byte, v protoreflect.EnumNumber, ed protoreflect.EnumDescriptor) []byte {
if ev := ed.Values().ByNumber(v); ev != nil {
return append(b, ev.Name()...)
}
return strconv.AppendInt(b, int64(v), 10)
}
func appendMessage(b []byte, m protoreflect.Message) []byte {
if b2 := appendKnownMessage(b, m); b2 != nil {
return b2
}
var fds []protoreflect.FieldDescriptor
m.Range(func(fd protoreflect.FieldDescriptor, _ protoreflect.Value) bool {
fds = append(fds, fd)
return true
})
sort.Slice(fds, func(i, j int) bool {
fdi, fdj := fds[i], fds[j]
switch {
case !fdi.IsExtension() && !fdj.IsExtension():
return fdi.Index() < fdj.Index()
case fdi.IsExtension() && fdj.IsExtension():
return fdi.FullName() < fdj.FullName()
default:
return !fdi.IsExtension() && fdj.IsExtension()
}
})
b = append(b, '{')
for _, fd := range fds {
k := string(fd.Name())
if fd.IsExtension() {
k = string("[" + fd.FullName() + "]")
}
b = append(b, k...)
b = append(b, ':')
b = appendValue(b, m.Get(fd), fd)
b = append(b, delim()...)
}
b = appendUnknown(b, m.GetUnknown())
b = bytes.TrimRight(b, delim())
b = append(b, '}')
return b
}
var protocmpMessageType = reflect.TypeOf(map[string]interface{}(nil))
func appendKnownMessage(b []byte, m protoreflect.Message) []byte {
md := m.Descriptor()
fds := md.Fields()
switch detectknown.Which(md.FullName()) {
case detectknown.AnyProto:
internal/msgfmt: use msgfmt package to format messages Port message formatting logic in testing/protocmp to internal/msgfmt and improve upon its output. This formatter is optimized for humanly readable output. It takes the best parts of both the JSON and proto text formats. The good of prototext: * It supports emitting unknown fields (useful for debugging). * It is relatively concise in the common-case since keys do not need to be represented as quoted strings (e.g., "key" vs key). The bad of prototext: * Requires relatively large dependency on encoding/prototext. * Our implementation lacks support for serializing packed lists. * Lacks support for readable maps. * Lacks support for readable Timestamp and Duration. The good of protojson: * First-class support for readable maps. * First-class support for readable Timestamp and Duration. The bad of protojson: * Requires relatively large dependency on encoding/protojson. * Lacks support for emitting unknown fields. * More verbose in the common-case as keys are quoted strings. The msgfmt package has the benefits of both protojson and prototext, but none of the detriments. It is a relatively simple implementation. This output is only intended for human consumption with no associated deserialization implementation. To avoid any illusion that this is identical to either the proto text or JSON formats, this always emits surrounding "{}" for top-level messages and the keys are not quoted strings. This CL does not use this format for generated Message.String methods as there is concerns about being inconsistent with the String methods as implemented in other languages. Having it be a seperate package makes it trivial to switch over to this if desired. Change-Id: I8b3581904d1624e84bf1b1954d2f01e5774b7f87 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/223752 Reviewed-by: Damien Neil <dneil@google.com>
2020-02-28 18:37:16 -08:00
var msgVal protoreflect.Message
url := m.Get(fds.ByName("type_url")).String()
if v := reflect.ValueOf(m); v.Type().ConvertibleTo(protocmpMessageType) {
// For protocmp.Message, directly obtain the sub-message value
// which is stored in structured form, rather than as raw bytes.
m2 := v.Convert(protocmpMessageType).Interface().(map[string]interface{})
v, ok := m2["value"].(proto.Message)
if !ok {
return nil
}
msgVal = v.ProtoReflect()
} else {
val := m.Get(fds.ByName("value")).Bytes()
mt, err := protoregistry.GlobalTypes.FindMessageByURL(url)
if err != nil {
return nil
}
msgVal = mt.New()
err = proto.UnmarshalOptions{AllowPartial: true}.Unmarshal(val, msgVal.Interface())
if err != nil {
return nil
}
}
b = append(b, '{')
b = append(b, "["+url+"]"...)
b = append(b, ':')
b = appendMessage(b, msgVal)
b = append(b, '}')
return b
case detectknown.TimestampProto:
internal/msgfmt: use msgfmt package to format messages Port message formatting logic in testing/protocmp to internal/msgfmt and improve upon its output. This formatter is optimized for humanly readable output. It takes the best parts of both the JSON and proto text formats. The good of prototext: * It supports emitting unknown fields (useful for debugging). * It is relatively concise in the common-case since keys do not need to be represented as quoted strings (e.g., "key" vs key). The bad of prototext: * Requires relatively large dependency on encoding/prototext. * Our implementation lacks support for serializing packed lists. * Lacks support for readable maps. * Lacks support for readable Timestamp and Duration. The good of protojson: * First-class support for readable maps. * First-class support for readable Timestamp and Duration. The bad of protojson: * Requires relatively large dependency on encoding/protojson. * Lacks support for emitting unknown fields. * More verbose in the common-case as keys are quoted strings. The msgfmt package has the benefits of both protojson and prototext, but none of the detriments. It is a relatively simple implementation. This output is only intended for human consumption with no associated deserialization implementation. To avoid any illusion that this is identical to either the proto text or JSON formats, this always emits surrounding "{}" for top-level messages and the keys are not quoted strings. This CL does not use this format for generated Message.String methods as there is concerns about being inconsistent with the String methods as implemented in other languages. Having it be a seperate package makes it trivial to switch over to this if desired. Change-Id: I8b3581904d1624e84bf1b1954d2f01e5774b7f87 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/223752 Reviewed-by: Damien Neil <dneil@google.com>
2020-02-28 18:37:16 -08:00
secs := m.Get(fds.ByName("seconds")).Int()
nanos := m.Get(fds.ByName("nanos")).Int()
if nanos < 0 || nanos >= 1e9 {
internal/msgfmt: use msgfmt package to format messages Port message formatting logic in testing/protocmp to internal/msgfmt and improve upon its output. This formatter is optimized for humanly readable output. It takes the best parts of both the JSON and proto text formats. The good of prototext: * It supports emitting unknown fields (useful for debugging). * It is relatively concise in the common-case since keys do not need to be represented as quoted strings (e.g., "key" vs key). The bad of prototext: * Requires relatively large dependency on encoding/prototext. * Our implementation lacks support for serializing packed lists. * Lacks support for readable maps. * Lacks support for readable Timestamp and Duration. The good of protojson: * First-class support for readable maps. * First-class support for readable Timestamp and Duration. The bad of protojson: * Requires relatively large dependency on encoding/protojson. * Lacks support for emitting unknown fields. * More verbose in the common-case as keys are quoted strings. The msgfmt package has the benefits of both protojson and prototext, but none of the detriments. It is a relatively simple implementation. This output is only intended for human consumption with no associated deserialization implementation. To avoid any illusion that this is identical to either the proto text or JSON formats, this always emits surrounding "{}" for top-level messages and the keys are not quoted strings. This CL does not use this format for generated Message.String methods as there is concerns about being inconsistent with the String methods as implemented in other languages. Having it be a seperate package makes it trivial to switch over to this if desired. Change-Id: I8b3581904d1624e84bf1b1954d2f01e5774b7f87 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/223752 Reviewed-by: Damien Neil <dneil@google.com>
2020-02-28 18:37:16 -08:00
return nil
}
t := time.Unix(secs, nanos).UTC()
x := t.Format("2006-01-02T15:04:05.000000000") // RFC 3339
x = strings.TrimSuffix(x, "000")
x = strings.TrimSuffix(x, "000")
x = strings.TrimSuffix(x, ".000")
return append(b, x+"Z"...)
case detectknown.DurationProto:
internal/msgfmt: use msgfmt package to format messages Port message formatting logic in testing/protocmp to internal/msgfmt and improve upon its output. This formatter is optimized for humanly readable output. It takes the best parts of both the JSON and proto text formats. The good of prototext: * It supports emitting unknown fields (useful for debugging). * It is relatively concise in the common-case since keys do not need to be represented as quoted strings (e.g., "key" vs key). The bad of prototext: * Requires relatively large dependency on encoding/prototext. * Our implementation lacks support for serializing packed lists. * Lacks support for readable maps. * Lacks support for readable Timestamp and Duration. The good of protojson: * First-class support for readable maps. * First-class support for readable Timestamp and Duration. The bad of protojson: * Requires relatively large dependency on encoding/protojson. * Lacks support for emitting unknown fields. * More verbose in the common-case as keys are quoted strings. The msgfmt package has the benefits of both protojson and prototext, but none of the detriments. It is a relatively simple implementation. This output is only intended for human consumption with no associated deserialization implementation. To avoid any illusion that this is identical to either the proto text or JSON formats, this always emits surrounding "{}" for top-level messages and the keys are not quoted strings. This CL does not use this format for generated Message.String methods as there is concerns about being inconsistent with the String methods as implemented in other languages. Having it be a seperate package makes it trivial to switch over to this if desired. Change-Id: I8b3581904d1624e84bf1b1954d2f01e5774b7f87 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/223752 Reviewed-by: Damien Neil <dneil@google.com>
2020-02-28 18:37:16 -08:00
secs := m.Get(fds.ByName("seconds")).Int()
nanos := m.Get(fds.ByName("nanos")).Int()
if nanos <= -1e9 || nanos >= 1e9 || (secs > 0 && nanos < 0) || (secs < 0 && nanos > 0) {
internal/msgfmt: use msgfmt package to format messages Port message formatting logic in testing/protocmp to internal/msgfmt and improve upon its output. This formatter is optimized for humanly readable output. It takes the best parts of both the JSON and proto text formats. The good of prototext: * It supports emitting unknown fields (useful for debugging). * It is relatively concise in the common-case since keys do not need to be represented as quoted strings (e.g., "key" vs key). The bad of prototext: * Requires relatively large dependency on encoding/prototext. * Our implementation lacks support for serializing packed lists. * Lacks support for readable maps. * Lacks support for readable Timestamp and Duration. The good of protojson: * First-class support for readable maps. * First-class support for readable Timestamp and Duration. The bad of protojson: * Requires relatively large dependency on encoding/protojson. * Lacks support for emitting unknown fields. * More verbose in the common-case as keys are quoted strings. The msgfmt package has the benefits of both protojson and prototext, but none of the detriments. It is a relatively simple implementation. This output is only intended for human consumption with no associated deserialization implementation. To avoid any illusion that this is identical to either the proto text or JSON formats, this always emits surrounding "{}" for top-level messages and the keys are not quoted strings. This CL does not use this format for generated Message.String methods as there is concerns about being inconsistent with the String methods as implemented in other languages. Having it be a seperate package makes it trivial to switch over to this if desired. Change-Id: I8b3581904d1624e84bf1b1954d2f01e5774b7f87 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/223752 Reviewed-by: Damien Neil <dneil@google.com>
2020-02-28 18:37:16 -08:00
return nil
}
x := fmt.Sprintf("%d.%09d", secs, int64(math.Abs(float64(nanos))))
x = strings.TrimSuffix(x, "000")
x = strings.TrimSuffix(x, "000")
x = strings.TrimSuffix(x, ".000")
return append(b, x+"s"...)
case detectknown.WrappersProto:
internal/msgfmt: use msgfmt package to format messages Port message formatting logic in testing/protocmp to internal/msgfmt and improve upon its output. This formatter is optimized for humanly readable output. It takes the best parts of both the JSON and proto text formats. The good of prototext: * It supports emitting unknown fields (useful for debugging). * It is relatively concise in the common-case since keys do not need to be represented as quoted strings (e.g., "key" vs key). The bad of prototext: * Requires relatively large dependency on encoding/prototext. * Our implementation lacks support for serializing packed lists. * Lacks support for readable maps. * Lacks support for readable Timestamp and Duration. The good of protojson: * First-class support for readable maps. * First-class support for readable Timestamp and Duration. The bad of protojson: * Requires relatively large dependency on encoding/protojson. * Lacks support for emitting unknown fields. * More verbose in the common-case as keys are quoted strings. The msgfmt package has the benefits of both protojson and prototext, but none of the detriments. It is a relatively simple implementation. This output is only intended for human consumption with no associated deserialization implementation. To avoid any illusion that this is identical to either the proto text or JSON formats, this always emits surrounding "{}" for top-level messages and the keys are not quoted strings. This CL does not use this format for generated Message.String methods as there is concerns about being inconsistent with the String methods as implemented in other languages. Having it be a seperate package makes it trivial to switch over to this if desired. Change-Id: I8b3581904d1624e84bf1b1954d2f01e5774b7f87 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/223752 Reviewed-by: Damien Neil <dneil@google.com>
2020-02-28 18:37:16 -08:00
fd := fds.ByName("value")
return appendValue(b, m.Get(fd), fd)
}
return nil
}
func appendUnknown(b []byte, raw protoreflect.RawFields) []byte {
rs := make(map[protoreflect.FieldNumber][]protoreflect.RawFields)
for len(raw) > 0 {
num, _, n := protowire.ConsumeField(raw)
rs[num] = append(rs[num], raw[:n])
raw = raw[n:]
}
var ns []protoreflect.FieldNumber
for n := range rs {
ns = append(ns, n)
}
sort.Slice(ns, func(i, j int) bool { return ns[i] < ns[j] })
for _, n := range ns {
var leftBracket, rightBracket string
if len(rs[n]) > 1 {
leftBracket, rightBracket = "[", "]"
}
b = strconv.AppendInt(b, int64(n), 10)
b = append(b, ':')
b = append(b, leftBracket...)
for _, r := range rs[n] {
num, typ, n := protowire.ConsumeTag(r)
r = r[n:]
switch typ {
case protowire.VarintType:
v, _ := protowire.ConsumeVarint(r)
b = strconv.AppendInt(b, int64(v), 10)
case protowire.Fixed32Type:
v, _ := protowire.ConsumeFixed32(r)
b = append(b, fmt.Sprintf("0x%08x", v)...)
case protowire.Fixed64Type:
v, _ := protowire.ConsumeFixed64(r)
b = append(b, fmt.Sprintf("0x%016x", v)...)
case protowire.BytesType:
v, _ := protowire.ConsumeBytes(r)
b = strconv.AppendQuote(b, string(v))
case protowire.StartGroupType:
v, _ := protowire.ConsumeGroup(num, r)
b = append(b, '{')
b = appendUnknown(b, v)
b = bytes.TrimRight(b, delim())
b = append(b, '}')
default:
panic(fmt.Sprintf("invalid type: %v", typ))
}
b = append(b, delim()...)
}
b = bytes.TrimRight(b, delim())
b = append(b, rightBracket...)
b = append(b, delim()...)
}
return b
}
func appendList(b []byte, v protoreflect.List, fd protoreflect.FieldDescriptor) []byte {
b = append(b, '[')
for i := 0; i < v.Len(); i++ {
b = appendValue(b, v.Get(i), fd)
b = append(b, delim()...)
}
b = bytes.TrimRight(b, delim())
b = append(b, ']')
return b
}
func appendMap(b []byte, v protoreflect.Map, fd protoreflect.FieldDescriptor) []byte {
var ks []protoreflect.MapKey
mapsort.Range(v, fd.MapKey().Kind(), func(k protoreflect.MapKey, _ protoreflect.Value) bool {
ks = append(ks, k)
return true
})
b = append(b, '{')
for _, k := range ks {
b = appendValue(b, k.Value(), fd.MapKey())
b = append(b, ':')
b = appendValue(b, v.Get(k), fd.MapValue())
b = append(b, delim()...)
}
b = bytes.TrimRight(b, delim())
b = append(b, '}')
return b
}
func delim() string {
// Deliberately introduce instability into the message string to
// discourage users from depending on it.
if detrand.Bool() {
return " "
}
return ", "
}