Open schani opened 6 years ago
This is because of isValidTag
(https://golang.org/src/encoding/json/encode.go#L805). Your tags are not considered to be valid, and are therefore ignored. isValidTag
was implemented to fix #1520, but I think that issue was before the standard field tag format.
Do other JSON encoders support field names that are not ordinary identifiers?
@ianlancetaylor Newtonsoft.JSON for .NET handles all those cases.
Might be worth noting that the JSON spec(s) [1] [2] allow for any unicode character in object keys.
JSON.parse (ECMAScript 5.1 and up) also supports that.
Change https://golang.org/cl/140305 mentions this issue: encoding/json: permit any string as a struct field name
@rsc Should this issue be considered with "JSON sweep", or is it fine as-is? The PR that I submitted can be amended to remove the introduced emptykey option.
I'd like to hear from the other encoding/json
owners before we merge that CL - ping @rsc @dsnet. The proposed change seems fine to me in principle, although I can't think of where I'd take advantage of it myself.
This change seems too narrow-sighted. An emptykey
option permits one currently invalid key among many other keys that are still not allowed. For example, what if I wanted a comma to be in my JSON key? Currently that isn't allowed since commas are used as the delimiter between the different tag arguments. Why is an empty string as a key more special than a key with commas?
A more generalized solution might be to allow a quoted string as the name argument:
Field1 int `json:"\"\",string"` // JSON name is ``
Field2 int `json:"\"foo,bar\",string"` // JSON name is `foo,bar`
Field3 int `json:"\"foo\\\"bar\",string"` // JSON name is `foo"bar`
However, this looks ugly since it requires double escaping.
Personally, I'm okay with the fact that the json
package can't emit every possible key via struct tags. Using map[string]interface{}
is a possible workaround.
From #29476 .
I think it's a great pity that we can't use Chinese punctuation as json's key. But in fact, I still have other ways to avoid this situation.
What I encountered was that I had to add 《
to the key, but that didn't work. So I used two <
to simulate, but <
were automatically converted to \u003e
(And I dont know why) . So I can only ask other developers in the group not to use 《
.
Marking as NeedsDecision since it's not clear what is the correct solution to this issue.
If anyone does want to take a crack at allowing arbitrary utf-8 as JSON keys, please read @dsnet's comment at https://github.com/golang/go/issues/39189#issuecomment-632467837.
I personally agree with the earlier comment here that it's okay for encoding/json
to not have built-in support for this. Allowing nested quoting would be a possibility, but also a pretty ugly one. I don't see a nice way to fit this into the current API, but perhaps others have ideas on how a different API could work.
Allow \uNNNN
sequences?
There is also no reason why commas are not allowed in JSON keys. Using commas in JSON keys is very common:
{"username,version1": "Foo"}
There is no any way for us to correctly unmarshal the JSON above to a structure:
type Data struct {
UsernameV1 string `json:"username,version1"`
// UsernameV1 string `json:"username\,version1"`
// UsernameV1 string `json:"username\\,version1"`
}
Can't we support any escape seq here?
Or we can add a new tag jsonkey
for raw json keys without options. And then give it a higher priority.
type Data struct {
/* Options here Key, supports comma */
UsernameV1 string `json:",omitempty" jsonkey:"username,version1"`
}
We have run into this in https://github.com/opensearch-project/OpenSearch/issues/8744.
What did you do?
https://play.golang.org/p/RRB1VFNufW
Trying to unmarshal with tags like this:
What did you expect to see?
What did you see instead?
System details