Yonagi's World

SFC：基于自定义 .sy 格式的文件归档工具

Wed, 29 Apr 2026 00:00:00 GMT

项目仓库： Gitee | GitHub

SFC（Simple Files Compressor）面向 Windows，输出格式为自定义 .sy。项目围绕归档协议、目录块写入、偏移量维护、路径编码转换和压缩加密组合展开。CLI 与 Qt GUI 共用核心层，界面层负责参数、进度和线程调度。

对象

工程对象分成协议层、目录层、数据层、界面层。协议层由 HeaderWriter、Locator、BinaryStandardLoader、EntryParser 组成，核心字段包括 strategy、version、directoryOffset、compressedSize。目录层由 EntryProcessor、LogicalRoot、Directory、File、Separated、SymbolLink 组成，负责目录树和目录块。数据层由 CompressionLoop、DecompressionLoop、DataLoader、DataExporter、StrategyFactory、ICompression、IEncryption 组成，覆盖 Huffman、AES 和数据块读写。界面层由 MainWindow、CompressionWorker、QThread 组成，负责输入路径、模式、密码、进度和停止控制。

.sy 协议对象固定为三段：19 字节文件头、目录块区域、数据块区域。目录块前置 Separated 标准，数据块按文件拆分，树数据和压缩数据各自带分块信息。路径对象统一经过 EncodingUtils::pathFromUtf8()、EncodingUtils::pathToUtf8() 和 path.u8string()。

职责

HeaderWriter 和 Locator 负责文件头写入、目录偏移回填、compressedSize 回填和块边界维护。BinaryStandardLoader 负责目录块读取、目录块解密和标准项装配，EntryParser 负责按 FlagType 解析目录项、文件项、逻辑根目录项和分割项。EntryProcessor 负责把输入路径转成目录树，再序列化进目录块。

CompressionLoop 负责压缩主循环，DecompressionLoop 负责解压主循环，DataLoader 负责原始数据读取，DataExporter 负责树数据、压缩数据和分块标准写出。StrategyFactory 按 CompressionMode 组装 HuffmanAES、HuffmanOnly、AESOnly、PackOnly。MainWindow 和 CompressionWorker 只负责任务调度、进度回调和线程停止，不处理协议细节。

流程

归档流程从输入路径列表进入 EntryProcessor。输入源先挂到 LogicalRoot，再按 BFS 顺序写成目录项和文件项。目录块按 16KB 分块，每块前写入 Separated 标准，块内记录 blockSize 和 AES-CFB 的 IV。目录块写完后，HeaderWriter 回填 directoryOffset，文件体写完后，Locator 回填 compressedSize。

解压流程从文件头开始。读取 strategy、version、directoryOffset 后，BinaryStandardLoader 逐块读取目录块，检查 IV，决定是否解密，再把二进制数据交给 EntryParser。EntryParser 按 Directory、File、LogicalRoot、Separated、SymbolLink 拆成 directoryQueueReady、entryQueue、fileQueue。DecompressionLoop 先创建目录，再按 fileQueue 进入数据区读取文件体。

数据流程按文件拆分。DataLoader 读取原始数据块，HuffmanCompression 生成频率表、Huffman 树和编码数据，DataExporter 写入树块、压缩块和有效位数。启用加密时，输出再进入 AesEncryption。树数据使用先序遍历序列化，叶子节点写 'l' 和字节值，内部节点写 'r'。AES 密钥由 SHA-256 派生，协议层使用 AES-128 CFB，目录块和数据块都按流式长度组织，不引入 PKCS#7 填充。

路径流程贯穿 GUI、核心层和文件系统。Qt 输入先转成 UTF-8，核心层用 std::string 表示 UTF-8 文本，进入文件系统前统一走 EncodingUtils::pathFromUtf8()，返回日志或界面前统一走 EncodingUtils::pathToUtf8()。目录遍历、文件名序列化、解压输出目录拼接都沿用同一条转换链。

.sy 文件头、目录块和数据块。格式识别依赖 magicNum_1、magicNum_2，模式识别依赖 strategy，目录读取依赖 directoryOffset，数据读取依赖 compressedSize 和 blockSize。目录块、数据块、IV、偏移量都写进归档内部，不依赖外部清单。

目录 EntryProcessor、BinaryStandardLoader、EntryParser。输入路径、逻辑根目录、BFS 队列、childCount 和目录恢复都停在这一层。压缩：CompressionLoop、DecompressionLoop、ICompression、IEncryption，算法替换不改协议主流程。编码问题用： EncodingUtils，并且Qt、std::string、std::filesystem::path 不应当脱离转换混用。GUI 部分有 MainWindow 和 CompressionWorker，界面层不接触目录块、文件头和数据区。

限制

当前版本以 Windows 为主，路径处理和文件系统行为按 Windows 规则组织。主流程仍是单线程顺序处理，ThreadPool 和 Scheduler 还停在接口和实验代码层。压缩算法当前只有 Huffman，AES 还是纯软件实现，长路径分支没有进入发布版本。

