【BUG记录】Apifox 参数传入 + 号变成空格的 BUG
文章目录
- 1. 问题描述
- 2. 原因
- 2.1 编码
- 2.2 解码
- 3. 解决方法
1. 问题描述
之前写了一个接口，用 Apifox 请求，参数传入一个 +86 的电话，结果到服务器 + 就变成空格了。
Java 接收请求的接口：
2. 原因
2.1 编码
进行 URL 请求的时候我们需要用 URLEncoder 对参数进行编码，下面是编码的规则。
/**
* Utility class for HTML form encoding. This class contains static methods
* for converting a String to the <CODE>application/x-www-form-urlencoded</CODE> MIME
* format. For more information about HTML form encoding, consult the HTML
* <A HREF="http://www.w3.org/TR/html4/">specification</A>.
*
* <p>
* When encoding a String, the following rules apply:
*
* <ul>
* <li>The alphanumeric characters "{@code a}" through
* "{@code z}", "{@code A}" through
* "{@code Z}" and "{@code 0}"
* through "{@code 9}" remain the same.
* <li>The special characters "{@code .}",
* "{@code -}", "{@code *}", and
* "{@code _}" remain the same.
* <li>The space character " " is
* converted into a plus sign "{@code +}".
* <li>All other characters are unsafe and are first converted into
* one or more bytes using some encoding scheme. Then each byte is
* represented by the 3-character string
* "<i>{@code %xy}</i>", where <i>xy</i> is the
* two-digit hexadecimal representation of the byte.
* The recommended encoding scheme to use is UTF-8. However,
* for compatibility reasons, if an encoding is not specified,
* then the default encoding of the platform is used.
* </ul>
*
* <p>
* For example using UTF-8 as the encoding scheme the string "The
* string ü@foo-bar" would get converted to
* "The+string+%C3%BC%40foo-bar" because in UTF-8 the character
* ü is encoded as two bytes C3 (hex) and BC (hex), and the
* character @ is encoded as one byte 40 (hex).
*
* @author Herb Jellinek
* @since JDK1.0
*/
public class URLEncoder {
...
}
直接上 GPT，解释如下：
-
保留字符：
- 字母（a-z, A-Z）和数字（0-9）保持不变。
- 特殊字符 .（点）、-（减号）、*（星号）和 _（下划线）保持不变。
-
空格：
- 空格字符（ ）被转换为加号（+）。
-
其他字符：
- 所有其他字符被认为是“不安全的”，需要先使用某种编码方案（如UTF-8）转换为一个或多个字节，然后每个字节表示为%xy，其中xy是该字节的十六进制表示。
举个例子：假设使用UTF-8编码，字符串 “The string ü@foo-bar” 将被转换为 “The+string+%C3%BC%40foo-bar”，因为：
字符 ü 在UTF-8中编码为两个字节 C3 和 BC。
字符 @ 编码为一个字节 40。
2.2 解码
编码之后就能发送请求到服务器了，而我们直接在 Postman 上面请求的 URL 如下：
可以理解成编码之后的 URL，所以接收请求的时候同样会进行 URL 解码。那么 URL 是如何解码的呢？我们可以同样到 URLDecoder 里面去找答案：
/**
* Utility class for HTML form decoding. This class contains static methods
* for decoding a String from the <CODE>application/x-www-form-urlencoded</CODE>
* MIME format.
* <p>
* The conversion process is the reverse of that used by the URLEncoder class. It is assumed
* that all characters in the encoded string are one of the following:
* "{@code a}" through "{@code z}",
* "{@code A}" through "{@code Z}",
* "{@code 0}" through "{@code 9}", and
* "{@code -}", "{@code _}",
* "{@code .}", and "{@code *}". The
* character "{@code %}" is allowed but is interpreted
* as the start of a special escaped sequence.
* <p>
* The following rules are applied in the conversion:
*
* <ul>
* <li>The alphanumeric characters "{@code a}" through
* "{@code z}", "{@code A}" through
* "{@code Z}" and "{@code 0}"
* through "{@code 9}" remain the same.
* <li>The special characters "{@code .}",
* "{@code -}", "{@code *}", and
* "{@code _}" remain the same.
* <li>The plus sign "{@code +}" is converted into a
* space character " " .
* <li>A sequence of the form "<i>{@code %xy}</i>" will be
* treated as representing a byte where <i>xy</i> is the two-digit
* hexadecimal representation of the 8 bits. Then, all substrings
* that contain one or more of these byte sequences consecutively
* will be replaced by the character(s) whose encoding would result
* in those consecutive bytes.
* The encoding scheme used to decode these characters may be specified,
* or if unspecified, the default encoding of the platform will be used.
* </ul>
* <p>
* There are two possible ways in which this decoder could deal with
* illegal strings. It could either leave illegal characters alone or
* it could throw an {@link java.lang.IllegalArgumentException}.
* Which approach the decoder takes is left to the
* implementation.
*
* @author Mark Chamness
* @author Michael McCloskey
* @since 1.2
*/
public class URLDecoder {
...
}
还是一样，直接用 GPT 解释：
- **字母和数字：**字母a到z、A到Z和数字0到9保持不变。
- **特殊字符：**点号.、连字符-、星号*和下划线_保持不变。
- **加号：**加号+被转换为空格字符。
- **百分号编码：**形式为"%xy"的序列被视为表示一个字节，其中xy是该字节的两位十六进制表示。连续的这些字节序列将被替换为那些字节所表示的字符。字符的编码方案可以指定，如果没有指定，则使用平台的默认编码。
比如请求参数：http://localhost:8080/demo/getName?name=.-*_aA0+%2B
服务端这边的接收：.-*_aA0 +，可以看到 + 号解码成空格，同时 %2B 解码成 + 号了。因为 + 的 Ascii 十六进制就是 2B。
3. 解决方法
既然 + 号是被解码成空格了，那我们可以不把 + 号放在 URL 中，可以放在 Body 中，也就是使用 Post 请求，把参数放到请求体中传入就不会解码了。
@RequestMapping("/demo")
@RestController
public class DemoController {
@GetMapping("getName")
public void reqDemo(@RequestBody DataDemo dataDemo){
System.out.println(dataDemo.getName());
}
}
@Getter
@Setter
public class DataDemo {
private String name;
}
输出结果如下：
此外，还有一种方法，就是上面说的：传入 %2B 就行了。
如有错误，欢迎指出！！！