eSIM-Tools

把物理卡“搬”进 eUICC：Silentely/eSIM-Tools 技术拆解

项目背景与痛点

eSIM 的普及速度远远落后于手机硬件的支持速度。几乎所有近三年的旗舰机都内置了 eUICC，但真正愿意把「换卡」按钮开放给用户的运营商仍是少数。Giffgaff、Simyo 这类 MVNO 更微妙：它们背靠 O2、Telefónica 的大网，成本结构决定了它们必须把客服和物流压到最低，因此 eSIM 自助换卡的功能往往被隐藏在一个深达三层的用户中心页面之后，并且没有任何文档告诉你完整的操作链路。

对普通用户来说，痛点集中在三处：其一，Giffgaff 的 eSIM 申请在老账户、携号转入账户上的入口不一致，走错流程会直接触发 SIM Swap 风控；其二，Simyo 的换卡页面会强制要求填写德文的地址确认字段，稍有不符就静默失败；其三，拿到的一串 LPA:1$smdp.xxx$MATCHING-ID 激活码，需要自己生成标准 QR 码才能被系统相机识别，而多数在线二维码工具会把 $ 和大小写搞坏。

eSIM-Tools 的价值不在于“发明”了什么协议，而在于把运营商那一套半公开的换卡流程抽象成一个可复用、可校验的工具链，把“能不能换”的不确定性收敛成一条可预期的路径。

核心技术揭秘

从项目定位反推，它并没有实现 eUICC 侧的 ES10 接口或 SGP.22 的完整 RSP 栈；它实现的是运营商 OSS/BSS 层面的流程编排 + 激活码的规范化输出。因此它的架构重心在“适配器”与“状态机”两处。

适配器层用于隔离 Giffgaff 与 Simyo 的差异：登录方式（邮箱 + 短信 OTP vs. 号码 + PIN）、表单字段、换卡提交接口、状态查询节奏都不同，但对外暴露统一语义——“发起换卡、等待 profile 就绪、取回激活码”。这是典型的 Strategy + Adapter 组合，新增一家运营商只需再写一个 driver，上层二维码渲染与结果校验完全不动。

状态机层则负责处理运营商异步返回。SIM 换卡不是同步事务：提交请求后，后台会在数秒到数分钟内完成 profile 的签发与绑定，此时轮询状态接口或用回调感知，是唯一可靠的收敛方式。项目必须处理“提交成功但 profile 未就绪”“profile 已删除但新卡未激活”等中间态，否则用户会拿到一个指向已失效 matching ID 的死码。

数据流的关键节点在 I 与 J 之间：激活码 LPA:1$<SM-DP+ FQDN>$<Matching ID> 是一个对字符极其敏感的字符串，$ 是分隔符不能转义，Matching ID 大小写敏感。任何一次多余的 URL 编码或换行插入，都会让 LPA 在解析阶段直接报错。这也是很多“自己拿在线工具做二维码”失败率高的真实原因。

功能亮点与差异

与市面上几类竞品相比，它的差异很明确。第一类是运营商官方流程，功能正确但入口分散、无状态反馈，用户提交后只能干等邮件；eSIM-Tools 把等待过程可视化，明确告知当前卡在哪个阶段。第二类是通用的二维码生成器，它们只做字符到图形的转换，不理解语义，因此无法校验激活码结构是否合法；本项目的强校验逻辑能挡掉一批“看起来像激活码”的脏数据。第三类是各类“eSIM 管理 App”，多数绑定自家商城，本质是销售渠道的引流工具，而非面向自由用户的工具集。

真正的杀手锏是多账号、多运营商下的可重放性：把一次成功的换卡过程沉淀为可复用的操作序列，这对频繁更换测试设备、或需要为自己和家人维护多张保号卡的用户来说是刚需。

应用场景与落地建议

适用场景相当垂直：跨境保号用户、需要把实体卡迁到平板或手表副设备的用户、以及在多台测试机之间轮换同一号码的开发者。它不适合作为企业级批量开户或号码管理的生产组件——那是 SM-DP+ 与 MNO 的领域，不是网页自动化的能力边界。

落地时必须正视几个风险点。其一，凭据安全：登录态与 OTP 属于高敏感信息，工具若以 Web 形式部署，务必自建而非使用公共实例，避免账号被第三方截获。其二，运营商 ToS：自动化访问用户中心在多数运营商条款中处于灰色地带，高频请求极易触发风控与号码冻结。其三，流程脆弱性：页面结构一旦改版，适配器即刻失效，使用者要有“随时需要自己修 driver”的心理预期。其四，二维码即号码：激活码泄露等同于号码被接管，生成后应立即离线保存，切勿留在聊天记录或云端相册。

综合评价

优点很突出：定位精准到“只服务已有 Giffgaff / Simyo 号码的人”，不做无谓的功能扩张；架构上把运营商差异收敛到适配器层，扩展成本低；对激活码的规范化处理切中了真实的失败点，是有实际工程判断的取舍。

短板同样明显：它本质上是运营商网页流程的自动化封装，而非 eSIM 协议栈的实现，因此天然缺乏稳定性保障，属于“上游一改版就得跟着改”的软肋型项目；同时缺少对 eUICC 侧能力的触达（profile 删除、跨设备迁移的合规路径仍需回到运营商），闭环并不完整；合规层面也无明确背书，使用者需自行承担风险。

一句话总结：这是一个边界清醒、工程诚实的小工具，它不试图解决 eSIM 生态的结构性问题，只把一段人人都会踩坑的流程打磨到可复现——对于目标用户，这恰恰是最有价值的部分。