XrmToolBox中FetchXML Builder编写OData 4.0 IN查询返回Bad Request问题

问题场景 #

在XrmToolBox的FetchXML Builder生成OData查询字符串后，手动调整查询逻辑为or、尝试使用IN运算符实现多值匹配，通过C# HttpClient.GetAsync发起请求时直接返回Bad Request。
已提前完成的排查验证：相同的请求封装逻辑在其他正常查询场景下可稳定运行，问题根因完全定位在OData查询字符串本身，历史上也多次通过修正查询字符串语法解决同类报错。
最初拼接的自定义查询字符串如下：

.../contacts?$filter=(searchable eq true) 
             or (contains(firstname, '%25firstName%25)' 
             or contains(lastname, '%25lastName%25') 
             or Microsoft.Dynamics.CRM.In(PropertyName= '_accountid_value', PropertyValues=['00000000-0000-0000-0000-000000000000','c198b30d-8d4e-eb11-a812-000d3ab5acdf','6c9caaac-a755-eb11-a812-0022489b9c9c']) 
             or Microsoft.Dynamics.CRM.In(PropertyName= 'contactid', PropertyValues=['00000000-0000-0000-0000-000000000000','30262317-0a83-eb11-a812-000d3ab02826']))

后续参考官方文档调整为标准OData IN语法格式后，依然返回同样的Bad Request错误，调整后的查询字符串为：

".../contacts?$filter=(searchable eq true) or (contains(firstname, '%25Mat%25)' or contains(lastname, '%25son%25') or _accountid_value in ('c198b30d-8d4e-eb11-a812-000d3ab5acdf','6c9caaac-a755-eb11-a812-0022489b9c9c') or contactid in ('30262317-0a83-eb11-a812-000d3ab02826'))"

常见报错诱因 #

结合同类场景的排查经验，这类无具体错误描述的Bad Request基本都是语法细节疏漏导致的，常见问题包括：

• 括号/单引号不闭合：拼的查询里contains(firstname, '%25Mat%25)是语法硬伤——字符串的闭合单引号跑到方法括号外面去了，解析器读到这直接判定字符串没写完，当场就抛Bad Request，连后续逻辑都不会解析。
• 编码操作过度：写contains()的匹配参数时，根本不需要提前手动敲URL编码。示例中的%25是半角百分号的编码值，如果手动把要搜的字符串改成%25Mat，再让HttpClient自动做一遍编码，到服务器那边实际匹配的就是%Mat，就算不报400，查出来的结果也完全不对。
• IN运算符类型不匹配：Dynamics 365的OData接口对类型校验卡得很严，像_accountid_value、contactid这种Guid类型的字段，在IN列表里写Guid值的时候不能加单引号。加了单引号，接口就会把值当字符串处理，和字段的Guid类型对不上，直接报类型错误。
• 格式字符混入请求：多行代码里拼接查询串的时候，写代码的换行、前面的缩进空格如果没处理，直接拼到最终的URL里，有些严格的OData解析器会把这些连续空白当非法字符，直接返回400。
• 环境版本不兼容：老版本的本地部署Dynamics（9.0及更早）根本不支持原生的in操作符，得用Microsoft.Dynamics.CRM.In()的扩展函数写法才行；反过来高版本环境里用扩展函数，要是参数名写错、结构不对，也会触发报错。

修正后可正常运行的写法示例 #

把所有语法坑都填上的查询串参考：

.../contacts?$filter=(searchable eq true) 
or contains(firstname, 'Mat') 
or contains(lastname, 'son') 
or _accountid_value in (c198b30d-8d4e-eb11-a812-000d3ab5acdf, 6c9caaac-a755-eb11-a812-0022489b9c9c) 
or contactid in (30262317-0a83-eb11-a812-000d3ab02826)

几个关键注意点：

• 所有字符串类的匹配值用单引号完整包裹，保证每个方法的括号、每段字符串的引号都闭合，不要漏写
• Guid类型的值直接写字面量，不要额外加单引号
• 不要提前手动敲URL编码，匹配的文本就写原始内容，让HttpClient自动完成编码即可，避免多层编码出问题
• 拼接最终请求时，把所有换行、连续的缩进空格替换为单个空格，别把代码格式字符带进URL

内容的提问来源于stack exchange，提问作者FearlessFox