开发日志（一）：AES 原型、模块划分与 .sy 格式雏形

My ARPG：场景切换、对话、任务和 UI 管理的 Unity 2D ARPG 原型

Wed, 29 Apr 2026 00:00:00 GMT

项目仓库： Gitee | GitHub 在线试玩：ARPG WebGL Demo

My ARPG 基于 Unity 2022.3.62f3c1。原型围绕场景切换、状态恢复、条件对话、任务推进、商店交互和 UI 管理展开。资源加载使用 Addressables，输入使用 Input System，模块通信使用 ScriptableObject 事件。

对象

工程对象分成场景层、状态层、导航层和交互层。场景层由 InitialLoad、SceneChanger、SceneLoadEventSO、GameSceneSO 组成，负责持久场景和地图切换。状态层由 DataManager、ISaveable、DataDefinition、Data 组成，用于对象注册、数据分发和持久化标识。导航层由 AStarPathFinder、AStarNodeManager、PathFinderDetails 组成，底层结构使用 Dictionary<Vector3, PathFinderDetails> 和 HashSet<Vector3>。交互层覆盖 NPCStateController、NPCWander、NPCPatrol、NPCChat、ShopKeeper、DialogSO、DialogLine、DialogOption、QuestSO、QuestObjective、Reward、QuestProgressData、ShopManager、UIManager。

职责

SceneChanger 负责场景卸载、场景加载、玩家坐标切换和输入恢复，DataManager 负责 Save()、Load() 和 ISaveable 注册表，AStarPathFinder 负责 FindPath()、WorldToCell()、CellToWorld()、GetNodeMap()，AStarNodeManager 负责导航节点生成。

交互层的职责按模块拆开。NPCStateController 维护 Idle、Wander、Patrol、Chat 状态流，NPCChat 把交互请求交给 DialogManager，ShopKeeper 把商店请求交给 ShopManager。DialogManager 负责 MatchConditionsToStartDialog()、分支选择和 DialogSO.HasChated，QuestManager 用 Dictionary<QuestSO, QuestProgressData> 和 Dictionary<QuestObjective, int> 维护任务状态，UIManager 负责 ToggleCanvasEventSO、ResetCanvas() 和面板互斥。

流程

场景流程从 SceneLoadEventSO 进入 SceneChanger.OnEnable()，再走 LoadSceneMode.Additive 和 OnLoadCompleted()。传送门、菜单、碰撞脚本只发切换请求，坐标写入 newPosition，缺失时回退到 GameSceneSO.initialPosition。

存档流程从 VoidEventSO 进入 DataManager.Save() 和 DataManager.Load()。DataManager 带 [DefaultExecutionOrder(-100)]，先建立 List<ISaveable>，再把 Data 分发给对象。对象侧通过 SaveData(Data data) 和 LoadData(Data data) 读写字段，DataDefinition.ID 用于对象定位，Data.lootsStatsDic 用于战利品状态恢复。

寻路流程从 FindPath() 开始，经过 SearchCheapestCost()、AddNodeToOpen()、CanWalkDiagonally() 完成搜索。optPos 用于前移起点，NoCoverObstacleNodes() 用于检查直线路径，对角移动受相邻阻挡检测约束。

对话流程从 NPCChat 进入 DialogManager，再进入 MatchConditionsToStartDialog()、DialogSO 和 DialogOption。角色条件依赖 ConversationHistoryManager 的 HashSet<CharacterSO>，物品条件依赖 ItemHistoryManager 的 Dictionary<ItemSO, int>，一次性条件依赖 DialogSO.HasChated。任务流程由 QuestManager.UpdateObjectiveProgress() 直接读取历史数据，奖励流程由 RaiseRewardEvent() 写入 InventorySlotsStatsSO。商店流程从 ShopLoadEventSO 进入 ShopManager.OnShopLoad() 和 PopulateShopItems()，购买与出售都经过 InventoryUpdateRequest.RaiseInventoryUpdateRequest()。UI 流程由输入检测、ToggleCanvasEventSO 和 CanvasGroup 组成，切场景时执行 ResetCanvas()。

边界

场景切换 SceneChanger，外层对象只保留请求入口。运行时的状态保存： DataManager 和 ISaveable，对象侧只处理序列化字段。寻路系统： AStarPathFinder 和 AStarNodeManager，NPC、敌人、交互物共享导航数据，不持有网格生成逻辑。

交互边界按系统拆开。NPC 本体不持有对话 UI、商店 UI、任务 UI。DialogManager 依赖历史数据，不依赖移动逻辑。QuestManager 依赖历史系统，不维护对话状态。UIManager 只处理面板开关，不处理任务、商店、对话数据。

限制

