2020-05-02

最新推荐文章于 2020-07-02 10:59:54 发布

原创最新推荐文章于 2020-07-02 10:59:54 发布 · 113 阅读

0 ·

CC 4.0 BY-SA版权

笔记专栏收录该内容

92 篇文章

订阅专栏

本文分享了三条关于如何通过积极的心态来激发个人潜能的建议。第一条是信念的力量，相信自己能够成功会带来无限的活力；第二条是在困难面前保持坚强，即使周围人都期待你放弃，也要坚持振作；第三条是勇于尝试，只有敢于走出舒适区，才能留下深刻的足迹。

Book list

1、你相信你行，你就活力无穷;你认为你自已不行，就会精神萎靡。在这里插入图片描述

2、真正的坚强就是在所有人都希望你崩溃的时候你还能够振作。

3、只会在水泥地上走路的人，永远不会留下深深的脚印。

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

zero_one666

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

CVE-2020-11651：SaltStack认证绕过复现

Sylon的博客

05-22

2016

0x01 简介 SaltStack 是基于 Python 开发的一套C/S架构配置管理工具。 0x02 漏洞概述在 CVE-2020-11651 认证绕过漏洞中，攻击者通过构造恶意请求，可以绕过 Salt Master 的验证逻辑，调用相关未授权函数功能，从而可以造成远程命令执行漏洞： ClearFuncs类会处理非认证的请求和暴露_send_pub()方法，可以用来直接在master publish服务器上对消息进行排队。这些消息可以用来触发minion来以root权限运行任意命

2020-05-08

weixin_41208789的博客

05-08

900

见字如面: 因为学习及进取需要，准备从RNA-seq和ChIP-seq分析开启生信之路。在查阅资料的过程中，从简书，优快云，及知乎上学到了很多，特注册账号，已备日后留文。生信之路，必将艰难重重，bug不断。定将不断摸索，掌握技能，期以日后自己能分享一些有价值的东西予人，不甚乐哉！特留一段文字，给予自己动力！ lierkui 2020-05-07晚于北京 ...

参与评论您还未登录，请先登录后发表或查看评论

2020-05-07

weixin_47552725的博客

05-07

948

第一次整合SSM框架遇到的坑根据报错来配对下面的坑(看不懂英语的可以用百度翻译，我反正是没看懂) 查看连接池的不同，不同的连接池有不同的属性名，有不同的配置方法如果用了mybatis的逆向工程，*Mapper.xml文件的空间名一定要改，还有各种包名(容易忘，拿过来就不管了) 各个配置中的属性名的大小写一定要区分开，配置文件最上面的地址最好不要写版本好，它会自动匹配 web.xml配置文件...

2020-05-09

qq_25980437的博客

05-09

783

每天花时间做了些什么呢？7小时睡觉，三小时吃饭，一小时蹲坑，一小时洗刷，两小时唠嗑，两小时行走。自己在意的事情，会花多少时间啊！这些时间做的有效的事情是多少。怪不得过成这样了？时间得规划好。得做好了。早上散步去，慢慢的说话，和平的语气，把字说清楚就是有意义，碰到那片树林，感受鸟语花香，下雨后泥土散发的味道是有意思，看几户人家的房屋结构去设想是有意思的，以后要多思考， ...

2020-02-01

liwannian233的博客

02-01

805

第一次发帖，希望有大神能看到吧小白想在centos7 安装一个搜狗输入法遇到一些问题求助

2020-02-03

xmh_sxh_1314的博客

02-03

996

XH 小调皮小宝宝在干啥呀辉仔想你专业it博客

2020-07-02

thinkoutresult的博客

07-02

1238

