记一次url参数截断的问题

在使用GET请求批量删除ES数据时,ID列表作为URL参数传递导致最后一条ID被截断的问题。文章详细描述了问题现象,提供了通过控制参数检查数据正确性,以及建议将数据文件放置于resource目录下读取的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

问题现象

在最近的开发过程中要根据一堆id值去删除ES中的数据,就写了一个脚本接口,传入了idList。这里选择的是GET方式的接口,将idList以逗号分隔当做字符串传入当做参数,然后在接口中转换成List类型再对ES进行操作。

脚本代码

这个接口中的process是为了控制是否真正执行刷数据的逻辑,在一些刷数据的接口中加入这个参数,可以去在真正去刷数据之前,去看看捞出来的数据是否正确,然后再进行刷数据的逻辑。

@GetMapping(value = "/es/fix/removeNotConsumerData")
@ResponseBody
public boolean removeNotConsumerData(@RequestParam(value = "kdtIdList") String kdtIdListString, @RequestParam(value = "process", defaultValue = "false") boolean process) {

    List<Long> kdtIdList = Arrays.stream(kdtIdListString.split(",")).map(Long::parseLong).collect(Collectors.toList());
    log.info("要刷的数据是:{}", JSON.toJSONString(kdtIdList));
    if (!process) {
        return true;
    }

    Set<Long> successSet = Sets.newHashSet();
    Set<Long> failSet = Sets.newHashSet();

    for (Long kdtId : kdtIdList) {
        try {
            ESResult esResult = esSyncHelper.deleteDoc(EsConstant.ESV5_TEAM_INDEX, EsConstant.ESV5_TEAM_TYPE, kdtId.toString(), ESResult.class);
            Thread.sleep(200);
            if (AppConstant.SUCCESS != esResult.getCode()) {
                log.warn("刷数据失败,kdtId={}, msg:{}", kdtId, esResult.getMessage());
                failSet.add(kdtId);
            } else {
                successSet.add(kdtId);
            }
        } catch (Throwable e) {
            log.warn("刷数据异常, kdtId={}", kdtId, e);
            failSet.add(kdtId);
        }

    }

    if (kdtIdList.size() != successSet.size()) {
        log.warn("有数据删除失败, failSet={}", JSON.toJSONString(failSet));
        return false;
    } else {
        return true;
    }

}

这里在机器上进行跑的时候,先去跑了单个id数据,发现是没有问题的。之后就想一把梭去将数据跑完,就把整个id集合数据放入了url要传入的参数之中,这个时候发现出现了问题。
在这里插入图片描述
在数据的最后一条id值被截断了,只是去截止到了42122,所以这个会被转为42122存入要刷的id集合中。这个就可能去刷错了数据(所以之前的process参数还是很有用的 = =)。

这里有个比较稳的解决方案是要刷的数据可以把文件放在resource目录下,然后通过读取这个文件的内容直接去去刷数据,这样就不会存在这个问题了。这里去简单记录下这次参数被截断的过程。