当前版本覆盖场景切换、对象状态恢复、条件对话、任务统计、商店和面板互斥。完整落盘存档、敌人状态持久化、地图交互对象、背包规则和任务内容仍在补全。

配套开发日志：My ARPG 开发日志

SFC 开发日志（二）：压缩 / 解压、目录恢复与首个 CLI 版本

Wed, 29 Apr 2026 00:00:00 GMT

项目仓库： Gitee | GitHub

依赖部分文件头的实现、目录块和偏移量逻辑实现。开始编写数据区的写入、目录恢复、解压读取和命令行版本，并且构建发布版。

上一篇：SFC 开发日志（一）

2025 年 12 月 1 日到 2025 年 12 月 2 日：数据块表示

压缩模块、加密模块、读取器DataLoader和导出器DataExporter统一使用 DataBlock = std::vector<uint8_t>。压缩模块与文件流解耦。协议层、算法层和导出层通过同一类型传递数据。

整理Y_flib 命名空间的初始版。HeaderLoader 分块读取采用迭代器混合状态机模式处理生产消费耦合。目录、树数据、压缩数据。模块只接收字节数据，不关心上游来自文件、目录项还是算法中间产物。

2025 年 12 月 3 日到 2025 年 12 月 6 日：HeaderWriter 扩展与压缩侧联通

HeaderWriter v0.1.5 继续扩展。目录协议增加符号链接标准，格式为链接名长度、目标路径长度、链接名和目标路径。（目前随跨平台方案难产废弃）目录块和数据块都引入 IV 字段。Separated 标准的职责从块边界标记扩展为“块大小 + IV + 分块标识”。

| 标志 '4' | 链接名长度(4B) | 目标路径长度(4B) | 链接名 | 目标路径 |

IV 协议统一放在块分割协议开头。目录块、树数据、压缩数据都通过分割标准记录 IV。读取侧先读标准，再按 IV 决定是否解密（早期按浮点精度随机数生成器随机不到0判断，后期已经改为依照策略头判断整体是不是经过AES加密）。此时写入器负责输出目录结构、回读解压侧所需块信息。

输出文件流程：写文件头、写目录块、读刚刚写的目录块、按块处理、目录块加密（此时是耦合的）、写进处理后块、回填大小。HeaderWriter、EntryProcessor、DataExporter 与压缩模块围绕同一个输出文件（协议化目录）工作。

2025 年 12 月 8 日到 2025 年 12 月 9 日：AES 模块补齐

AES 从独立算法代码转成归档流程模块。密钥派生仍然使用 SHA-256 的前 16 字节，密钥扩展生成 44 个轮密钥字，主体保持标准 10 轮 AES-128。添加乘法表 GF_MUL_2、GF_MUL_3、GF_MUL_9、GF_MUL_11、GF_MUL_13、GF_MUL_14 ，利用缓存命中减少运行时 GF(2^8) 乘法计算耗时，实测目前软件AES方案增快80%以上。

2025 年 12 月 10 日到 2025 年 12 月 12 日：BFS 目录遍历与逻辑根目录

EntryProcessor BFS 目录遍历方案。输入文件和输入目录先挂到逻辑根目录下，再由队列按层序遍历。目录项进入 entryQueue，子目录继续入队，文件项写入文件标准。目录块每写满 16KB，就插入一条分割标准，把当前块大小和 IV 写入协议。

void EntryProcessor::flowScanner(...)
{
    // 1. 写入逻辑根节点
    // 2. 处理用户指定的文件/目录列表
    // 3. 循环从队列取出目录，处理其内容
    // 4. 遇到子目录时加入队列继续遍历
}

BFS 目录遍历直接服务目录恢复。解压器不需要外部目录描述文件，只按目录标准和 childCount 推进队列，就能还原父目录、子目录和同层兄弟项的关系。协议为处理多个文件、文件夹逻辑根目录（本质森林合成一颗树）。利用逻辑根目录提供一个根节点（无序）。

2025 年 12 月 13 日到 2025 年 12 月 17 日：解压流程

解压流程主体是 BinaryStandardLoader。类内部维护 fileQueue、entryQueue、directoryQueueReady、blockPosition，分别负责待解压文件项、目录项上下文、目录恢复顺序和目录块回写位置。读取器先打开归档文件，验证魔数，读取文件头，定位到 directoryOffset，逐块读取目录块，再把数据交给 EntryParser解析。

读取 .sy 文件
    -> 验证魔数
    -> 跳转到目录块偏移
    -> 按需解密目录块
    -> 解析文件队列和目录队列
    -> 创建目录结构
    -> 逐块读取数据区
        -> 解密 Huffman 树
        -> 重建 Huffman 树
        -> 解密压缩数据
        -> Huffman 解码
        -> 写回原文件

EntryParser 解析目录标准和文件标准后，把文件条目压入 fileQueue，把目录路径压入 directoryQueueReady。DecompressionLoop 先创建目录，再根据文件条目进入数据区。文件条目中的第二字段在压缩场景承担偏移量语义，在解压场景承担 compressedSize 语义。

