AWS Java SDK 2.x调用Elasticsearch含Unicode长文本时签名不匹配问题

这个问题和你索引配置的asciifolding分析器没有任何关联，问题出在AWS SigV4签名流程中请求体的编码与读取逻辑不一致。

根因说明 #

AWS SigV4签名算法要求计算签名时使用的请求体字节，必须和实际发送到服务端的请求体字节完全一致，只要两边的字节有任何差异，就会返回签名不匹配的403错误。
你当前技术栈的问题在于：

1. Hibernate Search 6序列化Elasticsearch请求JSON时，默认会把\u3010这类Unicode字符直接输出为UTF-8原生字符，不会转义为\uXXXX格式。
2. 旧版本的AWS Java SDK 2.x在处理超过特定缓冲区长度的请求体时，读取请求体计算签名的过程中会出现编码解析错误，误将原生UTF-8字符做转义处理或者读取截断，导致计算签名用的请求体哈希值和实际发送的请求体哈希值不一致。

你验证的场景生效原因 #

• 将\u替换为\\u：相当于把Unicode转义序列变成了普通ASCII字符串，序列化后所有字符都在ASCII范围内，不会出现编码解析歧义，签名计算和实际发送的内容完全一致，因此请求成功。
• 缩短description字段长度：请求体总长度低于SDK的缓冲区阈值，SDK可以一次性完整读取整个请求体，不会出现编码解析错误，签名校验通过。
• 禁用签名功能：跳过了签名校验环节，自然不会触发该错误。

修复方案 #

1. 配置Hibernate Search使用的JSON序列化器，强制开启非ASCII字符转义：如果你用的是Jackson作为JSON序列化工具，配置JsonWriteFeature.ESCAPE_NON_ASCII属性为true，将所有非ASCII字符统一转义为\uXXXX格式，避免编码歧义。
2. 升级AWS Java SDK 2.x到最新稳定版：该缓冲区读取编码问题是旧版本SDK的已知缺陷，高版本已经完成修复。
3. 替换Elasticsearch客户端为AWS官方提供的OpenSearch Java客户端：该客户端内置了适配OpenSearch/Elasticsearch场景的SigV4签名逻辑，不会出现该类编码不一致问题。

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