Decimal

ייצוג של ערך עשרוני, כמו 2.5. יכול להיות שהלקוחות ימירו ערכים לפורמטים עשרוניים שמותאמים לשפה, כמו BigDecimal ב-Java או decimal.Decimal ב-Python.

ייצוג ב-JSON 
{
  "value": string
}
שדות
value

string

הערך העשרוני, כמחרוזת.

הייצוג של המחרוזת מורכב מסימן אופציונלי, + (U+002B) או - (U+002D), שאחריו רצף של אפס או יותר ספרות עשרוניות ("המספר השלם"), שאחריו יכול להיות שבר, שאחריו יכול להיות מעריך חזקה. מחרוזת ריקה צריכה להתפרש כ-0.

החלק השברי מורכב מנקודה עשרונית שאחריה אפשר להוסיף ספרות עשרוניות או לא. המחרוזת חייבת להכיל לפחות ספרה אחת בחלק השלם או בחלק השברי. המספר שנוצר מהסימן, מהמספר השלם ומהשבר נקרא מנטיסה.

החזקה מורכבת מהתו e (U+0065) או E (U+0045) שאחריהם ספרה עשרונית אחת או יותר.

שירותים צריכים לבצע נורמליזציה של ערכים עשרוניים לפני שהם מאחסנים אותם, על ידי:

  • הסרת סימן שסופק באופן מפורש + (+2.5 -> 2.5).
  • החלפת ערך של מספר שלם באורך אפס ב-0 (‏.5 -> ‏0.5).
  • המרת תו המעריך לאות גדולה, עם סימן מפורש (2.5e8 -> 2.5E+8).
  • הסרת מעריך אפס שצוין במפורש (2.5E0 -> 2.5).

יכול להיות ששירותים יבצעו נורמליזציה נוספת בהתאם לצרכים שלהם וליישום הפנימי של המספר העשרוני שנבחר, למשל הזזה של הנקודה העשרונית וערך החזקה יחד (דוגמה: 2.5E-1 <-> 0.25). בנוסף, יכול להיות ששירותים ישמרו את האפסים בסוף השבר כדי לציין דיוק מוגבר, אבל הם לא מחויבים לעשות זאת.

שימו לב: רק התו . נתמך לחלוקת המספר השלם והשבר. , לא אמור להיות נתמך ללא קשר ללוקאל. בנוסף, אסור לתמוך במפרידי אלפים. אם השירות תומך בהם, חובה לנרמל את הערכים.

הדקדוק של ENBF הוא:

DecimalString =
  '' | [Sign] Significand [Exponent];

Sign = '+' | '-';

Significand =
  Digits ['.'] [Digits] | [Digits] '.' Digits;

Exponent = ('e' | 'E') [Sign] Digits;

Digits = { '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' };

בשירותים צריך לתעד באופן ברור את טווח הערכים הנתמכים, את הדיוק המקסימלי הנתמך (המספר הכולל של הספרות) ואם רלוונטי, את קנה המידה (מספר הספרות אחרי הנקודה העשרונית), וגם את אופן הפעולה כשמתקבלים ערכים שחורגים מהטווח.

יכול להיות ששירותים יבחרו לקבל ערכים שמועברים כקלט גם אם הערך הוא בעל דיוק או קנה מידה גבוהים יותר מאלה שהשירות תומך בהם, וצריכים לעגל את הערך כך שיתאים לקנה המידה הנתמך. לחלופין, יכול להיות שהשירות יחזיר שגיאה עם 400 Bad Request (INVALID_ARGUMENT ב-gRPC) אם תהיה ירידה ברמת הדיוק.

שירותים צריכים להחזיר שגיאה עם קוד 400 Bad Request (INVALID_ARGUMENT ב-gRPC) אם השירות מקבל ערך מחוץ לטווח הנתמך.