2025 年 12 月 18 日到 2025 年 12 月 25 日：工程整理与 CLI 交互

工程整理与主流程开发。huffman的std::map 替换为 std::unordered_map，整理优化CLI相关代码（GUI版本已删除的main.cpp）。

采用了耦合设计：目录块、树数据、压缩数据、加密过程全部写进压缩 / 解压主循环。

2025 年 12 月 30 日到 2025 年 12 月 31 日：Huffman 单字符边界问题

单字符输入的协议边界：数据块全部由同一个字节组成时，Huffman 树只有一个叶子节点，常规的构造方式失效。树生成失败后，编码和回读都会随之失效。

处理方式是给单字符场景固定一位编码。树节点数量为 1 时，编码直接写成 {0}，长度记为 1。压缩侧仍能生成树数据和编码数据，解压侧也按同一规则恢复。单字符文件和单字符数据块纳入标准压缩 / 解压流程。

if (countLeaves(treeroot) == 1) {
    hashtab[onlyChar].code = {0};
    hashtab[onlyChar].codelen = 1;
}

2026 年 1 月 1 日到 2026 年 1 月 6 日：首个 CLI 预览版本

v1.0.0 Preview 首个release。实现了CLI版本的加密压缩与解压全流程。修复数据区解码和单字符边界问题。

预览版仍有稳定性修正项：目录偏移量类型统一为 uint64_t，目录缓冲区大小固定为 16KB，部分 constexpr const 历史写法被清理，项目说明与 README 同步补全。归档体积超过 4GB 时，32 位偏移量没有可用空间，因此偏移量类型固定为 uint64_t。

结果

主逻辑完成，引入目录遍历与逻辑根目录，BinaryStandardLoader 和 EntryParser 把目录恢复纳入主流程，Huffman 单字符边界bug修复，发布CLI 形式的压缩与解压工具。

下一篇：SFC 开发日志（三）：CLI 稳定化、Qt GUI 与发布

SFC 开发日志（三）：CLI 稳定化、Qt GUI 与发布

Wed, 29 Apr 2026 00:00:00 GMT

项目仓库： Gitee | GitHub

处理目录块边界、GUI 、UTF-8 路径、策略模式、单文件发布等问题。

上一篇：SFC 开发日志（二）

2026 年 3 月 2 日到 2026 年 3 月 15 日：CLI 稳定化

CLI debug、refactor。FlagType 改成强类型枚举，目录接口、工具类接口、文件已存在时的处理方式、目录队列逻辑同步整理。目录标准、文件标准、分割标准共享同一组枚举和偏移量规则，目录恢复与数据区读取都按统一类型解释。

enum class FlagType : char
{
    Directory = '0',
    File = '1',
    Separated = '2',
    LogicalRoot = '3',
    SymbolLink = '4'
};

目录块边界写入问题。目录条目恰好落在分块边界时，流程没有正常进行，产生空分块或目录解析错位，具体问题在于请求的流程逻辑的遗漏。

关于长路径问题。尝试在PathTransfer::transPath() 给绝对路径加上 \\?\ 前缀，用于解决 Windows 路径长度限制。由于操作系统实际上还是禁止了长路径的出现，项目只能使用 Windows 路径处理和 UTF-8 中文路径。

2026 年 4 月 1 日：构建系统调整

构建系统改为 MSVC + CMake。关闭CMAKE_INTERPROCEDURAL_OPTIMIZATION 。

仅仅是为了使用VS的性能分析报告

2026 年 4 月 12 日到 2026 年 4 月 15 日：文档整理与 GUI 工程建立

代码清理与 GUI 开发。开始编写 Qt Widgets 。编写CMake 配置和后台任务执行框架。

GUI 的设计隔离： Y_Manager 和 CompressorFileSystem负责主逻辑。GUI 负责参数录入、结果展示和线程调度。

修复directoryOffset 的写入时机问题。

2026 年 4 月 16 日：Qt GUI 主体

GUI 主体围绕 MainWindow、CompressionWorker、QThread 组织。MainWindow 收集源路径、输出目录、模式和密码。CompressionWorker 在后台线程调用 MainLoop、CompressionLoop、DecompressionLoop。进度通过信号送回 UI 线程。界面层不直接访问目录块、数据区和压缩模块。

MainWindow (UI线程)
    -> QThread
        -> CompressionWorker
            -> CompressionLoop / DecompressionLoop
    <- detailedProgress / finished

GUI 接入后，进度信号频率需要限流。后台线程若每处理一小段数据就发出信号，UI 线程会堆积刷新请求。处理方式分成两层：MainLoop 控制核心层回调频率，CompressionWorker 按时间和百分比变化量再做一层节流。双层节流下，进度显示保持连续。

