java.lang.IllegalArgumentException: Invalid character found in the request target The valid characters are defined in RFC 7230 and RFC 3986

java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986是一个Java异常，它表示在请求目标中找到了无效字符。RFC 7230和RFC 3986定义了请求目标中允许的有效字符范围。这个异常通常出现在HTTP请求的处理过程中。 出现这个异常的原因可能是由于请求目标中包含了不符合RFC标准的无效字符。可能是由于URL编码错误、特殊字符未正确转义等原因导致的。通常情况下，这个异常会记录在日志中，以帮助开发者定位问题。 解决这个问题的方法是确保请求目标中的字符都是符合RFC 7230和RFC 3986定义的有效字符范围。可以使用URL编码对特殊字符进行正确转义，确保请求目标的格式符合标准。另外，还可以检查代码中处理请求目标的部分，确保没有对无效字符进行处理或解析。 综上所述，java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986是一个Java异常，表示在请求目标中找到了无效字符。要解决这个问题，需要确保请求目标中的字符符合RFC标准，并且检查代码中处理请求目标的部分，确保没有对无效字符进行处理或解析。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* [java.lang.IllegalArgumentException: Invalid character found in the request target 异常](https://blog.csdn.net/weixin_46417933/article/details/122409399)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *2* *3* [java.lang.IllegalArgumentException: Invalid character found in the request target. The valid charact](https://blog.csdn.net/ab601026460/article/details/85258829)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

<think>我们正在处理一个关于HTTP请求中非法字符导致的异常问题。用户遇到了`java.lang.IllegalArgumentException: Invalid character found in the request target`异常，并希望了解如何修复。根据提供的引用信息，我们可以总结如下： ### 问题原因 1. **高版本Tomcat的严格校验**：Tomcat 8.0及以上版本遵循RFC 7230和RFC 3986规范，对URL中的字符进行了严格限制。只允许以下字符： - 英文字母（a-z，A-Z） - 数字（0-9） - 四个特殊字符：`-`、`_`、`.`、`~` - 保留字符：`!`、`*`、`'`、`(`、`)`、`;`、`:`、`@`、`&`、`=`、`+`、`$`、`,`、`/`、`?`、`#`、`[`、`]` 2. **非法字符的出现**：当URL中包含不在上述允许列表中的字符时（例如空格、中文、`{`、`}`等），就会抛出该异常。 ### 解决方案 根据引用[3]和[4]，有以下几种解决方法： #### 方法1：将GET请求改为POST请求（推荐） - 原理：POST请求通过请求体（body）传输参数，不会受到URL字符限制的影响。 - 适用场景：当参数中包含大量特殊字符或中文字符时。 #### 方法2：配置Tomcat的relaxed-query-chars属性（适用于Spring Boot） - 在Spring Boot的配置文件（application.yml或application.properties）中添加以下配置，允许额外的字符： ```yaml server: tomcat: relaxed-query-chars: ['{','}','|',' '] # 添加需要允许的字符，例如允许大括号、竖线和空格 relaxed-path-chars: ['{','}','|',' '] # 如果路径中有非法字符，也可以配置这个 ``` - 注意：`relaxed-query-chars`用于查询字符串（即?后面的参数），`relaxed-path-chars`用于路径部分。 - 示例中允许了`{`、`}`、`|`和空格，你可以根据实际出现的非法字符进行添加。 #### 方法3：对URL进行编码（前端处理） - 在发送请求之前，使用`encodeURIComponent`（JavaScript）对URL的每个参数部分进行编码，确保特殊字符被转换为百分号编码（如空格变为`%20`）。 - 示例： ```javascript let param = "含有特殊字符的参数"; let encodedParam = encodeURIComponent(param); // 编码 let url = `/path?param=${encodedParam}`; ``` - 后端接收到编码后的参数会自动解码。 #### 方法4：降级Tomcat版本（不推荐） - 降级到Tomcat 7.x或更低版本，这些版本对URL字符限制较松。但这样会失去高版本Tomcat的安全性和性能优化。 ### 注意事项 - **RFC规范**：RFC 3986规定，URL中只能包含US-ASCII字符集中的可打印字符。非ASCII字符（如中文）必须使用百分号编码（Percent-Encoding）[^1]。 - **安全风险**：允许额外的字符可能会引入安全风险，因此应谨慎添加。 ### 总结步骤 1. **定位非法字符**：检查错误日志中请求的URL，找出非法字符。 2. **选择解决方案**： - 如果参数复杂，改用POST请求。 - 如果必须用GET且字符较少，配置Tomcat的`relaxed-query-chars`。 - 确保前端对URL进行正确编码。 3. **测试**：修改后测试包含特殊字符的请求是否正常。 §§相关问题§§ 1. 如何查看Tomcat版本？ 2. 除了配置Tomcat，还有其他方法解决URL非法字符问题吗？ 3. 为什么Tomcat高版本要严格限制URL字符？ 4. 如何在Spring Boot中配置多个relaxed-query-chars字符？</think>### 问题分析与解决方案 当出现 `java.lang.IllegalArgumentException: Invalid character found in the request target` 异常时，表明 **HTTP 请求的 URL 中包含非法字符**。这是由于 Tomcat 8.0+ 版本严格遵守 RFC 7230 和 RFC 3986 规范，对 URL 字符集进行了严格限制。以下是详细原因和解决方案： --- ### 一、根本原因 1. **URL 字符限制** Tomcat 高版本（8.0+）仅允许 URL 包含以下字符： - 英文字母（`a-zA-Z`） - 数字（`0-9`） - 基础特殊字符（`-_.~`） - 保留字符（`! * ' ( ) ; : @ & = + $ , / ? # [ ]`） 其他字符（如中文、空格、`{ } |` 等）均被视为非法字符 [^3][^4]。 2. **典型触发场景** - GET 请求参数含中文或特殊符号（如 `?name=测试|123`） - URL 路径包含未编码的符号（如 `/user/{id}`） - 请求头含非法字符 --- ### 二、解决方案 #### ✅ 方法 1：修改 Tomcat 配置（推荐） 在 Spring Boot 的 `application.yml` 中添加配置，允许特定字符： ```yaml server: tomcat: relaxed-query-chars: "|,{,},[,]" # 允许 | { } [ ] 等符号 relaxed-path-chars: "|,{,},[,]" # 允许路径中的特殊字符 ``` **效果**： - 直接放宽 Tomcat 对指定字符的限制 [^3][^4]。 - 需重启服务生效。 #### ✅ 方法 2：改用 POST 请求 将 GET 请求改为 POST，通过请求体（Body）传递参数： ```http POST /api/data HTTP/1.1 Content-Type: application/json {"name": "测试|123"} ``` **优势**： - 请求体不受 URL 字符限制影响。 - 适合传输复杂数据（如中文、JSON）[^3]。 #### ✅ 方法 3：URL 编码 前端发送请求前，对参数编码： ```javascript // JavaScript 示例 encodeURIComponent("测试|123"); // 输出 "%E6%B5%8B%E8%AF%95%7C123" ``` **后端解码**： ```java // Java 示例 String param = URLDecoder.decode("%E6%B5%8B%E8%AF%95%7C123", "UTF-8"); ``` **注意**： - 编码后非法字符会转为 `%` + `十六进制值`（如空格→`%20`）。 - 确保前后端使用统一字符集（如 UTF-8）[^2][^4]。 #### ⚠️ 不推荐方案：降级 Tomcat 降低 Tomcat 版本（如改用 Tomcat 7.x）可绕过限制，但会牺牲安全性和兼容性 [^3]。 --- ### 三、预防措施 1. **代码规范** - 避免在 URL 中直接使用非 ASCII 字符（如中文）。 - 路径参数优先使用英文、数字或短横线（如 `/user/user-01`）。 2. **自动化测试** 使用工具（如 Postman）模拟含特殊字符的请求，提前发现异常。 --- ### 总结 | **场景** | **解决方案** | |------------------------|----------------------------------| | 少量特殊字符（如 `{}`） | 配置 `relaxed-query-chars` | | 复杂参数（如中文） | 改用 POST 请求或 URL 编码 | | 历史遗留系统 | 降级 Tomcat（临时方案） | > **关键点**：RFC 规范要求 URL 仅包含安全字符，高版本 Tomcat 的严格校验是为了提升安全性 [^1][^4]。通过编码或配置可平衡兼容性与安全性。