programing

JSON의 문자열을 사용하여 10진수를 나타내는 이유는 무엇입니까?

batch 2023. 3. 17. 19:42
반응형

JSON의 문자열을 사용하여 10진수를 나타내는 이유는 무엇입니까?

paypal API와 같은 일부 API는 10진수를 나타내기 위해 JSON 문자열 유형을 사용합니다.그렇게"7.47"7.47

json number value type을 사용하는 것보다 이 방법이 좋은 이유는 무엇입니까?AFIK 숫자 값 유형은 과학적 표기뿐만 아니라 무한 정밀도를 허용합니다.

JSON에서 숫자 값을 문자열로 전송하는 주된 이유는 전송 시 정밀도의 손실이나 모호성을 제거하기 위해서입니다.

JSON 규격에는 숫자 값의 정밀도가 지정되어 있지 않습니다.그렇다고 해서 JSON 번호가 무한한 정밀도를 갖는 것은 아닙니다.즉, 수치 정밀도가 지정되어 있지 않습니다.즉, JSON 구현은 구현 또는 목표에 편리한 수치 정밀도를 자유롭게 선택할 수 있습니다.애플리케이션에 특정 정밀도 요건이 있는 경우, 이러한 다양성이 문제가 될 수 있습니다.

정밀도 손실은 일반적으로 숫자 값의 JSON 인코딩(1.7은 양호하고 간결함)에서는 명확하지 않지만 수신 측에서의 JSON 구문 분석 및 중간 표현에서 나타납니다.JSON 해석 함수는 1.7을 IEEE 배정도 부동소수점 번호로 해석하는 것이 타당합니다.그러나 유한 길이/유한 정밀도 십진수 표현은 항상 십진수 확장이 유한한 자릿수로 표현될 수 없는 숫자에 해당됩니다.

  1. 무리수(파이, e 등)

  2. 1.7은 base 10 표기법에서는 유한하지만 base 2 표기법에서는 1.7을 정확하게 부호화할 수 없습니다.이진수가 거의 무한대에 달하더라도 1.7에 근접할 뿐 정확히 1.7에 근접할 수는 없습니다.

따라서 1.7을 메모리 내 부동소수점 번호로 해석하면 1.7이 아닌 1.69가 반환될 수 있습니다.

JSON 1.7 값의 소비자는 고정점 데이터형 또는 "string int" 데이터형을 임의의 정밀도로 사용하는 등 보다 정교한 기술을 사용하여 값을 해석하고 메모리에 유지할 수 있지만, 이것이 일부 숫자의 변환에서 정밀도를 완전히 상실하는 망령을 완전히 제거하는 것은 아닙니다.대부분의 경우 이점이 적고 메모리와 CPU 비용이 높기 때문에 이러한 극단적인 방법을 사용하는 JSON 파서는 거의 없습니다.

따라서 정확한 수치값을 소비자에게 전송하고 이 값을 일반적인 내부 수치표현으로 자동 변환하고 싶지 않은 경우,숫자 값을 문자열로 발송하고 숫자 연산을 수행해야 할 경우 해당 문자열의 처리 방법을 사용자에게 정확하게 전달하는 것이 가장 좋습니다.

예를 들어 다음과 같습니다.일부 JSON 생산자(JRuby, 1개의 경우)에서는 BigInteger 값이 문자열로 자동으로 JSON에 출력됩니다.이는 BigInteger의 범위와 정밀도가 IEEE 2배 정밀도 플로트보다 훨씬 크기 때문입니다.BigInteger 값을 2배로 줄이면 JSON 수치로 출력할 수 있습니다.