窗口关闭期间的线程退出。后台线程执行中直接关闭窗口，文件句柄、缓冲区和输出状态容易残留。GUI 因此加入 std::atomic<bool> m_stopRequested。主线程发出停止请求，后台线程在进度回调和循环中检查标记，析构阶段等待线程退出。停止逻辑只处理线程与资源，不改协议结构。

文件句柄和缓冲区释放。BinaryStandardLoader::setAllLoopDone()、DecompressionLoop::createFile()、std::vector 缓冲复用、Heffman::merge_ttabs() 的容量释放都进入正式代码。长任务运行期间，已经处理完的缓冲区会及时释放。解压阶段输出文件句柄也会在写入结束后关闭。

中文路径与编码处理

GUI 接入后的路径编码差异。Qt 层传入 UTF-8 字符串，std::filesystem 在 Windows 下返回的路径文本可能关联本地代码页。路径拼接、文件名恢复和日志显示都依赖统一转换规则，中文输出目录尤其敏感。

修正规则集中在 EncodingUtils。Qt 边界处统一使用 UTF-8 作为文本协议，QString 进入核心层前先转 UTF-8，进入文件系统前再用 pathFromUtf8()，从 std::filesystem::path 回到日志或 GUI 时再用 pathToUtf8()。目录遍历和文件名序列化统一使用 entry.path().filename().u8string()。toStdString()。关于输出目录乱码：UTF-8 文本先转路径对象，再交给 DecompressionLoop。

统一规则覆盖中文路径、中文输出目录、日志显示和 GUI 展示。 EncodingUtils ，QString、std::string、std::filesystem::path 统一处理三个文本体系的路径逻辑。

Qt 工具链与系统兼容性

GUI 发布的依赖为 Qt 6.2.4 LTS。MSYS2 MinGW 15.x 构建版本在运行时出现过 nanosleep64 缺失，Qt 6.10.1 的部分 API 在旧版 Windows 10 环境下也不稳定。Qt 6.2.4 LTS 用于统一图形界面、路径转换、线程模型和静态发布环境。

GUI 兼容 Windows 10 1809 及以上版本。

2026 年 4 月 17 日：多策略支持与发布形态调整

主流程原本把 Huffman + AES 写死在内部。重构后，CompressionMode 枚举、StrategyFactory、ICompression、IEncryption、NullCompression、NullEncryption 一并接入，压缩和加密组合改由运行时装配。

enum class CompressionMode : uint8_t
{
    HuffmanAES  = 0,
    HuffmanOnly = 1,
    AESOnly     = 2,
    PackOnly    = 3
};

CompressionLoop、DecompressionLoop 和 BinaryStandardLoader 由依赖具体类改为依赖接口。HeaderWriter 负责把策略号写入文件头，解压侧通过 Header.strategy 还原模式。策略号 0 继续映射 HuffmanAES，旧归档文件保持兼容。

发布形态同步调整。动态部署包体约 57MB，Qt DLL、渲染依赖和资源文件分散在目录中。静态发布改用 Qt 6.2.4 静态库，构建开关通过 USE_STATIC_QT 控制，翻译文件和图片资源内嵌进可执行文件，背景图从 PNG 改成 JPEG。默认发布体积约 16MB，发布目录不携带额外依赖。

2026 年 4 月 18 日到 2026 年 4 月 19 日：编码整理、翻译与工程清理

编码规则固定为：GUI 输入统一转 UTF-8，核心层字符串按 UTF-8 组织，真正接触文件系统时再转成 std::filesystem::path。规则覆盖 GUI 压缩输入、解压输出目录、目录遍历结果和日志文本。编码转换职责全部归入 EncodingUtils。

GUI 多语言规则固定为：界面文案统一使用 tr() 包装，翻译资源通过 resources.qrc 内嵌，语言选择优先读取 SFC_GUI_LANGUAGE，没有显式指定时再读取 QLocale::system()。单 exe 发布下，翻译资源不依赖外部目录。日志和技术状态文本保持英文，控件文本按语言环境切换。

工程整理还包括头文件、命名空间、本地构建目录 .gitignore 和临时验证目录清理。目录块规则、编码规则、GUI 工具链和策略模式稳定后，代码布局与功能布局对齐。

结果

从CLI 到桌面程序（GUI）。处理的问题：目录块写入顺序、目录恢复队列、输出目录编码、目录偏移量回填和目录块加密、GUI、多策略和单文件发布。

返回项目介绍：SFC

SFC 开发日志（一）：AES 原型、模块划分与 .sy 格式雏形

Wed, 29 Apr 2026 00:00:00 GMT

项目仓库： Gitee | GitHub

开发 AES-128 原型、目录读取、文件头写入、偏移量定位和 Huffman 树序列化。 .sy协议：文件系统信息写进二进制文件，读取器按同一规则读回。涉及的主要模块有：文件头、目录块、数据区、定位工具和读取器。

