-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
encoding/json: support unmarhaling "1.111111e+06" into int64 #5562
Comments
http://play.golang.org/p/OAeg4VrwUw If all json values are floating-point, it is a bug to handle some values two different ways depending on encoding. For example, if I have "foo" in some JSON, I don't want it being handled differently than "\u0066\u006f\u006f". Decoding either of the equivalent values into any type should yield the same result. |
Issue #6657 has been merged into this issue. |
I think the current position on this is unreasonable. If the callers struct indicates an integer value and: var valFromJSON float64 if valFromJSON == float64(int(valFromJSON)) { ... The scientific number should be accepted as the integer value requested, if not the current error should apply. Even if it is known that the value will be an integer, a Go system may receive data from system that will use scientific notion whenever the value is smaller in that notation (to minimize JSON size). Ex: "2000000" (7 bytes) vs "2e+6" (4 bytes). |
Issue #8460 has been merged into this issue. |
Just for all future Go users: If one applies Unmarshal + Marshal, the produced JSON message will be have different representation of numbers than original message. IMO it's a bug (I acknowledge "Working-as-intended" status). |
FWIW I think this is unfortunate. JSON numbers are floats, and I think we should at least try to convert them to integers if we're unmarshaling into an integer type. If the JSON is produced by some other language, it may very well encode larger integers in exponential notation in the expectation that they can be round-tripped back into an integer. Luckily the usual Javascript JSON stringify function does not produce e-notation for integers in the int32 range, otherwise this would be a much bigger issue than it is. If it were up to me, I'd treat unmarshaling into an integer type as the same as converting a float64 to an integer type, int64(f). As an mitigating change, perhaps we could change %g to avoid e-notation for numbers in the range -0x80000000 to 0x7fffffff. @orian You can use UseNumber to round trip JSON without changes like that. http://play.golang.org/p/YcpPyC6v3s |
@rogpeppe 👍 . Given that |
by ben.lubar:
The text was updated successfully, but these errors were encountered: