2024-重新开始记录

最新推荐文章于 2025-12-31 22:47:58 发布
原创 最新推荐文章于 2025-12-31 22:47:58 发布 · 176 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#生活

本文探讨了计算机视觉在AI领域的应用，以及它如何影响学习过程中的语言学知识。同时提及在工作中建立标准操作程序（SOP），并强调保持生活平衡如练习八段锦的重要性。

记录：计算机视觉； AI

# 学习

## 语言学

# 工作

## 写～ 建立SOP

# 生活

## 八段锦

## 动起来

lestat_black
关注
【系统安全】Windows 远程桌面授权服务(RDL)远程代码执行漏洞（CVE-2024-38077）
李同學的安全圈
08-14 1235
Windows远程桌面授权服务（RDL）是一个用于管理远程桌面服务许可证的组件,确保对远程桌面连接的合法性。该服务被广泛部署于开启了Windows远程桌面服务（3389端口）的服务器上,但漏洞的利用不是通过3389端口,需要先连接135端口发送访问请求,然后服务器给出一个连接RDL服务的动态高端口,再连接访问,如果服务器对外不开放135端口则不可利用
PostExpKit - CVE-2024-26229提权复现测试
潇湘信安的博客
06-25 2191
CVE-2024-26229：Windows CSC服务特权提升漏洞，csc.sys驱动程序中带有METHOD_NEITHER I/O控制代码的IOCTL地址验证不正确。当IOCTL使用METHOD_NEITHER选项进行I/O控制时，IOCTL有责任验证提供给它的地址，如果验证缺失或不正确，攻击者可以提供任意内存地址，从而导致代码执行或拒绝服务。
Windows 远程桌面授权服务远程代码执行漏洞（CVE-2024-38077）
热门推荐
企业实战系列集 ●●● https://ximenjianxue.blog.youkuaiyun.com
08-10 1万+
开启该服务（Windows 远程桌面授权服务）并且操作系统版本在受影响范围的 Windows Server 受影响，没有开启该服务但是操作系统版本在受影响范围的Windows Server 不受影响，Windows 10、Windows 11 等非 Server 版本的操作系统，不论是否开启Windows 远程桌面（RDS），均不受影响。这一漏洞存在于Windows远程桌面许可管理服务（RDL）中，该服务被广泛部署于开启Windows远程桌面（3389端口）的服务器，用于管理远程桌面连接许可。
CVE-2024-21762漏洞分析
zgz67611的博客
12-20 3095
FortiGate今年来连续爆出多个高危漏洞，其中一个严重级别漏洞CVE-2024-21762是SSL VPN的内存未授权越界写入仅有的2个字节\r\n导致了RCE。漏洞利用链比较巧妙, 非常值得学习的, 这里记录一下从环境搭建到漏洞分析再到漏洞利用getshell的完整过程。通过网络空间测绘平台进行威胁分析，全球大约有超过数万台Fortigate VPN设备存在漏洞，涉及国防、政府、大型企业，影响面还是比较大的。
CVE2024-1086 nftables UAF漏洞
凯峰的日志
06-12 3491
具作者介绍，该漏洞影响从 v5.14（包括）到 v6.6（包括）的版本，但不包括已修补的分支 v5.15.149>、v6.1.76>、v6.6.15>。关闭nf_tables模块只要使用的还是iptables基本就没啥影响，只是新的类似于iptables防火墙功能的nft无法使用而已。一次，而不需要``make clean`.另外编译新内核时候不要使用其他人分享的内核的config编译参数文件，可能会直接系统开不了机，尽量使用内核自带的config编辑。样例用的6.3.13复现该漏洞的提权。
CVE-2024-38077漏洞 2012R2系统更新失败
izmyzyq186的博客
08-10 1万+
官方漏洞报告链接：https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38077下载安装出现报错。
CVE-2024-45216 Authentication bypass in Apache Solr
鸣蜩十四的博客
11-19 1581
在目前可得的描述中可以得出这个漏洞主要是因为使用 PKIAuthenticationPlugin 的 Solr 实例（在使用 Solr 身份验证时默认启用）容易受到身份验证绕过的影响，下来着重分析绕过数据的传递过程
Apache Struts2 - 任意文件上传漏洞 - CVE-2024-53677
Blue17 の 小窝
02-16 1869
是美国 Apache 基金会的一个开源项目，是一套用于创建企业级 Java Web 应用的开源 MVC 框架（将软件分为模型（Model）、视图（View）和控制器（Controller）三部分）。CVE-2024-53677 是一个在 Apache Struts 框架中发现的严重漏洞，可能允许攻击者远程执行任意代码。漏洞的根本原因是文件上传逻辑存在缺陷，攻击者可以利用该缺陷进行路径穿越和恶意文件上传。
2024年最全CVE-2024-26923漏洞分析_cve-2024–26923(1)，2024最新网易网络安全面试题目
2401_84544363的博客
05-05 1464
本次漏洞产生的主要原因是计算机账户关键属性的ACL设置问题和ADCS检查客户端身份不严格导致，结合之前的samAccountName欺骗漏洞，AD域中涉及身份认证标识的问题不止一次，微软在AD域中不用具有唯一性的自动编号字段SID而是其他字段作为身份认证标识在安全方面着实欠妥。本次漏洞利用简单，流量特征不明显难以检测，同时获取的AD域证书有效时间长，因此对于AD域的提权和权限维持都有很高的利用价值。
IDEA配置Java远程调试，以CVE-2024-4956为例
iamblackcat's blog
06-03 2544
本文记录学习Java远程调试环境搭建的过程，并使用docker容器搭建环境，分析CVE-2024-4956
精选资源
IB Specification Vol 1-Release-1.9-Draft-2024-08-31
12-18
InfiniBand架构规范第一卷（Volume 1）版本1.9的草案版，记录日期为2024年8月31日，是一份详尽的文档，它不仅覆盖了InfiniBand技术的发展历史，还包括了从2000年首次发布至今的各个版本的修订记录。此文档详细介绍了...
精选资源
XMind2024-mac畅享版
12-30
用户可以在思维导图中添加任务状态，标记重要信息，记录详细笔记，甚至链接到相关的文件或网页，这样可以将思维导图转变为一个信息中心，极大地提高了工作效率。 为了提升协作效率，XMind2024-mac畅享版还支持团队...
bugreport-Mi 10S-2024-10-28-103354.zip
10-28
"main_entry.txt" 文件名称可能意味着这是一个主入口文件，它可能是整个bug报告的开始，或者是系统日志文件的摘要，简明扼要地介绍了问题发生的主要情况和症状。 "version.txt" 文件中应该记录了设备的操作系统版本...
杨建允：AI搜索优化对本地生活、本地服务行业的影响
mys5518的博客
12-31 214
‌地理信息系统（GIS）整合‌：优化过程将企业地理位置信息与行业需求关联，通过LBS数据标注增强本地搜索响应能力，如针对“小区名称+3公里内”等长尾关键词优化，使本地商家在AI搜索中优先展示‌‌。‌语义精准度与意图识别‌：AI系统通过自然语言处理分析用户查询的上下文和意图，而非仅依赖关键词匹配，例如将不同表述的相似问题归类为同一意图，提升内容匹配效率‌。影响因素上，AI搜索优化在内容上要讲究客观性、专业性和权威性，AI优化的同时也要结合营销策略和用户运营策略和实实在在的服务。本地生活重在服务质量和体验。
漫步烟台：历史的棱角，与生活的柔软弧度
2401_87128333的博客
12-26 284
道路一侧是开阔的海景，另一侧则是错落的街巷。这里的建筑少有摩天大楼的压迫感，多以舒缓的坡屋顶和柔和的色调为主，米黄、浅灰的墙体，与海天的背景构成了和谐的色板。深入那些坡度平缓的老街，生活的纹理变得具体：晨练归来的老人提着布袋，临街的住户将晾晒的衣物挂在伸出窗外的竹竿上，海风将它们轻轻吹起。这座城市的气质，如同其海岸线的轮廓，既有历史沉淀的坚硬棱角，又有生活浸润的柔软弧度。青灰色的东炮台沉默地指向海的方向，下方，黄渤海交汇处的海水呈现出更为复杂的层次，近岸是温润的绿，远处则铺展为一片无垠的深蓝。
董璇张铎《不期而遇的生活》武洪武再度执导当代都市剧
2401_86584021的博客
12-26 467
由他执导，佟丽娅、李乃文、李纯、王姬、王刚主演的都市情感剧《大都市小爱情》，当年得到无数观众认可和热议，收视率和网络热度极高；在甜宠剧、古偶剧、悬疑剧充斥市场的当下，这部现实主义题材，都市生活、家庭情感剧选择回归最朴素的叙事，讲述身边普通人的日常生活。一套房，两对夫妻，从不打不相识的陌生人到和睦相融的“家人”，《不期而遇的生活》用一纸“共居”契约，勾勒当代都市人最真实的生活半径。南京这座城市的多元气质，为剧集提供了丰富的叙事画风， 它既有历史厚重感，又有现代活力，既有摩天大楼的繁华，也有市井巷弄的烟火气。
2025年12月个人工作生活总结
最新发布
李迟的专栏
12-31 339
本文为 2025年12月工作生活总结。
米悦MIY：以科技赋能健康生活，打造高端生活家电新标杆
2508_92108265的博客
12-30 396
作为健康家电行业的先行者，米悦（MIY）品牌始终坚持以科技创新为驱动、以用户健康为核心，深耕富硒与纯钛两大健康材料技术，推出包括富硒水杯、富硒电饭煲、纯钛炒锅、纯钛电饭煲等系列高品质产品，不仅赢得了千万家庭的信任，更屡获行业殊荣——“健康家电行业领导品牌”“科技创新品牌”“年度优质服务标杆品牌”“无毒害（绿色）环保品牌”“制造业消费者信赖品牌”“质量信得过品牌”等荣誉，成为新时代健康生活方式的引领者。正因如此，米悦被授予“无毒害（绿色）环保品牌”，成为家电行业绿色转型的典范。
【2025年度创作总结】从笔记到实践，从思考到生活融合
lirendada的博客
12-29 820
2025年技术成长与创作总结：本文系统回顾了作者在算法、C++工程、Linux系统、Java开发等领域的技术深耕历程。通过动态规划、高并发服务器等实战项目，以及持续的技术写作输出，构建了完整的知识体系。文章从技术体系构建、实战成果、创作历程、生活融合等维度，展现了技术学习与日常生活的平衡之道，并展望了2026年在微服务、AI等领域的深入探索计划，体现了持续成长的技术追求与人生思考。
某个表五个字段，广告id、位置、投放开始时间(start_time)、投放结束时间(end_time)、创建时间,同广告id、位置时，投放开始时间至投放结束时间段之间有时间重叠时，取最近创建时间对应的记录 例如： data = { '广告id': ['ad1', 'ad1', 'ad1', 'ad1', 'ad1', 'ad1', 'ad1','ad2', 'ad2','ad3','ad1','ad1'], '位置': ['pos1', 'pos1','pos1' , 'pos1','pos1' ,'pos1' ,'pos1' ,'pos2', 'pos2','pos3','pos1','pos1'], '投放开始时间': ['2024-01-01', '2024-01-05', '2024-01-01', '2024-01-03','2024-01-07','2023-12-07','2024-01-01', '2024-01-12','2024-01-15','2025-03-01','2025-01-01', '2025-01-03'], '投放结束时间': ['2024-01-10', '2024-01-15', '2024-01-10', '2024-01-10','2024-01-08','2024-01-31','2024-01-10', '2024-01-20','2024-01-16','2025-03-05','2025-01-06', '2025-01-05'], ' 创建时间': ['2024-01-01 10:00:00', '2024-01-02 10:00:00', '2024-01-02 10:11:00','2024-01-03 10:00:00', '2024-01-02 09:00:00', '2024-11-05 10:00:00','2024-12-01 10:00:00', '2024-12-03 10:00:00', '2024-11-02 09:00:00', '2025-01-05 10:00:00','2024-12-07 10:00:00', '2024-12-31 10:00:00'] } 输出结果： ad1 pos1 2024-01-01 2024-01-10 2024-12-01 10:00:00 ad2 pos2 2024-01-12 2024-01-20 2024-12-03 10:00:00 ad3 pos3 2025-03-01 2025-03-05 2025-01-05 10:00:00 ad1 pos1 2025-01-03 2025-01-05 2024-12-31 10:00:00
03-24
<think>嗯，用户的问题是关于如何处理同一广告ID和位置下时间重叠的记录，保留最近创建的那条。首先我需要理解用户的需求。他们有一个包含广告ID、位置、开始时间、结束时间和创建时间的表，当同一广告ID和位置的记录在时间上有重叠时，需要保留创建时间最新的那条。用户还提供了一个例子数据，希望得到正确的输出。 首先，我得确定如何检测时间重叠。两个时间段重叠的条件是：一个时间段的开始时间早于另一个时间段的结束时间，同时另一个时间段的开始时间早于这个时间段的结束时间。用数学表达式的话，就是对于两个时间段$[s1, e1]$和$[s2, e2]$，如果$s1 < e2$且$s2 < e1$，则它们重叠。 接下来，用户需要按广告ID和位置分组，然后在每个组内处理重叠的记录。处理策略是保留创建时间最新的记录。因此，步骤应该是：首先按广告ID和位置分组，然后在每个组内按创建时间降序排序，这样最新的记录排在前面。接着，遍历每条记录，检查是否与已保留的记录有时间重叠，如果没有，则保留当前记录。 不过，可能需要注意，如果有多个重叠的记录，可能需要多次比较。例如，如果较早创建的记录时间范围覆盖了多个后面的记录，但因为创建时间较旧，所以应该被覆盖掉。因此，正确的做法应该是先按创建时间从新到旧排序，然后逐个检查每条记录是否与已经保留的记录有时间重叠。如果没有重叠，则保留，否则跳过。 现在，我需要验证这个逻辑是否正确。例如，用户提供的例子中，广告ad1在pos1有多个记录。按创建时间排序后，最新的记录会被优先保留，然后后续的记录如果时间与已保留的记录重叠就会被忽略。例如，在输出中，ad1 pos1的最后两条记录是2025年的，这两个时间段可能没有重叠，或者其中一条被保留，另一条被排除？ 另外，用户提供的输出结果中有ad1 pos1的两个记录，一个是2024-12-01创建的，另一个是2024-12-31创建的，这说明这两个时间段可能没有重叠，或者虽然创建时间更早的与后面的有重叠，但后面的因为创建时间更新而被保留。需要仔细检查时间范围。 例如，最后两条记录的投放开始时间是2025-01-01和2025-01-03，结束时间是2025-01-06和2025-01-05。这两个时间段是否重叠？第一个从1号到6号，第二个从3号到5号，显然重叠。但因为第二个记录的创建时间更晚（2024-12-31），所以在处理时，应该先处理创建时间更晚的记录，也就是先处理第二个记录，然后处理第一个记录时发现其时间与已保留的第二个记录重叠，因此被排除。但用户的输出结果中却保留了这两条记录，这说明我的逻辑可能有误。 这说明，可能存在多个非重叠的记录，即使在同一组内，只要它们的时间段不重叠，即使创建时间较旧，但可能因为没有与任何已保留的记录重叠而被保留。因此，正确的处理逻辑应该是：按创建时间降序排序后，对于每条记录，如果它不与任何已保留的记录时间段重叠，则保留它。因此，可能存在多个记录被保留，只要它们的时间段互不重叠，且按创建时间顺序处理。 例如，在用户的输出中，ad1 pos1的最后两条记录的时间段是2025-01-03到2025-01-05和2025-01-01到2025-01-06，这两个时间段是重叠的。但输出结果中却都保留，这说明我的理解有误。或者可能用户提供的输出结果中，这两个记录的时间段实际上没有重叠？需要检查具体日期。 用户给出的最后两条记录的投放开始时间和结束时间分别是：'2025-01-01'到'2025-01-06'，以及'2025-01-03'到'2025-01-05'。显然，这两个时间段是重叠的。但输出结果中这两条都被保留，这意味着可能用户示例的输出有误，或者我的理解有误。 或者，可能用户的数据中存在其他情况，比如创建时间更晚的记录覆盖了之前的时间段，但时间段本身可能被分割。例如，假设排序后，先处理创建时间较晚的记录，然后处理较早的记录，如果较早的记录的时间段在已保留的记录之外，则保留。 例如，在最后两条记录中，创建时间较晚的是'2024-12-31 10:00:00'对应的记录，其时间段是2025-01-03到2025-01-05。而另一条的创建时间是'2024-12-07 10:00:00'，时间段是2025-01-01到2025-01-06。当按创建时间排序后，先处理2024-12-31的那条，时间段是3号到5号。然后处理2024-12-07的那条，时间段是1号到6号，这个时间段与已保留的3-5号重叠，所以被排除。但用户的输出结果中却显示这两条都被保留，这说明我的逻辑有问题。 这可能意味着用户提供的示例输出有误，或者我理解错了问题。或者，可能用户希望对于同一广告ID和位置，如果有多个时间段重叠，但彼此之间不连续，则都保留。例如，可能存在多个时间段不重叠的情况，但需要确保在合并后的时间段中，每个时间段都是最新的。 或者，可能用户希望将重叠的时间段合并，只保留最新的记录，覆盖旧的时间段。例如，如果有一个记录的时间段是1月1日到1月10日，创建时间较早，而另一个记录的时间段是1月5日到1月15日，创建时间较晚，那么后者会覆盖前者，最终保留后者，而前者被排除。 但用户的示例输出中，对于ad1 pos1，有多个记录被保留，比如第一条是2024-01-01到2024-01-10，创建时间是2024-12-01，这可能是因为在排序后，这条记录是创建时间最新的，而其他重叠的记录被排除。然后，在2025年的时间段中，可能存在两条记录的时间段不重叠，或者被正确处理。 现在，我需要重新仔细分析用户提供的示例数据，看看输出是否正确。 在用户的数据中，广告id为ad1，位置pos1的记录共有7条： 索引0: start=2024-01-01, end=2024-01-10, 创建时间=2024-01-01 10:00:00 索引1: start=2024-01-05, end=2024-01-15, 创建时间=2024-01-02 10:00:00 索引2: start=2024-01-01, end=2024-01-10, 创建时间=2024-01-02 10:11:00 索引3: start=2024-01-03, end=2024-01-10, 创建时间=2024-01-03 10:00:00 索引4: start=2024-01-07, end=2024-01-08, 创建时间=2024-01-02 09:00:00 索引5: start=2023-12-07, end=2024-01-31, 创建时间=2024-11-05 10:00:00 索引6: start=2024-01-01, end=2024-01-10, 创建时间=2024-12-01 10:00:00 索引10: start=2025-01-01, end=2025-01-06, 创建时间=2024-12-07 10:00:00 索引11: start=2025-01-03, end=2025-01-05, 创建时间=2024-12-31 10:00:00 现在，按广告id和位置分组，这里处理ad1 pos1的组。需要将这些记录按创建时间降序排序。创建时间从新到旧： 索引6: 2024-12-01 10:00:00 索引11: 2024-12-31 10:00:00 （注意这里索引11的创建时间其实是2024-12-31，比索引6的2024-12-01更晚，所以排序应该是索引11在前） 但用户的数据中，创建时间字段的值如下： 索引6的创建时间是'2024-12-01 10:00:00' 索引10的创建时间是'2024-12-07 10:00:00' 索引11的创建时间是'2024-12-31 10:00:00' 所以，正确的排序应该是： 索引11 → 索引10 → 索引6 → 索引5 → 索引3 → 索引2 → 索引1 → 索引0 → 索引4（创建时间较早） 所以，在ad1 pos1组内，按创建时间降序排序后的顺序是： 索引11 → 创建时间2024-12-31 索引10 → 2024-12-07 索引6 → 2024-12-01 索引5 → 2024-11-05 其他更早的... 现在，处理这些记录： 首先处理索引11：时间段2025-01-03到2025-01-05，加入结果列表。 接下来处理索引10：时间段2025-01-01到2025-01-06。检查是否与结果列表中的记录（即索引11）重叠。索引11的时间段是3号到5号，索引10的时间段是1号到6号，两者重叠，所以索引10会被排除，因为索引11的创建时间更晚，所以索引10的时间段与索引11重叠，因此不被保留。 接下来处理索引6：时间段2024-01-01到2024-01-10。检查是否与结果列表中的现有记录（目前只有索引11）的时间段重叠。索引11的时间段是2025年的，与索引6的时间段没有重叠，所以保留索引6。 然后处理索引5：时间段2023-12-07到2024-01-31。此时需要检查是否与已保留的记录（索引11和索引6）重叠。索引6的时间段是2024-01-01到2024-01-10，索引5的时间段是2023-12-07到2024-01-31，显然重叠。因为索引5的创建时间早于索引6，所以索引5被排除。 接着处理其他更早的记录，如索引3、2、1、0、4，这些记录的创建时间都早于已保留的索引6和11，且它们的时间段可能与索引6的时间段重叠，因此会被排除。 因此，在ad1 pos1组中，最终保留的记录应该是索引11和索引6。但用户的示例输出中，ad1 pos1有两条记录：一条是2024-12-01创建的（索引6），另一条是2024-12-31创建的（索引11）。此外，还有一条索引5的记录？或者可能我哪里弄错了？ 但用户的示例输出中，对于ad1 pos1，输出是： ad1 pos1 2024-01-01 2024-01-10 2024-12-01 10:00:00 ad1 pos1 2025-01-03 2025-01-05 2024-12-31 10:00:00 这说明这两条记录被保留，它们的投放时间段分别是2024-01-01到2024-01-10和2025-01-03到2025-01-05，这两个时间段没有重叠，所以都被保留。而索引5的记录时间段是2023-12-07到2024-01-31，与索引6的记录时间段重叠，但创建时间较早，所以被排除。 另外，索引10的记录时间段是2025-01-01到2025-01-06，与索引11的记录时间段（2025-01-03到2025-01-05）重叠，所以被排除。 因此，正确的逻辑应该是： 1. 按广告ID和位置分组。 2. 在每个组内，按创建时间降序排序。 3. 初始化一个空列表来保存不重叠的记录。 4. 遍历排序后的记录，对于每条记录，检查它是否与已保存的记录中的任何一条有时间重叠。如果没有重叠，则添加到已保存列表。 这样，可以确保保留的是创建时间最新的且时间段不重叠的记录。 因此，处理步骤如下： - 对于每个组（广告ID + 位置），按创建时间从新到旧排序。 - 遍历每条记录，检查当前记录的时间段是否与已选中的记录时间段有重叠。 - 如果没有重叠，则保留该记录。 这样，最终保留的记录都是创建时间最新的，并且时间段不重叠。 现在，验证用户的示例输出是否符合这个逻辑： 在ad1 pos1组中，排序后的第一条记录是索引11（创建时间2024-12-31），时间段2025-01-03到2025-01-05。添加到结果。 接下来是索引10（创建时间2024-12-07），时间段2025-01-01到2025-01-06。与索引11的时间段重叠，所以不保留。 然后是索引6（创建时间2024-12-01），时间段2024-01-01到2024-01-10。不与索引11的时间段重叠，所以保留。 接下来是索引5（创建时间2024-11-05），时间段2023-12-07到2024-01-31。与索引6的时间段重叠，所以不保留。 其他更早的记录都会被排除。 所以结果中保留的是索引11和索引6，对应输出中的两条记录。这符合用户的示例输出。 另一个例子是ad2 pos2的记录： 广告id为ad2，位置pos2的记录有两条： 索引7: start=2024-01-12, end=2024-01-20，创建时间=2024-12-03 10:00:00 索引8: start=2024-01-15, end=2024-01-16，创建时间=2024-11-02 09:00:00 按创建时间排序，索引7的创建时间更晚。检查时间段，索引7的时间段是12号到20号，索引8的时间段是15号到16号，显然重叠。因此只保留索引7的记录，输出正确。 对于ad3 pos3，只有一条记录，自然保留。 因此，正确的处理逻辑是： 按广告ID和位置分组 → 组内按创建时间降序排序 → 保留那些时间段不与已保留记录重叠的记录。 现在，如何用SQL或编程实现这个逻辑？ 在编程实现中，可以用Python来处理。步骤： 1. 将数据转换为DataFrame（例如使用pandas）。 2. 按广告id和位置分组。 3. 对每个组内的记录按创建时间降序排序。 4. 遍历每个组内的记录，维护一个列表保存已保留的记录时间段。 5. 对于当前记录，检查其时间段是否与已保留的任何一个时间段重叠。如果不重叠，则保留，并添加到已保留列表。 如何高效检查时间段重叠？ 可以写一个函数，判断两个时间段是否有重叠： def is_overlap(start1, end1, start2, end2): return start1 < end2 and start2 < end1 在Python中，需要先将日期字符串转换为可比较的对象，比如datetime。 具体实现步骤： - 转换所有时间列为datetime类型。 - 分组处理。 - 对每个组，排序后遍历，检查重叠。 现在，编写这个逻辑的伪代码： import pandas as pd from datetime import datetime # 转换数据 df = pd.DataFrame(data) df['投放开始时间'] = pd.to_datetime(df['投放开始时间']) df['投放结束时间'] = pd.to_datetime(df['投放结束时间']) df['创建时间'] = pd.to_datetime(df['创建时间']) # 按广告id和位置分组 groups = df.groupby(['广告id', '位置']) result = [] for (ad_id, pos), group in groups: # 按创建时间降序排序 sorted_group = group.sort_values('创建时间', ascending=False) kept = [] for idx, row in sorted_group.iterrows(): overlap = False # 检查与已保留记录的时间重叠 for kept_row in kept: # 判断是否有重叠 if (row['投放开始时间'] < kept_row['投放结束时间']) and (kept_row['投放开始时间'] < row['投放结束时间']): overlap = True break if not overlap: kept.append(row) # 将保留的记录添加到结果 for r in kept: result.append(r) # 转换为DataFrame并输出 result_df = pd.DataFrame(result).sort_values(['广告id', '位置', '创建时间'], ascending=[True, True, False]) 这样处理后的结果应该符合用户示例的输出。 但需要注意，在用户的示例输出中，ad1 pos1的两条记录的时间段是2024-01-01到2024-01-10和2025-01-03到2025-01-05，这两个时间段没有重叠，因此都被保留。而创建时间较晚的排在前面，但因为时间段不重叠，所以都保留。 因此，这个逻辑是正确的。 总结解决步骤： 1. 数据预处理：转换时间字段为datetime类型。 2. 分组：按照广告ID和位置进行分组。 3. 组内处理： a. 按创建时间降序排序，确保优先处理最新记录。 b. 遍历每条记录，检查其时间段是否与已保留的记录重叠。 c. 若无重叠，则保留该记录。 4. 收集所有组的保留记录作为最终结果。 这种方法确保了在重叠的情况下，只保留创建时间最新的记录，并且所有保留的记录时间段互不重叠。</think>要解决广告时段重叠时保留最新创建记录的问题，可以按以下步骤操作： $$流程图伪代码 开始 ├─ 按广告ID和位置分组 ├─ 组内按创建时间降序排序 ├─ 初始化空保留列表 ├─ 遍历排序后的记录： │ ├─ 与保留列表所有记录进行时段比对 │ └─ 无重叠时加入保留列表 └─ 输出最终保留记录 结束 $$ ### 具体实现步骤 1. **数据预处理** 将时间字段转换为可比较的datetime类型： ```python import pandas as pd df['投放开始时间'] = pd.to_datetime(df['投放开始时间']) df['投放结束时间'] = pd.to_datetime(df['投放结束时间']) df['创建时间'] = pd.to_datetime(df['创建时间']) ``` 2. **核心处理逻辑** 对每个广告位组合执行以下操作： ```python result = [] for (ad_id, pos), group in df.groupby(['广告id', '位置']): # 按创建时间降序排序 sorted_group = group.sort_values('创建时间', ascending=False) kept_records = [] for _, row in sorted_group.iterrows(): # 检查时段重叠 is_overlapping = any( (row['投放开始时间'] < kept['投放结束时间']) & (kept['投放开始时间'] < row['投放结束时间']) for kept in kept_records ) if not is_overlapping: kept_records.append(row) result.extend(kept_records) ``` 3. **结果输出** 最终生成DataFrame并按广告位组合整理： ```python result_df = pd.DataFrame(result)[ ['广告id', '位置', '投放开始时间', '投放结束时间', '创建时间'] ].sort_values(['广告id', '位置']) ``` ### 关键点解析 - **时间重叠判定**：两个时段$[s_1,e_1]$和$[s_2,e_2]$重叠的条件为$s_1 < e_2$且$s_2 < e_1$ - **处理顺序**：按创建时间倒序处理确保优先保留最新记录 - **时间复杂度优化**：采用线性扫描方式，每组时间复杂度为$O(n^2)$（适用于常规数据量） ### 示例验证 原始数据中广告`ad1 pos1`的处理过程： 1. 按创建时间排序后顺序： - `2024-12-31`创建的2025-01-03至2025-01-05时段（最新） - `2024-12-07`创建的2025-01-01至2025-01-06时段（与前者重叠被排除） - `2024-12-01`创建的2024-01-01至2024-01-10时段（无重叠保留） 最终输出符合"同一时段仅保留最新记录，不同时段共存"的业务需求。
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值