2025 年 9 月 29 日到 2025 年 10 月 5 日：AES 原型与密钥入口

开发 Aes.cpp 和 Aes.h。首先实现主逻辑，接着补齐密钥对齐。密码入口采用 SHA-256 派生，再截取前 16 字节作为 AES-128 密钥。AES 模块内部只处理 128 位密钥。

void SubBytes(state_t &state);
void ShiftRows(state_t &state);
void MixColumns(state_t &state);
void AddRoundKey(state_t &state);

AES 初版使用 ECB。由于系统尚未引入目录块、数据块、偏移量、IV 和文件头，目前仅做实验性实现

2025 年 10 月 11 日到 2025 年 10 月 18 日：结构设计与并发架构的设计（虽然最后并未使用）

代码从单文件算法实验转向模块化结构。目录内出现 Scheduler、ThreadPool、TaskQueue、DataInteraction 等名称，职责划分也随之明确：调度层负责组织流程，压缩与加密模块只处理字节流，数据交互层负责把文件系统内容转成模块输入。

线程池和任务队列先以接口形式落位。主流程没有并入并发执行，但 TaskMonitor、条件变量、队列和销毁逻辑已经编写完成。主流程保持单线程时使用同一份数据交换结构，并发分支接入时也不需要重写。

模块化设计把压缩与加密拆开。目录树读取器、文件头写入器、数据块读取器被划入协议层。协议层与算法层分离后，Huffman、AES、GUI 共享同一份文件系统结构。

2025 年 10 月 21 日到 2025 年 10 月 30 日：工具类与偏移量

CompressionModules/heffman 负责 Huffman，EncryptionModules/aes 负责 AES，CompressorFileSystem/DataCommunication 负责目录树、文件头、偏移量、路径和数据块读写。

需要注意的是，并发代码承担的是模块交接任务。TaskMonitor 使用 vector、condition_variable 和 mutex 管理多条队列。工程结构已经脱离单文件测试程序的写法。

Locator ，关键工具。用于归档文件写入文件头后偏移量字段回填。负责在文件头、目录块、数据区之间定位，封装并且统一所有 seekg 和 seekp的调用。directoryOffset、compressedSize、目录块大小和文件头定位从此纳入同一套偏移量规则。

协议中出现需要回填的字段，不同区域通过偏移量互相引用。

2025 年 11 月 1 日到 2025 年 11 月 13 日：HeaderReader、filesystem 与目录信息读取

读取器 Reader、ReaderUpdate、Reader_filesystem、HeaderReader 的重构。主要处理文件系统路径接入、目录项结构化读取、位流与普通文件流统一、Windows 路径编码处理。读取器形态由普通文件流读取转向“按目录项解释字节流”。

抛弃posix（我不会），使用标准库的filesystem。MyQueue、辅助结构、目录队列、文件队列成形，构建目录块解析方案。

Windows 路径问题。宽字符路径做过试验，最终规则尚未固定，但编码已经进入协议设计范围。

读取器重构后，目录信息进入内存结构，由读取器和队列维护。

2025 年 11 月 17 日到 2025 年 11 月 30 日：HeaderWriter、Huffman 序列化与 Header 雏形

开始写入端的编写。HeaderLoader、FileLibrary、DirectoryReader、HeaderWriter 。读取和写入形成对应关系：目录信息如何落盘，解压侧就按同样规则读回。文件头预留哪些字段，数据区写入时就按同样位置回填。

Huffman 编码树保存方式固定。树序列化采用先序遍历，叶子节点写 'l' 和字节值，内部节点写 'r'。解压侧根据树数据重建 Huffman 树，不重新扫描整文件统计频率。树的序列化方式固定后，压缩侧与解压侧共享同一份树结构，数据块也具备独立编码和独立恢复条件。

文件头Header结构同步定形。包含魔数、策略号、版本号、保留位、目录偏移量、尾部魔数。

文件头里预留八位strategy。为多策略模式保留扩展位。

2025 年 11 月 29 日到 2025 年 11 月 30 日：AES 从 ECB 转向 CFB

目录块和数据块纳入协议后，AES 模式需要随协议组织方式调整。归档文件按给定大小数据块写入，不做16B块对齐。目录信息和数据信息都依赖块分割协议。AES加密模式从CBC改成 CFB。原因是CFB 不改变数据长度，更加能准确还原信息，也便于在分割标准中记录 IV。

结果

AES 原型脱离单文件实验。目录结构、读取器、写入器、定位工具和偏移量规则纳入同一套代码。Huffman 树序列化方式固定，文件头字段和协议边界确定。CLI、目录恢复、数据区写入、GUI 都建立在这组协议代码上。

下一篇：SFC 开发日志（二）：压缩 / 解压、目录恢复与首个 CLI 版本

My ARPG 开发日志：场景切换、A*、对话与任务系统

Wed, 29 Apr 2026 00:00:00 GMT

