北京
上个月，我通过印度邮政的Speed Post寄了一块硬盘。柜台职员递回一张收据，用蓝笔在一串字母数字上画了个圈，说了句“track kar lena”（去查轨迹），就再没别的提示了。没有App，没有链接，什么都没有。我照着大多数人会做的，把这段字符敲进查询页面，然后盯着“Item Booked”的状态看了整整两天，心里慢慢认定包裹已经掉进了某个黑洞。其实包裹没事，好端端的。但作为开发者的那根神经发痒了：这些字符到底是什么东西？为什么是十三位？它有结构吗，还是说只是哪个数据库胡乱吐出来的一串玩意？结果我发现，它有实在的结构，一旦看懂，一半的包裹焦虑就没了。于是我对这个好奇的规律做了一个开发者最惯常的动作：把它“解析”了一遍。
每件Speed Post、挂号信和普通包裹，都遵循一种叫“UPU S10标准”的国际格式。名字听着很唬人，样子却极其简单。它永远是这种形状：EE 123456789 IN。两个字母，九位数字，再跟两个字母，总共十三个字符。拆开来是三个各有含义的部分：开头两个字母是服务代码，告诉你这是什么类型的邮件——大致能判断它应该多快；中间九位数字，是这一件邮件的唯一序列号；末尾两位字母，是原寄国代码，IN代表印度。来自境外的邮件会以US、CN、GB之类结尾。单凭末尾这一点，就能化解一大堆“等等，这到底是不是发自印度的包裹”的争论：以IN结尾的，就是从这儿出发的。知道这个形状后，一个正则表达式几乎不费吹灰之力就冒出来了。下面是我用来校验印度邮政追踪号的代码：
const S10 = /^[A-Z]{2}\d{9}[A-Z]{2}$/;function parseTracking(code) {const clean = code.trim().toUpperCase();if (!S10.test(clean)) return { valid: false };return {valid: true,service: clean.slice(0, 2), // EE, RX, CP...serial: clean.slice(2, 11), // 那9位数字country: clean.slice(11), // IN};}parseTracking("ee123456789in");// { valid: true, service: "EE", serial: "123456789", country: "IN" }
没什么花哨的。但把自己那张收据上的字符串塞进去跑一遍，竟有一种说不清的满足感，就好像邮政系统一声不吭地递给我一个API契约，而它自己从没提过这回事。
真正有价值的部分是那开头两个字母。它们对应一种服务，而服务就能大致告诉你预计要多久。如果以E开头，比如EE、ED、EM之类，那就是Speed Post或EMS，速度较快——同城一两天，跨城稍长，但也就几天的事。如果以R开头，比如RX、RK、RP，那就是挂号信，慢一些，不过是签收的，可追踪可追责。以C开头，比如CP、CE，那是普通包裹，走的是重量更大的普通包裹时效。而X通常代表特快包裹，属于很多电商使用的较快递道。这些信息最好当作强烈的暗示而不是铁律，因为印度邮政隔一段时间就会重组前缀。但总的来说，看到服务代码，你就能对包裹的节奏有个谱。比如，看到EE打头，却已经过了五天还没动静，那大概率就不是Speed Post该有的样子了。
把这套规则套到开发者熟悉的视角上，那个正则式就是印度邮政暴露出的一条“隐式接口”。柜台只给了你一个收据，但这张收据承载了一个可解析的结构。一旦你用代码把它解开，追踪过程就从“瞎等着看状态”变成“我知道它在某个服务类型里，按照这个类型的节奏跑”。而末尾的IN，则是一个小小的定心丸：至少它确实在这个国家的邮政系统里起过步。下次你再拿到那张蓝笔圈过的收据，或许也可以像我一样，在自己脑子里的解析器里跑一遍：服务代码，九位序列号，IN——然后，就可以安心地等了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
