ICS文件是UTF-8纯文本，解析核心是逐行读取+状态机提取SUMMARY、DTSTART等字段，需处理转义与TZID时区，推荐date.h辅助时间解析而非依赖cpp-ical。
ICS文件本质是纯文本，别被格式吓住
ICS 文件（iCalendar 标准）不是二进制或加密数据，它就是带固定结构的 UTF-8 文本。开头是 BEGIN:VCALENDAR，结尾是 END:VCALENDAR，中间用 BEGIN:VEVENT/END:VEVENT 包裹每个事件。C++ 解析它的核心不是找库，而是按行读取 + 状态机拆解 —— 你不需要完整实现 RFC 5545，只要能提取 SUMMARY、DTSTART、DTEND、UID 这几个关键字段，90% 的日常需求就覆盖了。
用 std::getline 逐行解析，避开正则和 DOM 思维
别一上来就搜 “C++ ICS parser library”，更别试图用 std::regex 匹配跨行内容 —— ICS 允许换行续写（比如长 DESCRIPTION 后跟 开头的续行），正则极易漏匹配或崩溃。正确做法是：
- 用
std::ifstream打开文件，std::getline逐行读取 - 维护一个状态变量（如
enum { OUTSIDE, IN_VCALENDAR, IN_VEVENT }）跟踪当前在哪个块里 - 遇到
BEGIN:VEVENT切换状态，开始收集字段；遇到END:VEVENT触发一次事件构造 - 字段值可能含转义（
;→ 分号），需调用简单解码函数处理，例如：std::string unescape_ical(const std::string& s) { std::string out; for (size_t i = 0; i < s.length(); ++i) { if (s[i] == '\' && i+1 < s.length()) { switch(s[i+1]) { case 'n': out += ' '; i++; break; case ';': out += ';'; i++; break; case '\': out += '\'; i++; break; default: out += s[i]; break; } } else { out += s[i]; } } return out; }
DTSTART 和 DTEND 的时区处理最容易出错
ICS 中时间字段格式不统一：可能是 DTSTART:20240315T093000Z（UTC），也可能是 DTSTART;TZID=Asia/Shanghai:20240315T093000（本地时间）。C++ 标准库直到 C++20 才有较完善的时区支持（<chrono> + std::chrono::zoned_time），但多数项目仍用 C++17 或更早。实际建议：
- 优先识别
Z结尾 → 直接当作 UTC 时间解析（用std::get_time配合%Y%m%dT%H%M%SZ） - 遇到
TZID=，先提取时区名（如Asia/Shanghai），再决定是否依赖外部库（如 ICU 或 date.h）转换；若只做展示，可原样保留字符串 + 时区标识 - 绝对避免把
20240315T093000当作本地时间直接喂给std::localtime—— 它会按系统时区解释，而 ICS 文件本身不含系统时区上下文
开源库选型：cpp-ical 还是 date.h + 手动解析？
如果项目允许引入第三方，cpp-ical（已归档，最后更新 2017）稳定性差、不支持续行、对中文字段乱码常见；更推荐用 Howard Hinnant 的 date.h（单头文件，C++11 起支持）配合手动解析 —— 它专精时间解析，parse 函数能可靠处理 20240315T093000Z 和带时区偏移的格式（如 20240315T093000+0800）。但注意：date.h 不处理 ICS 结构，你仍得自己写状态机提取字段，它只帮你把时间字符串转成 sys_time 或 zoned_seconds。
立即学习“C++免费学习笔记（深入）”；
真正难的不是读取，而是字段语义歧义：同一个 RRULE 可能含 UNTIL 或 COUNT，EXDATE 可能跨多行，ATTENDEE 值含邮箱但可能被折行。这些边界情况，手工状态机比任何通用库都更容易针对性修复。