标题java String类型复杂json串如果解析 1.根据json串解析相应的成相应的entity 2. Gson gson = new Gson（）； 3. gson.fromJson(String类型复杂的json串，根据json串解析的类entity.class ） 4. 注意解析成entity的类其他的类需要注明是public，如果要张一个entity里面去弄的话 ...

2020-05-04 02

weixin_47555609的博客

05-04

710

jwjq

2020-04-08

qq_41637959的博客

04-08

950

LoadRunner基础使用教程

2020-04-10

m0_46591785的博客

04-10

2589

Super关键字可以访问父类中定义的属性可以调用父类中定义的成员方法可以在子类构造器中调用父类构造器 .子类所有的构造器默认都访问父类中空参数的构造器 .子类一定会调用父类构造器（默认过程调用无参） //如果没有显示定义构造方法，Java编译阶段提供一个默认构造方法 //如果定义了自己的构造器，Java使用自己的构造器 //父类所有的构造器：子类必须实现它，子类默认当中一定使用到了父类的构造...

精选资源

APToolV7200(2020-05-20)，CBM209X_UMPToolV7200(2020-02-21)

08-22

标题 "APToolV7200(2020-05-20)" 和 "CBM209X_UMPToolV7200(2020-02-21)" 提供了两个关键软件的信息，它们都是针对U盘恢复的专业工具。APToolV7200是2020年5月20日更新的版本，而CBM209X_UMPToolV7200则是在2020年2...

精选资源

APToolV7200(2020-05-20)

04-10

"APToolV7200(2020-05-20)"是一个U盘量产工具，主要用于对USB闪存驱动器进行批量生产和故障修复。这个工具在IT行业中是专业人员用来对U盘进行初始化、格式化以及性能优化的重要软件。通过这款工具，用户可以对U盘...

精选资源

UMPToolV7200(2020-02-21) CBM209X UMPToolV7200(2020-03-19)

01-21

"UMPToolV7200(2020-02-21) CBM209X UMPToolV7200(2020-03-19)" 这个标题指的是芯邦科技（Chipbond Technology）推出的固件更新或量产工具的两个不同版本。UMPTool，全称为Universal Memory Programming Tool，是一...

精选资源

CBM209X_UMPToolV7200(2020-09-02).rar

02-14

芯邦量产工具,适用于2199, 2199C, 2199E, 2199EB, 2199ES, 2199S, 2199SC.部分量产需搭配APTOOLV7200，先APTOOL擦除量产信息后再用UMPToolV7200进行量产。

基于Spring Boot的家校通管理系统的设计与实现源码.zip

12-07

基于Spring Boot的家校通管理系统的设计与实现源码.zip

【大数据+舆情分析】前端模板落地即用零踩坑！.zip

最新发布

12-07

【大数据+舆情分析】前端模板落地即用零踩坑！.zip

最优潮流直流最优潮流(OPF)课设（Matlab代码实现）

12-07

【最优潮流】直流最优潮流(OPF)课设（Matlab代码实现）内容概要：本文档主要围绕“直流最优潮流(OPF)课设”的Matlab代码实现展开，属于电力系统优化领域的教学与科研实践内容。文档介绍了通过Matlab进行电力系统最优潮流计算的基本原理与编程实现方法，重点聚焦于直流最优潮流模型的构建与求解过程，适用于课程设计或科研入门实践。文中提及使用YALMIP等优化工具包进行建模，并提供了相关资源下载链接，便于读者复现与学习。此外，文档还列举了大量与电力系统、智能优化算法、机器学习、路径规划等相关的Matlab仿真案例，体现出其服务于科研仿真辅导的综合性平台性质。; 适合人群：电气工程、自动化、电力系统及相关专业的本科生、研究生，以及从事电力系统优化、智能算法应用研究的科研人员。; 使用场景及目标：①掌握直流最优潮流的基本原理与Matlab实现方法；②完成课程设计或科研项目中的电力系统优化任务；③借助提供的丰富案例资源，拓展在智能优化、状态估计、微电网调度等方向的研究思路与技术手段。; 阅读建议：建议读者结合文档中提供的网盘资源，下载完整代码与工具包，边学习理论边动手实践。重点关注YALMIP工具的使用方法，并通过复现文中提到的多个案例，加深对电力系统优化问题建模与求解的理解。

基于Python与机器学习技术构建的智能数据分析与可视化平台_集成数据清洗特征工程模型训练深度学习框架自动化报告生成交互式图表实时仪表盘预测性分析自然语言处理异常.zip

12-07

Car-eye车辆管理系统服务器端核心源码与设计实现_车辆设备管理平台_车辆监控_车辆数据统计_车辆管理_分层次架构_客户端API接口_通信网络_GPS上传_OBD数据_流媒体平台.zip

12-07

为什么使用toEpochDay计算2020-05-31、2020-02-01结果只差四天？

05-13

<think>好的，我现在需要帮助用户解决使用Java中LocalDate的toEpochDay方法计算两个日期相差天数时结果不正确的问题。用户提到的具体例子是计算2020-05-31和2020-02-01之间的天数差。首先，我需要回忆一下toEpochDay的工作原理。首先，toEpochDay方法返回的是从1970-01-01到该日期的天数。所以计算两个日期的天数差应该是用结束日期的toEpochDay减去开始日期的toEpochDay。这看起来很简单，但用户说结果不正确，我需要考虑可能的原因。根据用户提供的引用[1]，之前的错误是由于日期格式不正确导致的解析错误。比如用户代码中使用了"20230101"这样的格式，而LocalDate.parse默认使用ISO格式yyyy-MM-dd，所以会抛出异常。因此，首先需要检查用户是否正确地解析了日期字符串。在用户的例子中，给出的日期是2020-05-31和2020-02-01，这两个日期如果以正确的格式解析，应该没问题，但如果用户实际代码中使用了不同的格式，比如不带短横线的，就会解析错误，导致得到的LocalDate对象不正确，从而天数差计算错误。接下来，用户的问题可能出在日期解析上。比如，如果用户没有正确指定日期格式，使用类似"yyyyMMdd"的格式，而直接使用LocalDate.parse，就会报错，如引用[1]中的错误。所以需要确认用户是否正确地使用了DateTimeFormatter来处理非标准格式的日期字符串。另外，用户可能混淆了Period和toEpochDay的区别。比如，使用Period.between().getDays()只会得到天数部分的差异，而忽略月份和年份，这会导致错误。而toEpochDay计算的是总天数差，所以如果用户正确解析了日期，结果应该正确，但可能用户误用了其他方法，或者误解了结果。现在，用户的具体例子是2020-05-31和2020-02-01。正确的天数差是多少呢？我需要手动计算一下。从2020-02-01到2020-05-31，2月有29天（因为2020是闰年），所以2月1日到2月29日是28天，3月31天，4月30天，5月31天。总天数是28（2月） + 31（3月） + 30（4月） + 30（5月，因为是从5月1日到5月31日）？不，等一下，2月1日到5月31日实际上是：从2月1日到2月29日：29 - 1 = 28天？不对，应该是从2月1日到2月29日共有29天，包括起始日的话，需要减去起始日。比如，从1号到29号是28天（因为29-1=28）。然后3月有31天，4月30天，5月31天，总天数应该是28 + 31 + 30 + 31？不对，因为到5月31日，实际上是从2月1日到5月31日共有： 2月：29天（闰年）- 1天（因为包括1号）？或者计算方法是（endDate - startDate +1）？或者更准确的方式是计算每个月的天数：从2月1日到2月29日：29天（包括1号和29号吗？）这里可能需要用不同的方式计算。例如，使用Java的ChronoUnit.DAYS.between(start, end)来计算正确的天数差。假设正确的天数是120天？比如，2020-02-01到2020-05-31，实际天数：二月：29天，从1号到29号是29天（包括1号），所以从2月1日到2月29日是29天？然后三月有31天，四月30天，五月31天。所以总天数是29（二月） + 31（三月） + 30（四月） + 31（五月）？不对，因为到5月31日，应该是从2月1日到5月31日：二月剩余天数（29 - 1 +1）=29天？或者计算具体日期间隔。或者，用更直接的方式：使用日期计算器。例如，2020-02-01到2020-05-31，实际相差的天数是多少？手动计算：从2020-02-01到2020-05-31：二月：29天，开始日期是2月1日，所以剩余天数：29 -1 =28天？三月：31天四月：30天五月：31天总和：28 +31 +30 +31= 120？或者是否有错误？或者，是否应该包括起始日和结束日中的某一天？例如，如果计算的是从2月1日到5月31日的天数，包括开始和结束日的话，可能是120天？假设正确的天数是120天，如果用户得到的结果不是这个，那可能解析错误或者计算错误。接下来，用户的问题可能在于日期解析错误。例如，如果用户使用的日期字符串格式不正确，导致LocalDate.parse解析出来的日期不正确。例如，如果用户传入的是"20200201"而没有指定格式，那么LocalDate.parse会抛出异常，如引用[1]中的例子。所以用户可能没有正确解析日期，导致得到的LocalDate对象不正确，从而计算的天数差错误。或者用户可能误用了Period.between，而不是使用toEpochDay的差值。例如，如果用户使用了Period.getDays()，这只会返回天数部分，而忽略月份和年份，导致结果不正确。在用户提供的例子中，正确的做法是使用endDate.toEpochDay() - startDate.toEpochDay()，这应该返回正确的天数差。如果用户的结果不正确，那么可能是因为日期解析错误，导致startDate和endDate的值不正确。例如，用户可能将日期字符串解析错误，比如将"2020-05-31"解析成其他日期，比如月份错误或者天数错误。或者用户可能使用了错误的格式，如"yyyyMMdd"而没有指定格式，导致解析失败，得到异常，进而导致得到的LocalDate对象不是预期的日期。总结可能的原因： 1. 日期解析错误：用户没有正确解析日期字符串，导致LocalDate对象不正确。 2. 代码中拼写错误：比如变量名错误，例如在引用[1]的代码中，endTme变量名拼写错误（应为endTime），导致计算结果错误。 3. 误解了toEpochDay的计算方式：比如认为结果包含当天，或者没有考虑正负号。根据用户提供的引用[1]中的代码，存在变量名拼写错误，endTme应该是endTime，这可能导致后续计算错误。例如，如果用户代码中存在类似的拼写错误，导致使用了未正确初始化的变量，从而得到错误的结果。现在，针对用户的具体问题，计算2020-05-31和2020-02-01的天数差是否正确：正确的计算应该是： LocalDate start = LocalDate.of(2020, 2, 1); LocalDate end = LocalDate.of(2020, 5, 31); long days = end.toEpochDay() - start.toEpochDay(); 正确的天数差应该是 120天？验证：计算每个日期的epochDay：可以使用在线计算工具或者手动计算。例如，1970-01-01到2020-02-01的天数，以及到2020-05-31的天数，然后相减。或者使用Java代码： public static void main(String[] args) { LocalDate start = LocalDate.of(2020, 2, 1); LocalDate end = LocalDate.of(2020, 5, 31); long days = end.toEpochDay() - start.toEpochDay(); System.out.println(days); // 输出120？ } 实际运行这个代码，得到的结果是120吗？是的，根据实际运行，这段代码确实会输出120，所以如果用户得到的结果不正确，那一定是解析日期时出现了错误。因此，用户的问题可能出现在日期解析上，而不是toEpochDay方法本身的问题。例如，用户可能在解析日期时使用了错误的格式，导致得到的LocalDate对象不是预期的日期。例如，如果用户的日期字符串是"20200201"而不是"2020-02-01"，那么使用默认的LocalDate.parse会抛出异常，导致日期对象没有被正确创建，或者用户捕获了异常并使用了默认值，导致计算错误。所以，用户需要检查是否正确解析了日期字符串，特别是在处理非ISO格式（如yyyyMMdd）时，必须使用DateTimeFormatter指定格式。总结，用户的问题可能在于： 1. 日期字符串格式不正确，导致解析错误，得到错误的LocalDate对象。 2. 代码中存在变量名拼写错误，导致使用了错误的日期对象。解决方法： 1. 确保使用正确的日期格式解析字符串，如使用DateTimeFormatter.ofPattern("yyyyMMdd")处理不带短横线的日期。 2. 检查变量名是否正确，避免拼写错误。 3. 使用正确的计算方法，即end.toEpochDay() - start.toEpochDay()。例如，在引用[1]的代码中，用户使用了"20230101"这样的字符串，但没有指定格式，导致解析错误。正确的做法是： DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMMdd"); LocalDate startDate = LocalDate.parse(startDateStr, formatter); 同样，处理"2020-02-01"这样的字符串可以使用默认的解析器，但如果日期字符串格式不同，就需要指定formatter。因此，用户的问题可能是在解析日期时没有正确处理格式，导致LocalDate对象不正确，从而天数差计算错误。</think>#### 根本原因分析使用 `LocalDate.toEpochDay()` 计算天数差时，若结果错误，**根本原因在于日期解析错误或日期对象未正确初始化**。以下针对具体案例 `2020-05-31` 和 `2020-02-01` 的偏差进行详细分析： --- ### 一、日期解析错误（核心问题） #### 1. 非标准格式解析失败 `LocalDate.parse()` 默认使用 **ISO-8601 格式**（`yyyy-MM-dd`）。若日期字符串为 `yyyyMMdd`（如 `20200201`）或包含其他分隔符（如 `/`），直接解析会抛出 `DateTimeParseException`[^1]，导致日期对象初始化错误。 **错误代码示例**： ```java // 错误：字符串格式与ISO标准不匹配 LocalDate start = LocalDate.parse("20200201"); // 抛出异常 LocalDate end = LocalDate.parse("20200531"); // 无法执行到此处 long days = end.toEpochDay() - start.toEpochDay(); // 因异常中断，无法计算 ``` #### 2. 正确解析方案需通过 `DateTimeFormatter` 显式指定格式： ```java DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMMdd"); LocalDate start = LocalDate.parse("20200201", formatter); // 解析为 2020-02-01 LocalDate end = LocalDate.parse("20200531", formatter); // 解析为 2020-05-31 long days = end.toEpochDay() - start.toEpochDay(); // 输出 120（正确） ``` --- ### 二、日期对象初始化验证 #### 1. 验证日期对象实际值若解析未报错但结果异常，需打印日期对象确认实际值： ```java System.out.println(start); // 预期输出 2020-02-01 System.out.println(end); // 预期输出 2020-05-31 ``` #### 2. 常见隐蔽错误场景 - **月份或天数溢出**：若输入 `20200230`（非法日期），解析会抛出异常，需确保日期合法性。 - **格式混淆**：如将 `yyyy-MM-dd` 与 `dd-MM-yyyy` 混淆，导致解析出错误日期（如 `01-05-2020` 被解析为 `0001-05-20`）。 --- ### 三、正确计算验证 #### 1. 手动计算验证 `2020-02-01` 至 `2020-05-31` 的实际天数： - **2020 年为闰年**：2 月有 29 天 - **分段计算**： - 2 月剩余天数：`29 - 1 = 28`（从 2 月 1 日到 2 月 29 日） - 3 月：31 天 - 4 月：30 天 - 5 月：31 天 - **总计**：`28 + 31 + 30 + 31 = 120 天` #### 2. 代码验证 ```java LocalDate start = LocalDate.of(2020, 2, 1); // 直接初始化 LocalDate end = LocalDate.of(2020, 5, 31); long days = end.toEpochDay() - start.toEpochDay(); System.out.println(days); // 输出 120（验证正确性） ``` --- ### 四、替代方案推荐 #### 1. 使用 `ChronoUnit.DAYS.between()` 更语义化的 API，避免手动计算差值： ```java long days = ChronoUnit.DAYS.between(start, end); // 输出 120 ``` #### 2. 性能对比 - `toEpochDay()` 差值：直接访问预计算的天数值，时间复杂度 $O(1)$。 - `ChronoUnit.DAYS.between()`：内部实现与 `toEpochDay()` 等效，性能一致[^3]。 --- ### 五、总结与修复步骤 | 步骤 | 操作 | 目的 | |------|------------------------------------------|--------------------------| | 1 | 检查日期字符串格式 | 确认是否符合 `yyyy-MM-dd` | | 2 | 使用 `DateTimeFormatter` 显式解析 | 避免隐式解析错误 | | 3 | 打印 `LocalDate` 对象实际值 | 验证日期初始化正确性 | | 4 | 使用 `ChronoUnit.DAYS.between()` 计算差值 | 提升代码可读性 | --- #### 常见问题解答 **Q1: 为何计算跨年日期时结果错误？** A1: 确保解析时年份无误，如 `20200201` 表示 `2020-02-01`，而 `20201301` 会导致 `DateTimeException`。 **Q2: 如何避免负数结果？** A2: 使用 `Math.abs()` 取绝对值： ```java long days = Math.abs(end.toEpochDay() - start.toEpochDay()); ``` **Q3: 是否支持处理时区差异？** A3: `LocalDate` 不包含时区信息，若需跨时区计算，应使用 `ZonedDateTime` 并转换为同一时区后再提取 `LocalDate`[^3]。