项目仓库： Gitee | GitHub

开发记录覆盖场景切换、状态恢复、A*、NPC 状态、条件对话、任务、商店和 UI 路由。代码组织围绕事件、ScriptableObject 数据和多场景结构展开。每个模块单独建类，数据依赖和调用顺序落在同一条主链上。

2026 年 3 月 18 日到 2026 年 3 月 20 日：项目初始化与基础结构

工程已有玩家状态机、击退处理、商店入口和部分目录结构。初始化部分先整理脚本目录、命名和公共依赖。单位脚本、对话脚本、场景脚本、UI 脚本、ScriptableObject 资源分别归档。预制件、动画和 SO 资源同步分组。任务、对话、商店和多场景切换共享统一目录结构与 Inspector 绑定规则。

目录结构固定后，脚本职责随目录边界拆开。单位逻辑与 UI 逻辑不放在同一目录，对话系统与场景系统各自持有独立入口。多系统协作依赖稳定命名、稳定资源路径和稳定事件引用。

2026 年 3 月 21 日到 2026 年 3 月 24 日：场景切换与状态保存打底

场景切换和状态恢复由 InitialLoad、SceneChanger、DataManager、ISaveable 四层承担。入口场景通过 Addressables.LoadSceneAsync(persistentScene) 加载持久场景，后续加载事件由 SceneLoadEventSO 广播给 SceneChanger。SceneChanger 收到请求后禁用 PlayerMovement、重置血量、暂停时间、记录目标场景和目标位置，再按淡入标记控制过渡动画。

SceneChanger 的核心流程是：卸载当前场景，以 LoadSceneMode.Additive 异步加载目标场景，设置玩家坐标，在 OnLoadCompleted() 中恢复输入和时间。输入禁用、血量重置、暂停和位置切换都集中在同一个类内，传送门、菜单和碰撞脚本只负责发起请求。

状态恢复层由 DataManager 和 ISaveable 组成。DataManager 带有 [DefaultExecutionOrder(-100)]，初始化顺序早于普通脚本，内部维护 List<ISaveable>。保存事件触发时，Save() 遍历注册对象，把 Data 实例交给各对象写入。读取事件触发时，Load() 再把同一份 Data 发回各对象。对象侧实现 GetDataID()、SaveData()、LoadData() 即可。

战利品状态接入保存流程。Data.lootsStatsDic 记录战利品位置和拾取状态，用于重载场景时恢复交互物状态。GUID 与对象状态进入同一张数据表。

2026 年 3 月 25 日到 2026 年 3 月 31 日：A* 寻路

AStarPathFinder 完成主要结构。路径搜索接口是 FindPath(Vector3 optPos, Vector3 startPos, Vector3 endPos)，内部先把世界坐标转成网格坐标，再用 Dictionary<Vector3, PathFinderDetails> 维护开启列表，用 HashSet<Vector3> 维护关闭列表。SearchCheapestCost() 负责取总代价最低节点，RetracePath() 负责从终点回溯父节点并生成路径栈。

optPos 是一层前置优化。optPos 不为零时，程序先检查该点对应网格是否可通过，再用 NoCoverObstacleNodes() 判断起点到 optPos 的直线段是否存在障碍。直线路径可用时，搜索起点前移到 optPos，开启列表规模随之缩小。

八方向移动与对角穿墙检测是寻路层的另一条规则。AddNodeToOpen() 在展开邻居时调用 CanWalkDiagonally()。斜向移动时，如果横向和纵向相邻格子都被障碍占用，路径搜索禁止沿对角线穿过。路径结果因此与碰撞结果保持一致。

导航数据由 AStarNodeManager 从 Tilemap 和 Collider2D 生成。地图切换后，沿用相同图层与碰撞规则即可刷新网格数据。NPC、敌人和交互对象共享这层导航数据。

2026 年 4 月 1 日到 2026 年 4 月 6 日：NPC、动画与对话入口

NPC 行为按状态拆开。NPCStateController 管理 Idle、Wander、Patrol、Chat，NPCWander 与 NPCPatrol 处理移动，NPCChat 处理交互入口和对话触发。状态切换通过启用或禁用脚本完成。角色接近 NPC 并触发交互时，移动脚本停下，对话入口接管当前状态。

动画与交互时机跟随同一条状态链移动。NPCChat 负责拉起 DialogManager，NPCStateController 负责停掉游荡或巡逻脚本。移动、动画、交互、面板打开分别由不同脚本承担。

店主和普通 NPC 沿用同样的拆分方式。店主脚本只负责商店入口，商品内容和商店 UI 交给 ShopManager。普通 NPC 只负责对话入口，对话条件与历史回写交给 DialogManager 和历史管理器。

2026 年 4 月 7 日到 2026 年 4 月 10 日：菜单、暂停与 Retry 逻辑

