The error message is correct: it's an invalid use of the ,string option. After removing the quotes on "n", what's left is n, which isn't a valid JSON string.

@bradfitz

yes,

After removing the quotes on  "n" , what's left is  n , which isn't a valid JSON string.

but now encoding/json does not report the error message, and we got

{A: B:true C:100}

is it right???

@bradfitz

After removing the quotes on  "n" , what's left is  n , which isn't a valid JSON string.
After removing the quotes on  "t" , what's left is  t , which isn't a valid JSON string.

but now the result is

{A: B:true C:100}

A is "" and B is true

I think it is a bug!

Let's move this discussion to a forum. See https://golang.org/wiki/Questions

You're obviously looking something, but whatever it is, I don't think it's the ,string option.

@bradfitz

I think it's the ,string option
since it has ,string option, it should unquoteBytes(

golang-nuts topic is:
https://groups.google.com/forum/#!topic/golang-nuts/Z3BauUVklWM

It is definitely a bug. Why it be closed?

@bradfitz

After removing the quotes on "n", what's left is n, which isn't a valid JSON string.

so it should get a err, not a struct.

This looks like a bug.

Also decoding bool field with ",string" tag doesn't looks correct: tra-la-la is decoded to true.

http://play.golang.org/p/upVyInopWQ

package main

import (
    "encoding/json"
    "fmt"
)

type X struct {
    B bool   `json:"b,string"`
}

func main() {
    b := []byte(`{"b":"tra-la-la"}`)
    var x X
    if err := json.Unmarshal(b, &x); err != nil {
        fmt.Println(err)
        return
    }
    fmt.Printf("%+v\n", x)
}

@kostya-sh, thanks! I've reopened this bug and edited the original bug report's header to link to your example.

This is not bug(maybe?)
if value started from 't' json decoder return true (example "tra-la-la")
if value started from 'f' json decoder return false(example "foo")
in code this
line in code
and
line in code

case 't', 'f': // true, false
        return c == 't'

@bradfitz If you think this is bug?

This example shows the difference in error handling while decoding fields with and without ",string" tag: http://play.golang.org/p/RatENpHcvP

There are 3 problems as far as I can see (with ",string" tag):

• any value starting with "t" is interpreted as true for bool field
• any value starting with "f" is interpreted as false for bool filed
• any value starting with "n" is interpreted as null for bool, string and int fileds

The single letter check is not meant to intentionally accept "terrible" as true and "factual" as false. It is simply a mistake introduced when ,string was added. Originally the JSON parser was only letting true, false, and null through to that case, so looking at the first letter was sufficient. But the ,string code started passing arbitrary strings to that code and didn't first check to see if that was appropriate. Just a bug, not intended, nothing more.

Should be easy to fix.

Thanks for the simple case @kostya-sh.

CL https://golang.org/cl/23315 mentions this issue.

CL https://golang.org/cl/30943 mentions this issue.