ElasticMQ未按预期拒绝非法字符串问题咨询

我之前也碰到过ElasticMQ和AWS SQS兼容不一致的情况，结合你的描述和SQS的官方规范，来拆解下这个问题：

问题复现与本质 #

我正在使用ElasticMQ，它本应与AWS SQS表现一致。根据AWS SQS官方文档，任何超出#x9 | #xA | #xD | #x20至#xD7FF | #xE000至#xFFFD | #x10000至#x10FFFF范围的非法字符串都会被拒绝。但我创建了一个仅包含单个非法字符的字符串并发送给ElasticMQ时，并未被拒绝；不过ElasticMQ表现异常：客户端计算的该单字符非法字符串的MD5校验和出现异常。

这个问题的核心是ElasticMQ的字符校验逻辑没有完全对齐AWS SQS，进而引发MD5校验不匹配：

• AWS SQS会在消息接收阶段就严格校验字符范围，不符合规范的直接返回错误；但ElasticMQ的实现遗漏了这一步，导致非法字符被存入队列。
• MD5异常的根源是：客户端计算MD5用的是原始非法字符的字节数据，而ElasticMQ内部可能对这些非法字符做了隐式处理（比如替换成占位符、修改编码或截断），导致两端的消息字节内容不一致，最终MD5值无法匹配。

临时解决办法 #

1. 客户端提前做字符校验 #

在发送消息到ElasticMQ之前，先按照SQS的规则过滤非法字符，从源头避免问题。这里给你一个简单的Java校验示例：

// 匹配SQS允许的字符范围
private static final String SQS_VALID_CHAR_REGEX = "[\\x09\\x0A\\x0D\\x20-\\xD7FF\\xE000-\\xFFFD\\x10000-\\x10FFFF]";

public boolean isMessageValidForSqs(String message) {
    return message.chars()
            .mapToObj(c -> String.valueOf((char) c))
            .allMatch(charStr -> charStr.matches(SQS_VALID_CHAR_REGEX));
}

如果校验不通过，直接在客户端抛出错误，不要发送到ElasticMQ。

2. 验证ElasticMQ的消息存储内容 #

你可以通过ElasticMQ的REST API或者客户端SDK获取已发送的消息，对比原始发送的非法字符，看看ElasticMQ是否对其做了修改。比如用curl调用ElasticMQ的/queue/{queueName}接口获取消息，查看body字段的实际内容，这能帮你确认具体的异常点。

长期修复方案 #

1. 给ElasticMQ提交Bug报告 #

因为ElasticMQ主打与SQS兼容，这个行为偏差属于明显的bug。你可以去ElasticMQ的代码仓库提交Issue，附上你的测试用例（比如具体的非法字符、客户端计算的MD5值、ElasticMQ返回的MD5值），官方大概率会修复这个校验逻辑。

2. 自定义ElasticMQ扩展（紧急情况） #

如果你的业务需要立即解决这个问题，可以拉取ElasticMQ的源码，在消息接收的处理逻辑中添加SQS的字符范围校验，然后编译自定义版本部署使用。具体可以找到消息校验的相关模块，加入对应字符范围的判断逻辑。

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