ESC 菜单、暂停和 Retry 共用输入、动画、场景和玩家状态。时序问题集中在暂停状态、死亡重载、淡入淡出和输入恢复几个位置。由UI 管理层统一控制，不让单个按钮各自维护一套条件。

UI 射线阻挡、面板状态残留、按钮事件和场景状态不同步。问题在 UI 管理层。商店、任务、对话、属性和 ESC 面板共用一套开关路由，状态切换由统一管理器分发。

2026 年 4 月 13 日到 2026 年 4 月 19 日：条件对话与对话历史

DialogSO、DialogManager、ConversationHistoryManager、ItemHistoryManager 组成一套结构。DialogSO 保存主说话角色、对话文本数组、选项分支、角色前置条件、物品前置条件、拒绝对话节点和一次性触发限制。对话节点从“文本 + 下一句”扩展成带条件、带分支、带历史回写的数据对象。

DialogManager.StartDialog() 先执行 MatchConditionsToStartDialog()。角色条件通过 ConversationHistoryManager.CharactersHasChated 检查，物品条件通过 ItemHistoryManager.HasPickedOverAmount() 检查，一次性对话通过 DialogSO.HasChated 检查。条件不满足时，StartRefuseDialog() 按 ChatType 切到拒绝分支，界面继续显示对应内容。

对话结束时，EndDialog() 把 mainCharacter 写进 ConversationHistoryManager。ConversationHistoryManager 用 HashSet<CharacterSO> 记录已触发角色，ItemHistoryManager 用 Dictionary<ItemSO, int> 记录物品累计数量。历史系统服务条件判断。任务节点、分支对话和拒绝对话都从历史系统读取结果。

选项按钮纳入 DialogManager。ShowChoices() 遍历 nextDialogOptions，把选项文本写进按钮，再通过 onClick 注册进入下一节点。主分支、拒绝分支、一次性对话和普通默认对话共用同一套结构。

2026 年 4 月 20 日到 2026 年 4 月 24 日：任务系统成型

任务系统主体是 QuestManager。类内部维护 Dictionary<QuestSO, QuestProgressData>，每个任务对应一个状态和一张目标进度表。QuestProgressData 使用 Dictionary<QuestObjective, int> 保存目标当前值。任务板打开时，OnReFreshQuestState() 先初始化进度表，再刷新 QuestLogSlot。任务板为空时，详情页与提示页切到空任务状态。

任务状态流转由 QuestStateChanged() 控制。状态变化时，接取、放弃、完成按钮区域同步切换，QuestLogUI 刷新目标文本。任务完成时，RaiseRewardEvent() 遍历奖励列表，把奖励写进 InventorySlotsStatsSO。奖励发放由事件进入库存更新流程，不直接改背包槽位。

任务进度统计直接依赖历史系统。UpdateObjectiveProgress() 在目标是物品时读取 ItemHistoryManager 的累计数量，在目标是角色时读取 ConversationHistoryManager 的对话记录。任务脚本不需要维护 NPC 交互细节。任务目标和对话历史、拾取记录共享同一套底层数据。

QuestObjective 同时包含目标物品、目标角色和目标地点字段。地点统计接口已经留在数据结构中，地图触发点逻辑预留在该字段上。

2026 年 4 月 26 日到 2026 年 4 月 29 日：奖励、商店、UIManager 与 Addressables

奖励发放、商店、UI 路由和 Addressables 场景加载整理成同一条调用链。QuestManager.RaiseRewardEvent() 把奖励发给库存系统，ShopManager 接收商品列表并打开商店面板，UIManager 负责面板互斥，场景链路由 SceneChanger 和 Addressables 维持。

ShopManager 内部维护一般物品、武器、防具三张列表。OnShopLoad() 接到 ShopLoadEventSO 后，把列表保存到管理器，再打开商店 CanvasGroup。购买调用 RaiseInventoryUpdateRequest(item, price, 1)。出售沿用同一接口，只把价格和数量改成负值。买卖逻辑共用同一条库存更新链路。

UIManager 在 Update() 中读取 ESC、技能、属性、任务、对话、商店等输入，判断当前是否已有面板打开，再通过一组 ToggleCanvasEventSO 广播目标状态。管理器不直接硬编码每个面板的开关。面板开关和互斥关系都经事件系统分发。场景切换事件进入时，ResetCanvas() 把托管面板全部关掉，清空跨场景残留。

Addressables 场景链路固定为统一顺序。场景加载、场景卸载、淡入淡出、玩家状态恢复按同一顺序执行，普通加载接口不混入该路径。场景调试路径和构建路径保持一致。

结果

场景切换、状态恢复、A*、NPC 行为、条件对话、任务进度、奖励发放、商店和 UI 管理纳入同一条主链。系统边界如下：场景切换用事件和 Addressables，状态恢复用 DataManager，路径搜索用 A*，对话和任务读取历史系统，面板互斥由 UIManager 统一处理。

项目介绍：My ARPG