json: support decoding non-string values in a string context

[juanvallejo]

Right now, the codec does not appear to support booleans as values; it either expects an object, array, number, or string, but not boolean values true or false (without quotes).

This would make the following valid json return an error:

{
   "key": true
}

Please consider updating the codec to comply with newer versions of the spec, such as RFC 7159 (see section 3)

[ugorji]

Please provide a reproducer (my_test.go or main.go) that I can run using either "go test my_test.go" or "go run main.go". Also include what you see, and what you expected to see on execution.

Thanks.

[ugorji]

This has always, and continues to work. I suspect there is an error in your code. A reproducer will make this clear. Closing this until a reproducer is provided.

[juanvallejo]

Renaming this issue to be in-line with #203
Reproducer:

package main

import (
	"fmt"

	"github.com/ugorji/go/codec"
)

var jsonData = `{
    "selector":  {
        "key1": false
    }
}`

type SampleSchema struct {
	Selector map[string]string `json:"selector"`
}

func main() {
	obj := &SampleSchema{
		Selector: make(map[string]string),
	}

	err := codec.NewDecoderBytes([]byte(jsonData), new(codec.JsonHandle)).Decode(obj)
	if err != nil {
		// attempt to reproduce error:
		// error: [pos 38]: json: expect char '"' but got char 'f'
		fmt.Printf("error: %v\n", err)
	}
}

[ugorji]

Got it. Let me think about this today.

I see where you are coming from, and can mentally make a case that we can generalize a lenient form of decoding strings, where strings that are not in quotes can be read if a LenientString flag is set in the JsonHandle.

I should have a more concrete response to you by tomorrow.

[ugorji]

By definition, this will allow false there to the following:

{ "key": false32ijr, "key2": "false32ijr", "key3": false, "key4": "false" } which is a superset of what you want, but is a fair Lenient flag support.

Let me know if this idea works for you - I think it does, but need your confirmation or color if something is off.

[juanvallejo]

By definition, this will allow false there to the following:

{ "key": false32ijr, "key2": "false32ijr", "key3": false, "key4": "false" } which is a superset of what you want

@ugorji while I'd be in favor of this, I don't think it would conform to the json spec, given that the only "literals" allowed are true, false, and null https://tools.ietf.org/html/rfc7159#section-3

I have been discussing this with @fabianofranz but will try to get additional opinions as well

[ugorji]

Ah - got it.

You want to be able to parse a "valid" json file, but be flexible based on the destination e.g. if you see a boolean but expect a string, handle appropriately. To be general, I need to support any valid non-string scalar i.e. null, true, false and numbers.

Makes sense to me.

Will follow up.

[ugorji]

^^ @juanvallejo fixed.