$filter 数字文字的后缀（“number eq '5m”、“eq “5d”、...）仅在 OData 4.0 之前有效？

Question

我发现有时可以发布一个 $filter OData 2.0 请求，其中数字文字值以一个字母为后缀，就像可以测试 这里 "round(运费) eq 32l”。通过删除后缀或使用后缀 m、M、L，其工作原理也相同。如果使用 d 或 f ，则会出现类型不匹配错误（与 Edm.Decimal 属性一起使用的浮点文字）。如果使用 a、b（等等），则表示语法错误。

• d：Edm.Double
• f：Edm.Single
• L：Edm.Int64
• m 或 M: Edm.Decimal
• 其他字母无效

有时，似乎这个后缀是强制的，并且有时不是。

我在 OData 标准中进行了一些搜索（我的发现如下所述）。我得出的结论是，在 OData 2.0 和 3.0 中这些后缀是强制性的，但从 OData 4.0 开始这些后缀无效。 （编辑后的文本，请参阅编辑 1）

您能否确认这一点，并且您能否分享一些官方 OData 解释来解释 OData 4.0 中的这一重大变化？

我的发现：

(1) OData 2.0 > URI 约定，然后滚动到 4.5。过滤系统查询选项（$filter）（虽然文本“32d”指的是带有“32”的链接，但在 URL 中手动设置“32d”也可以）：

(2) OData 2.0 >概述，然后滚动到 6. 原始数据类型：

(3) OData 3.0 > URL 约定，然后滚动到 5.1.2。过滤系统查询选项 ($filter) 和 5.1.2.2.6。算术运算符示例，其中提到了“M”数字文字 (Edm.Decimal)：

< img src="https://i.sstatic.net/bm3BE54U.png" alt="OData 3.0 > URL 约定 > 5.1.2. 过滤系统查询选项 ($filter) > 5.1.2.2.6. 算术运算符示例">

(4) OData 4.01 >第 1 部分：协议 > 11.2.6.1.2。内置查询函数，然后滚动到算术函数，不再提及“32d”：

(5) OData 4.01>第 2 部分：URL 约定 > 5.1.1.9。算术函数 > 5.1.1.9.3 轮：

(6) OData ABNF 构造规则版本 4.01，然后滚动到“decimalValue ="

编辑 1（7 月2024年9月9日）：再次查看OData 3.0，我没有看到与2022年相同的情况，因此变化发生在OData 4.0中。

Answer 1

后缀 d、f 和 m 仅在 OData V2 中允许（并且某些实现需要）。

OData V4 中的数字文字不需要或允许使用这些后缀。

Answer 2

这是参考文档，表明 OData 4.0 中发生了更改。 新增内容在 OData 版本 4.0 中，然后滚动到 3.2 查询选项 > 3.2.10 修剪：数字类型的 URI 文字后缀：

URI 中的 Decimal、Double、Single 和 Int64 文字在 URI 中使用时不再需要指定“M”、“D”、“F”或“L”后缀。 p>

这里是 OData 4.0 委员会规范 02 的 ABNF 文档，滚动到“decimalValue ="（注意：4.01 中相同）：

decimalValue = [SIGN] 1DIGIT ["." 1数字]

doubleValue = DecimalValue [ "e" [SIGN] 1DIGIT ] / nanInfinity ; IEEE 754 二进制 64 浮点数（15-17 位十进制数字）*

singleValue = doubleValue ; IEEE 754 二进制 32 浮点数（6-9 位十进制数字）

nanInfinity = 'NaN' / '-INF' / 'INF'

byteValue = 13DIGIT ; 0 到 255 范围内的数字*

sbyteValue = [ 符号 ] 13DIGIT ；范围从 -128 到 127 的数字

int16Value = [ 符号 ] 15DIGIT ；范围从 -32768 到 32767 的数字

int32Value = [ 符号 ] 110DIGIT ；范围从 -2147483648 到 2147483647 的数字

int64Value = [ 符号 ] 119DIGIT ；范围从 -9223372036854775808 到 9223372036854775807 的数字

5.1.1.15 数字促销（OData 版本 4.0。第 2 部分：URL 约定以及勘误表 03）：

服务不应该要求比较表达式中使用的数字类型之间的显式转换操作。只要有可能，应使用足够大小的基础类型来执行此类比较。

服务可以支持算术运算的数字提升，或者通过按顺序应用以下规则来比较两个可比较类型的操作数：

• 如果任一操作数为 Edm.Double，则另一个操作数将转换为 Edm.Double 类型。
• 否则，如果任一操作数为 Edm.Single，则另一个操作数将转换为 Edm.Single 类型。
• 否则，如果任一操作数的类型为 Edm.Decimal，则另一个操作数将转换为 Edm.Decimal。
• 否则，如果任一操作数为 Edm.Int64，则另一个操作数将转换为 Edm.Int64 类型。
• 否则，如果任一操作数为 Edm.Int32，则另一个操作数将转换为 Edm.Int32 类型。
• 否则，如果任一操作数为 Edm.Int16，则另一个操作数将转换为 Edm.Int16 类型。

这些提升中的每一个都使用与castExpression相同的语义来将操作数提升为目标类型。

OData 未定义字符串和数字类型之间的隐式转换。

以下信息与问题无关（$filter 或其他 URI 数字表示形式），但适用于请求正文中的数字，此处为 JSON 格式。 3.2 控制数字的表示：

IEEE754Compatible=true 格式参数指示服务必须将 Edm.Int64 和 Edm.Decimal 数字（包括 odata.count，如果请求）序列化为字符串。这符合 [I-JSON]。

如果未指定，或指定为 IEEE754Compatible=false，则所有数字都必须序列化为 JSON 数字。

这可以支持定义为 64 位二进制格式 IEEE 754 值 [ECMAScript]（请参阅第 4.3.1.9 节）的 JavaScript 数字，从而导致整数失去超过 15 位的精度，并且由于以下原因导致小数失去精度从基数 10 到基数 2 的转换。

将 Edm.Int64 和 Edm.Decimal 值格式化为字符串的 OData JSON 负载必须在 Content-Type 标头返回的媒体类型中指定此格式参数。

ExponentialDecimals=true 格式参数指示服务可以以指数表示法（例如 1e-6 而不是 0.000001）序列化 Edm.Decimal 数字（包括 odata.count，如果需要）。< /p>

如果请求正文包含指数表示法的 Edm.Decimal 值，则请求的发送者必须在 Content-Type 标头中指定 ExponentialDecimals=true。

如果未指定，或指定为 ExponentialDecimals=false，则所有 Edm.Decimal 值必须以长表示法序列化，仅使用可选符号、数字和可选小数点后跟数字。