DDRG15/Dirty-Receipt-Parser-PoC

Titanium-Vault: 脏数据票据解析器 PoC (V13.6) 架构师：Diego del Rio Garcia 🏛️ 项目概述 这不是一个“快乐路径（Happy Path）”解析器。它是一个高性能、抗崩溃的摄取引擎，专为处理“脏”OCR 数据而构建，能够在操作系统级进程被强制终止的绝对混乱中幸存。 开发者注：我花了 3 个小时怀疑自己是否神智正常，才意识到代码没问题——问题出在 Windows 内核上。事实证明，有时真的不是我的问题，而是你的问题，Windows。我本该使用 Linux，而且我绝对应该从一开始就使用 Docker。这是用血、汗和泪水换来的教训。 ⚔️ 解决的关键工程挑战 1. 双写悖论（“头痛”模式） 同时写入数据库和扁平文件在数学上就是一场自杀任务。如果系统在这两次写入之间崩溃，你的数据就废了。我起初没看出来，但一旦我意识到了，我就彻底修复了它。 解决方案：事务性发件箱模式（Transactional Outbox Pattern）。SQLite 数据库是唯一的“事实来源（Source of Truth）”。它首先在一个 ACID 事务中提交完整的 JSON 负载（Payload）。文件仅在保管库（Vault）密封后才会被原子性地导出。 2. Windows NTFS 加固（WinError 32 墓地） Windows 处理文件元数据的方式就像还停留在 1995 年。我搞定了 WinError 32（强制锁定），这样你就不用再折腾了。 VDL 保护：大多数开发者相信 file.flush()。他们错了。在 Windows 上，除非你强制推进有效数据长度（Valid Data Length, VDL）指针，否则 NTFS 会在硬崩溃时将你的文件截断为 0 字节。我使用 os.fsync() 创建了硬件级别的屏障。 内核锁定：实施了显式连接关闭和 WAL 截断，以阻止 Windows 内核“监视”文件并阻塞流水线（Pipeline）。 3. 背压与内存安全（OOM 预防） 在 8GB 内存上处理 50GB 文件不应该是个奇迹——这应该是一项基本要求。 解决方案：设定上限的 MAX_INFLIGHT 任务队列。当工作线程已满时，生产者停止读取。内存使用保持平稳，性能保持高涨。 🚦 快速开始 不要只听我的一面之词。运行混乱测试并试着破坏它。 初始化：python nuclear.py（大爆炸） 安装：pip install -r requirements.txt 验证：pytest tests/ -v（55 项测试的严酷考验） 混乱测试：python scripts/crash_restart_test.py（“硬杀死”证明）

标签：ACID 事务, ETL, FinTech, JavaCC, JSON 处理, NTFS 文件系统, OCR 数据清洗, Python, SQLite, Transactional Outbox 模式, WAL 模式, Windows 内核, 元数据提取, 内存管理, 分布式计算, 利马 (Lima), 反脆弱, 容错机制, 异常处理, 拉丁美洲 (Latam), 收据解析, 数据恢复, 数据持久化, 文件锁, 无后门, 日志硬化, 流式处理, 系统编程, 背压控制, 资源优化, 进程保护, 逆向工具, 零售科技