또한 JSON 사양(http://www.json.org/)에서는 NaNs 및 Infinities(INF)가 JSON 수치에는 유효하지 않다고 명시되어 있습니다.이러한 프린지 요소를 표현해야 하는 경우 JSON 번호를 사용할 수 없습니다.문자열 또는 객체 구조를 사용해야 합니다.

마지막으로 숫자 데이터를 문자열로 전송하도록 선택할 수 있는 또 다른 측면이 있습니다. 바로 디스플레이 포맷 제어입니다.선행 0과 후행 0은 숫자 값에서 중요하지 않습니다.JSON 번호 값 2.10 또는 004를 전송하면 내부 숫자 형식으로 변환한 후 2.1 및 4로 표시됩니다.

사용자에게 직접 표시되는 데이터를 송신하는 경우는, 아마, 통화의 수치가 화면에 올바르게 표시되도록, 소수점 이하가 되도록 하고 싶다고 생각할 것입니다.이를 위한 한 가지 방법은 표시할 데이터의 포맷을 클라이언트에 맡기는 것입니다.또 다른 방법으로는 표시할 데이터를 서버에 포맷하는 방법이 있습니다.클라이언트가 화면에 정보를 표시하는 것이 간단할 수 있지만, 이 경우 클라이언트가 값을 계산해야 하는 경우 문자열에서 숫자 값을 추출하는 것이 어려울 수 있습니다.

조금 반대로 말하면 JSON에서는 재정적으로도 완벽하게 안전하다고 할 수 있습니다."7.47"더 안전한 건 없어


우선, 이 스레드의 몇 가지 오해에 대해 설명하겠습니다.

따라서 1.7을 메모리 내 부동소수점 번호로 해석하면 1.7이 아닌 1.69가 반환될 수 있습니다.

이는 해당 답변에서 언급된 IEEE 754의 이중 정밀 포맷에서는 특히 그렇지 않습니다. 1.7은 정확한 이중 1.699999999999999999995591079014373854733671875로 변환되며, 이 값을 표시하기 위해 "인쇄"하면 항상 1.7이 되고 1.699999999 또는 1.699999999999가 되지 않습니다.1.7 "정확히"입니다.

자세한 것은 이쪽.

7.47은 플로트로 변환했을 때 실제로 7.4699999923423423423423이 될 수 있다.

7.47은 이미 플로트이며, 정확한 이중값은 7.469999999999751310042483493494510650634565625입니다.다른 플로트로 "변환"되지 않습니다.

단순히 여분의 숫자를 잘라내는 단순한 시스템은 7.46이 될 것이고, 당신은 지금 어딘가에서 1페니를 잃었습니다.

IEEE 라운딩, 절단이 아닙니다.그리고 애초에 7.47 이외의 수치로는 변환되지 않습니다.

JSON 번호는 실제로 플로트입니까?언어에 의존하지 않는 번호로 JSON 번호를 Java BigDecimal 또는 기타 임의의 정밀도 형식으로 해석할 수 있습니다.

JSON 번호는 2배로 해석할 것을 권장합니다(IEEE 754 배 정밀도 형식).파서가 그런 짓을 하는 건 본 적이 없어요

그리고 아니다.BigDecimal(7.47)는 올바른 방법이 아닙니다.실제로 7.47의 정확히 두 배인 7.46999999999997513100424834945106506765625를 나타내는 BigDecimal이 생성됩니다.예상되는 동작을 얻으려면BigDecimal("7.47") 사용해야 합니다.


전체적으로 볼 때, 저는 에 대한 근본적인 문제는 없다고 생각합니다.{"price": 7.47}이것은 거의 모든 플랫폼에서 더블로 변환되며 IEEE 754의 의미론에서는 7.47로 정확하게 항상 "인쇄"

물론 이 값을 사용한 추가 계산에서 부동 소수점 반올림 오류가 발생할 수 있습니다(예: 0.1 + 0.2 == 0.300000000000004 참조). 하지만 JSON의 문자열이 이 값을 어떻게 개선하는지 알 수 없습니다."7.47"이 문자열로 도착하여 계산의 일부가 되어야 하는 경우, 어쨌든 숫자 데이터 유형(아마도 float :)으로 변환해야 합니다.

스트링에도 단점이 있습니다.예를 들어, 스트링에 전달할 수 없습니다.Intl.NumberFormat'무엇보다'라는 뜻의 '무엇보다'이치

에 대해 , 저도것만, 현에 대해서는 아무런 가 없다고 저도 현악기는 괜찮은 것 같습니다만, 현악기에서는 전혀 문제가 없다고 생각합니다.{"price": 7.47}어느 하나.

제가 이걸 하는 이유는 이 소프트웨어가AG 파서는 수신된 값에서 Java 유형을 "추측"하려고 합니다.

그래서 그것이 수신했을 때

"jackpot":{
 "growth":200,
 "percentage":66.67
}

번째 값은 '1'이 .java.lang.Long두 번째는 '비율이 .java.lang.Double

이 대박 배열의 두 번째 물건이 이걸 가지고 있을 때

"jackpot":{
 "growth":50.50,
 "percentage":65
}

문제가 생겼어요.

이러한 값을 문자열로 교환하면 완전한 제어가 가능하며 원하는 값으로 값을 캐스팅/변환할 수 있습니다.

요약판

@dthorpe의 답변에서 인용하자면, 이것이 가장 중요한 포인트라고 생각합니다.

또한 JSON 사양(http://www.json.org/)에서는 NaNs 및 Infinities(INF)가 JSON 수치에는 유효하지 않다고 명시되어 있습니다.이러한 프린지 요소를 표현해야 하는 경우 JSON 번호를 사용할 수 없습니다.문자열 또는 객체 구조를 사용해야 합니다.

I18N은 10진수에 String을 사용하지 않는 또 다른 이유입니다.

등 개에서는 콤마 (], [ (], [랑], [ (], [ (])가 사용됩니다.,)는와 점입니다..)는 천 구분자입니다.위키피디아 목록을 참조하십시오.

가 JSON 10인 :string가능한 모든 API 소비자에게 동일한 숫자 형식 변환(JSON 구문 분석 후 단계)을 사용합니다.쉼표와 점을 구분 기호로 거꾸로 사용하면 잘못된 변환의 위험이 있습니다.

「 」를 사용하고 number열 번

언급URL : https://stackoverflow.com/questions/35709595/why-would-you-use-a-string-in-json-to-represent-a-decimal-number

반응형