JSON parsing of floating-point numbers

Recently encountered a problem at work

Get a JSON string from a POST request from another system (as if it were written in C #)

{"Geometry": {"Rings": [[[40426489.331430912,3001752.0858958033],[40426225.692211367,3001750.0779145896],[ 40426202.957955509,3001594.0301330695],[40426290.959128119,3001559.0584689],[ 40426390.723533183,3001537.0470353812],[40426464.66273,3001645.3116807956],[ 40426489.331430912,3001752.0858958033]], "spatialreference": {"Wkid": 2364}}, "Succeed": True, "MSG": ""}

JSON parsing is then done in my system (written in Java),

Starting with JSON Lib 2.4 parsing

Get the JSON object, and then in the JSON object to calculate the area, how is wrong, and later analyzed the parsed code

{"Rings": [[[4.0426488e7,3001752],[4.0426224e7,3001750],[4.0426204e7,3001594],[4.0426292e7,3001559],[ 4.0426392E7,3001537],[4.0426464E7,3001645.2],[4.0426488E7,3001752]], "spatialreference": {"Wkid": 2364}}

Discover the original 40426489.331430912,3001752.0858958033

into a 4.0426488e7,3001752.

This difference is too far, the fractional part is all lost

My workaround here is to not do this JSON parsing process, split the JSON string directly, then get the part I want, and then request the service to compute the area.

This problem has been solved, but I have not figured out why JSON Lib parsing is so, I thought it was C # and Java for floating-point processing caused by different.

I tried some of the usual JSON parsing packages on the web.

Gson,smartjson

The results of the analysis are

{"Rings": [[[4.042648933143091e7,3001752.0858958033],[4.042622569221137e7,3001750.0779145896],[ 4.042620295795551e7,3001594.0301330695],[4.042629095912812e7,3001559.0584689],[4.042639072353318e7, 3001537.047035381],[4.042646466273E7,3001645.3116807956],[4.042648933143091E7,3001752.0858958033]], " Spatialreference ": {" Wkid ": 2364}}

Although the use of scientific notation, but no loss of precision

Seems to be the problem with JSON lib.

JSON parsing of floating-point numbers