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 #39189 (comment).

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 opensearch-project/OpenSearch#8744.