<think>嗯,用户发来了一段关于使用用户ID和密码进行测试时出现乱码的问题。首先,我需要理解用户的具体情况。他们提到初始化时使用用户ID:scott和密码:tiger进行首次测试,但连接时测试失败,并且返回了乱码字符。用户想知道为什么会乱码。 首先,我应该考虑编码问题。常见的乱码原因通常是字符编码不一致,比如发送方和接收方使用了不同的编码方式,比如UTF-8和GBK之间的不匹配。例如,如果数据库或应用程序使用的是UTF-8,而客户端或终端使用的是GBK,那么中文字符可能会显示为乱码。但用户这里显示的乱码似乎包含了一些日文字符,比如“ユーザーID”和“パスワード”,这可能意味着原始信息是日文,但显示环境不支持日文字符编码,或者传输过程中编码被错误处理。 接下来,考虑数据传输过程中的问题。如果数据在传输过程中被部分损坏或截断,也可能导致乱码。比如,网络传输中的二进制数据被错误地解析为文本,或者加密解密过程中出现问题。用户提供的乱码部分包含了一些特殊符号和非打印字符,这可能表示二进制数据被直接以文本形式显示,而没有正确的解析。 另外,数据库连接的问题也可能导致这种情况。例如,如果连接字符串没有正确指定字符集,或者数据库驱动版本不兼容,可能会导致返回的数据无法正确解码。特别是当数据库中的某些字段存储了二进制数据或加密后的内容时,如果应用程序尝试将这些二进制数据当作字符串处理,就会出现乱码。 还有可能的是日志或错误信息本身被加密或压缩。有些系统在录错误信息时可能会进行加密处理,如果查看日志的工具没有相应的解密能力,就会显示为乱码。或者错误信息在传输过程中被压缩,但接收端没有解压,导致显示异常。 此外,客户端软件的兼容性问题也不容忽视。比如,使用的数据库客户端工具版本过旧,无法正确处理服务器返回的数据格式,或者终端模拟器的编码设置不正确,都可能导致显示乱码。 最后,需要检查是否有配置错误。比如,数据库的NLS_LANG参数设置不正确,或者应用程序的字符集配置与数据库不一致,都可能导致乱码问题。特别是在多语言环境中,正确的区域设置和字符集配置至关重要。 综合这些可能性,用户的问题可能出在编码不一致、数据传输错误、数据库连接配置或客户端设置等方面。建议用户逐步检查这些方面,比如验证编码设置、检查网络传输的完整性、确认数据库和客户端的字符集配置是否匹配,以及查看是否有加密或压缩导致的数据无法解析。</think>您遇到的乱码问题可能由多个系统级原因导致,以下是逐步分析及解决方案: **一、编码不一致(最常见原因)** 1. 数据库字符集检查:Oracle数据库默认使用`WE8ISO8859P1`字符集,而客户端如果是UTF-8环境 ```sql SELECT * FROM nls_database_parameters WHERE parameter LIKE '%CHARACTERSET%'; ``` 2. 客户端NLS_LANG设置验证 ```shell # Windows查看 echo %NLS_LANG% # Linux/Mac查看 echo $NLS_LANG ``` 正确配置示例:`export NLS_LANG=JAPANESE_JAPAN.AL32UTF8` **二、二进制协议错误解析** 1. 当使用SQL*Plus等工具连接时,若出现`��)E `类乱码,可能是: - TNS协议数据被直接输出 - 网络抓包验证(需DBA权限) ```shell tcpdump -i any -s 0 -w oracle.pcap port 1521 ``` **三、驱动兼容性问题** 1. JDBC连接时应指定字符集 ```java String url = "jdbc:oracle:thin:@host:port:SID?useUnicode=true&characterEncoding=UTF-8"; ``` 2. 检查驱动版本 ```sql SELECT * FROM v$version; ``` **四、密码加密机制导致** 1. Oracle 11g后默认使用SHA1加密 ```sql SELECT password, spare4 FROM sys.user$ WHERE name='SCOTT'; ``` 输出应为`S:XXXXXXXXXXXXXXXXXXXX`格式 **五、调试建议** 1. 使用SQL*Plus进行基础测试 ```shell sqlplus scott/tiger@//host:port/service_name ``` 2. 开启10046跟踪事件 ```sql ALTER SESSION SET events '10046 trace name context forever, level 12'; ``` **典型解决方案流程:** 1. 确认客户端/服务端字符集一致 2. 验证网络传输完整性(telnet端口1521) 3. 使用Wireshark分析TNS协议 4. 检查sqlnet.log和listener.log 5. 尝试使用Oracle Instant Client测试 建议从字符集验证开始,若问题持续,需检查网络层数据包是否完整传输。数据库连接问题产生的二进制响应被错误解析为文本时,会产生此类乱码。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值