2.5와 같은 십진수 값의 표현입니다. 클라이언트는 값을 Java의 BigDecimal 또는 Python의 decimal.Decimal과 같은 언어 네이티브 십진수 형식으로 변환할 수 있습니다.
JSON 표현
{"value": string}
필드
value
string
문자열로 된 10진수 값입니다.
문자열 표현은 선택적 부호, + (U+002B) 또는 - (U+002D)로 구성되며, 그 뒤에 0개 이상의 10진수 시퀀스 ('정수')가 오고, 선택적으로 분수가 오고, 선택적으로 지수가 옵니다. 빈 문자열은 0로 해석해야 합니다.
분수는 소수점과 0개 이상의 십진수로 구성됩니다. 문자열에는 정수 또는 분수에 숫자가 하나 이상 포함되어야 합니다. 부호, 정수, 분수로 구성된 숫자를 유효숫자라고 합니다.
지수는 문자 e (U+0065) 또는 E (U+0045) 다음에 하나 이상의 십진수로 구성됩니다.
서비스는 다음을 통해 값을 저장하기 전에 십진수 값을 정규화해야 합니다.
명시적으로 제공된 + 기호 삭제 (+2.5 -> 2.5)
길이가 0인 정수 값을 0으로 대체 (.5 -> 0.5)
지수 문자를 대문자로 강제 변환하고 명시적 부호를 사용합니다 (2.5e8 -> 2.5E+8).
명시적으로 제공된 0 지수를 삭제합니다 (2.5E0 -> 2.5).
서비스는 자체 요구사항과 선택한 내부 10진수 구현에 따라 소수점과 지수 값을 함께 이동하는 등 추가 정규화를 실행할 수 있습니다 (예: 2.5E-1 <-> 0.25). 또한 서비스는 정밀도 증가를 나타내기 위해 분수의 후행 0을 유지할 수 있지만 그렇게 하지 않아도 됩니다.
정수와 분수를 나누는 데는 . 문자만 지원됩니다. ,는 언어와 관계없이 지원되지 않아야 합니다. 또한 천 단위 구분 기호는 지원하지 않아야 합니다. 서비스에서 이를 지원하는 경우 값을 정규화해야 합니다.
서비스는 지원되는 값의 범위, 지원되는 최대 정밀도 (총 자릿수), 해당하는 경우 스케일 (소수점 이하 자릿수), 범위를 벗어난 값을 수신할 때의 동작을 명확하게 문서화해야 합니다.
서비스는 서비스에서 지원하는 것보다 정밀도나 스케일이 높은 값이 입력으로 전달되더라도 이를 수락할 수 있고(may) 지원되는 스케일에 맞게 값을 반올림해야 합니다(should). 또는 정밀도가 손실되는 경우 서비스에서 400 Bad Request (gRPC에서는 INVALID_ARGUMENT) 오류가 발생할 수 있습니다.
서비스가 지원되는 범위를 벗어난 값을 수신하는 경우 400 Bad Request (gRPC에서는 INVALID_ARGUMENT) 오류가 발생해야 합니다.