简介一套基于J2ME/MIDP的移动设备识别与基站信息获取示例工程面向需要开发设备管理、防盗追踪或基站定位应用的Java移动开发者适用于具备基础J2ME知识、希望掌握MIDlet中设备标识与小区定位API的读者。压缩包共20个文件涵盖4个Java源文件、6个class编译文件、1个JAD描述、1个JAR包以及properties/XML配置和NetBeans工程文件其中源文件用于查看实现逻辑编译产物可直接部署验证整体仅41KB从src到dist结构完整便于直接导入IDE分析。目前已有219人学习具备一定参考热度。资料核心价值在于完整演示通过System.getProperty(com.sun.radiomgt.imei)读取15位IMEI码的简洁方法同时给出利用位置API获取基站LAC/CID的代码思路这类信息可在GPS信号不佳时辅助估算终端位置并附有src源码与dist编译产物方便对照学习J2ME中设备标识与基站定位的关键技术可直接用于定位类、设备管理类应用的开发参考。研读该工程还能了解MIDlet工程从源码、JAD/JAR清单到打包的完整组织方式对规范开展J2ME项目开发有实际帮助。1. 基站采集的IMEI数据包为何都在RAR里处理过路测或基站工参数据的工程师大概率收到过类似IMEI.rar的压缩包。这类压缩包装的是从基站侧抓取或路测软件导出的IMEI记录配合LAC、CellID、时间戳能还原一部终端在某基站下的驻留情况。它经常被用于覆盖评估、用户分布分析、终端型号占比统计也会被安全团队拿去做异常号码追溯。反直觉的地方在于这类数据包往往不带数据库文件而是一堆几百MB的CSV或TXT压缩后以RAR分卷形式传递。原因不复杂——日志文件重复度高RAR的压缩率比ZIP更友好而且很多采集服务商仍用旧式脚本打包多卷没合并就直接发了出来。所以第一步不是分析数据而是先把解压、校验、字段恢复这几道工序做扎实否则后续所有聚合统计都会建立在脏数据上。下面按“解压→校验→定位→聚合→验证”的顺序把完整链路展开。2. 解压环节RAR批量解压与文件结构判断2.1 先判断压缩包内层结构再动手不要拿到IMEI.rar就直接解压。基站数据包存在大量同名文件、嵌套压缩、GBK编码文件名混用的情况直接解开会得到一层__MACOSX、._前缀文件和一堆无法识别的目录。常见做法是先列出压缩包内文件清单#!/bin/bash rar_file/data/IMEI.rar # 7z 也兼容 RAR能列出多卷和注释 7z l $rar_file | head -80 # 如果机器上有 unar则输出更干净 unar -f -o /data/raw $rar_file7z l会把文件路径、原体积、压缩后体积打出来先花十秒钟确认内层是单一文本文件还是按日期分目录还是TA/xxx/imei_log_2024-09-01.txt这种带网元编号的层级。看到File Name列里有中文乱码后面解压时要考虑编码转换看到多个.part1.rar、.part2.rar就要按顺序整体处理不能单独解开某一个分卷。我先用自己的判断说明一个通用结论从这类压缩包的命名习惯看绝大多数是采集程序按小时切分日志再用服务端脚本打包文件名形如20240910_1800_IMEI_UE_LOG.txt。这种文件每行的列位置固定但列分隔符可能是竖线、逗号或制表符下面几节的处理都基于这个前提。2.2 用 unar 批量解压嵌套 RAR 包macOS 下的The Unarchiver命令行版unar是目前处理混合压缩格式最省心的命令它比unrar强在两点自动处理文件名编码、自动展开嵌套压缩包。Linux 上可以用unar的发行包安装或者直接用unrar加循环#!/bin/bash # 批量解压 data 目录下所有 .rar 到 /data/raw for f in /data/*.rar; do echo [-] extracting $f unar -f -o /data/raw $f -D done参数从左到右依次是-f允许覆盖已存在文件避免重复任务中断-o指定输出目录-D跳过__MACOSX这类资源文件夹。unar的优势在于内层若是tar.gz或zip它会自动递归解到底这对乱套的基站数据包很有用因为经常出现“RAR 里面包着一个 ZIPZIP 里面才是 txt”的怪结构。没有unar时替代方案是7z x配合-y和-o但得手动处理嵌套。注意解压后立即用du -sh /data/raw核对总体积若解出来只有几 MB而 RAR 原本就有上百 MB说明解压被中断或压缩包被拆分过后续统计会缺一大块。2.3 加密 RAR 与“查看 RAR 密码”的常见误区热词里总能看到“16进制编辑器查看rar密码”“rar password cracker”这类搜索这里把结论说清楚用十六进制编辑器打开 RAR 文件能看到的是 RAR 文件头里的版本标记、压缩算法标识、文件大小的打包信息以及最关键的加密标记位但看不到密码本身。密码在计算头校验和时参与运算但不以明文或可逆形式存在于文件中。于是网上的“查看密码”基本是两类结果一种是把压缩包注释里的提示信息误当成密码另一种是用暴力恢复工具在本地跑字典。# 用十六进制方式查看 RAR 文件头确认是否加密 xxd /data/IMEI.rar | head -5观察输出RAR4 头以52 61 72 21 1A 07 00开头如果其中的HEAD_FLAGS位置出现0x80表示该文件被加密。真正需要的动作是如果密码还有线索先试压缩包注释和交接文档如果完全没有线索且确实是数据提供方设置的统一密码最合理的方式是联系对方要密码而不是自行跑暴力恢复。自己负责的、有明确权限的压缩包忘记密码时可以用知名的恢复类工具搭配基础字典跑一遍但这属于最后手段不能用来处理别人发来的陌生包。拿到正确密码后解压时用-p参数一次性传入unar -p YourPass -f -o /data/raw /data/IMEI.rar在自动化处理里不建议把密码硬编码在命令行里改用环境变量传入并关闭 shell 历史记录更安全。解压完成后如果后续工具不读 RAR顺手把明文结果重压为无密码的.tar.zst或.zip这也覆盖了“rar 密码移除”的真实需求——移除的是解压障碍不是文件头里的加密标记。unar 参数作用典型场景-o指定输出目录统一落到 /data/raw 便于后续处理-f覆盖已存在文件重复跑流程时防止中断-D跳过 __MACOSX 目录避免垃圾目录混入数据-p传入解压密码处理加密的基站数据包-e指定文件编码遇到 GBK 文件名乱码时使用3. IMEI 与 MEID 的校验和清洗Luhn 算法与字段抽取3.1 先分辨 15 位 IMEI、16 位 IMEISV 和 14 位 MEID拿到解压后的日志文件最常见的字段不是标准 15 位 IMEI而是三种形态混在一起。设备上报时GSM/WCDMA/LTE 终端给的是 IMEI 或 IMEISVCDMA 终端给的是 MEID部分老模块会把 MEID 转成伪 IMEI 上报。直接按 15 位数字去匹配会漏掉一批。标识类型长度格式校验方法IMEI15 位数字TAC(6) FAC(2) SNR(6) CD(1)Luhn 校验最后一位IMEISV16 位数字TAC(6) FAC(2) SNR(6) SVN(2)前 14 位按 Luhn 算后 2 位是软件版本MEID14 位十六进制RR(2) TAC(4) SNR(6) CD(2)十六进制 Luhn 变体这里有个容易踩的坑很多人把 16 位 IMEISV 直接截断成 15 位去校验结果发现校验位不对。正确的做法是先按位数判断类型IMEISV 的第 15、16 位是软件版本号不参与校验MEID 的十六进制字符包含A-F不能用纯十进制正则去匹配。从基站日志里做清洗时我先按类型拆开再分别校验避免脏数据混进聚合结果。3.2 用 Python 实现 Luhn 校验并批量验证Luhn 算法本身不复杂用于 IMEI 校验时注意方向从右往左奇数位翻倍翻倍后如果超过 9 就减 9累加结果对 10 取模应为 0。直接实现成可复用的函数再套到整个 DataFrame 上import pandas as pd def luhn_checksum(digits: str) - bool: 对 15 位 IMEI 做 Luhn 校验输入去掉空格 if len(digits) ! 15 or not digits.isdigit(): return False total 0 # 从右向左最后一位是校验位 for i, ch in enumerate(reversed(digits)): d int(ch) if i % 2 1: d * 2 if d 9: d - 9 total d return total % 10 0 df pd.read_csv(/data/raw/imei_log.txt, sep|, headerNone, names[ts, imei, lac, cid, rat], dtypestr) df[imei_valid] df[imei].apply(luhn_checksum) valid_mask df[imei_valid] (df[imei] ! 000000000000000) invalid df[~valid_mask] print(fvalid: {valid_mask.sum()}, invalid: {len(invalid)})逻辑说明reversed(digits)把字符串反转后索引 0 是校验位所在位置索引为奇数时翻倍正是标准算法中“偶数位置翻倍”的镜像实现。用dtypestr读入是为了防止 pandas 把 15 位数字转成科学计数法。0x000000000000000这种全零值在工程测试手机和部分物联网模块上常见需要单独统计不能直接判定为无效。对校验失败的记录如果只有几十条可以做人工复核如果超过总行数 5%说明上游字段错位需要回到原始 RAR 重新核对列分隔符。3.3 从原始日志中正则抽取 IMEI 与去重日志文件格式不总是规整的竖线分隔有时是自由文本比如[2024-09-10 18:00:12] imei: 864387030256890, rssi: -72。这种情况下用正则更稳妥import re def extract_imei(line: str): # 优先匹配 imei: 后的连续数字避免扫到时间戳 m re.search(rimei[:\s]*([0-9]{15}), line, re.I) if m: return m.group(1) # 没有显式标签时找一行中的 15 位连续数字 m re.search(r(?!\d)([0-9]{15})(?!\d), line) return m.group(1) if m else None正则里的(?!\d)和(?!\d)是前后边界断言防止匹配到 16 位 IMEISV 的前 15 位。用re.I处理不统一的大小写。推荐先以imei:标签为准因为路测软件的文本日志里时间戳也是连续数字不带标签的盲匹配风险较高。抽取完成后按基站维度去重时要注意同一个 IMEI 在一小时内多次出现在同一基站是正常的驻留记录不能算多台设备。先按[imei, lac, cid, date]去重再做聚合统计得到的结果才反映“独立终端数”。去重操作建议用subset参数显式指定列避免 pandas 默认按全行去重后保留无意义的重复时间戳df df.drop_duplicates(subset[imei, lac, cid, day])4. 基站数据落地从 LAC/CID 到经纬度聚合4.1 解析 LAC 和 CID统一十六进制与十进制基站日志里 LAC位置区码和 CID小区标识经常是混着来的有的设备上报十进制有的上报0x0A1B这样的十六进制字符串。如果不统一同一个小区会被拆成两条记录。解析时先按0x前缀判断进制再转成整数作为聚合键def parse_cell(v): 统一 LAC/CID 进制返回十进制整数值 s str(v).strip() if s.lower().startswith(0x): return int(s, 16) if : in s: parts s.split(:) return (int(parts[0], 16) 16) | int(parts[1], 16) return int(s) df[lac_int] df[lac].apply(parse_cell) df[cid_int] df[cid].apply(parse_cell) df[cell_key] df[lac_int].astype(str) - df[cid_int].astype(str)注意 5G 基站的日志结构更复杂一些LTE 用的是 LACCIDNR 接入网给的是 TAC跟踪区码 NRCellIDNRCellID 有的厂商按 24 位上报有的按 36 位全局小区标识上报。如果直接把 5G 日志里的cid当作 4G 的cell_id去查基站位置经纬度会偏掉。处理 5G 数据时我一般把聚合键改成tac nr_cell_id并且在字段名上单独标记ratnr避免落到老键里产生歧义。4.2 LAC 基站 CID 位置查询入口公开 API 与离线工参表要把lac-cid变成经纬度行业内常见做法有三条路第一是直接用厂商或运营商下发的工参表离线匹配准确率最高第二是通过 OpenCellID 这类开放基站数据库的 API 查询覆盖范围广但小区位置可能漂移第三是网上各色“基站定位查询入口”这类工具多是把同一个数据集包装成网页结果可信度参差。没有工参表时我优先用 OpenCellID APIimport requests def query_opencellid(api_key: str, lac: int, cid: int): 通过 OpenCellID 查询基站经纬度返回 (lat, lon) url https://opencellid.org/ajax/getCell.php params { key: api_key, mcc: 460, # 中国区 MCC按实际网络调整 mnc: 0, lac: lac, cell_id: cid, format: json, } resp requests.get(url, paramsparams, timeout8) resp.raise_for_status() return resp.json().get(lat), resp.json().get(lon)mcc460表示中国境内网络mnc要与实际运营商对应移动 0/2、联通 1、电信 3。这个接口的免费额度有限单一基站数据量上了千条建议转离线工参表。注意返回值里lat/lon缺失时接口只返回status: 404或空对象代码里要做异常处理避免整个任务中断。对于刚开站或室分站点OpenCellID 可能没有记录此时再退回“最近邻基站”的逻辑用已解析基站的经纬度做空间插值而不是直接丢弃。4.3 按基站聚合 IMEI输出多维度统计聚合统计是整个流水线里最有业务价值的一步。以cell_key为分组键分别统计原始 IMEI 出现次数、去重后的独立 IMEI 数以及该基站下采集到的最早和最新时间summary df.groupby([cell_key, lac_int, cid_int]).agg( hits(imei, count), unique_imei(imei, nunique), first_seen(ts, min), last_seen(ts, max), ).reset_index() summary[stay_span_min] ( pd.to_datetime(summary[last_seen]) - pd.to_datetime(summary[first_seen]) ).dt.total_seconds() / 60 summary.to_csv(/data/out/base_station_summary.csv, indexFalse)nunique比count更重要前者是独立终端数后者包含同一终端在覆盖内反复重选的次数。stay_span_min用来识别异常基站——如果一个基站的驻留跨度超过 24 小时同时独立 IMEI 数只有个位数大概率是测试环境下长期连接的工程机分析用户分布时应单独分组。输出到 CSV 后下一步再与经纬度表做left join就能在地图工具里直接拉点。5. 构建一条自动化的基站 IMEI 分析流水线5.1 用 Python 串联解压、校验、聚合全流程前面的步骤独立跑通后瓶颈变成手工操作太多。我习惯于用 Python 脚本把流程串成一个入口解压交给unar子进程清洗和聚合留在 pandas 里。这样做的好处是RAR 包是外部来源时不需要打开命令行一步步敲增量数据进来时全量重跑一次也就几分钟。import subprocess, glob, pandas as pd RAW_DIR /data/raw OUT_DIR /data/out def extract_all(glob_pattern/data/*.rar): for f in sorted(glob.glob(glob_pattern)): subprocess.run([unar, -f, -o, RAW_DIR, f], checkTrue) def process_all(): frames [] for txt in glob.glob(f{RAW_DIR}/*.txt): df pd.read_csv(txt, sep|, headerNone, names[ts, imei, lac, cid, rat], dtypestr) df[src_file] txt frames.append(df) data pd.concat(frames, ignore_indexTrue) # 按第 3 节逻辑做清洗 data[imei_valid] data[imei].apply(luhn_checksum) data data[data[imei_valid]] return data if __name__ __main__: extract_all() df process_all() df.to_parquet(f{OUT_DIR}/clean_imei.parquet)subprocess.run里的checkTrue保证解压失败时脚本直接退出而不是带着残缺数据继续跑。glob排序保证多分卷 RAR 按文件名顺序处理part1 到 part3 不会乱序。最终输出parquet而非 CSV是为后续大数据量迭代省时间和磁盘。文件级联时记录src_file字段出了问题可以直接定位到是哪一小时的日志。5.2 参数化配置时间窗口、阈值与输出目录不在脚本里写死路径和阈值用配置文件或环境变量统一管理是流水线能稳定跑下去的另一个关键。下面这些参数是我在类似处理链路里常用的起步值按数据量调整参数建议值说明TIME_WINDOW_MIN60 分钟同一 IMEI 在同一小区出现间隔小于窗口则视为同一驻留会话MIN_HITS3 次低于该阈值的基站记录在聚合时标记为“稀疏采样”仍保留但不参与覆盖分析UNIQUE_RATIO_MIN0.05独立 IMEI 数除以原始 hits 数低于该值说明有终端反复重选需要去重OUTPUT_FORMATparquet中间结果用列式存储最终呈现转 CSVINVALID_RATIO_ALERT0.1无效 IMEI 比例超过 10% 时触发告警停止生成报告5.3 常见异常场景与处理策略流水线跑多了问题往往不在算法而在数据本身。最常见的三类解压时报CRC Failed一般是压缩包传输不完整IMEI 校验批量失败是列顺序对不上LAC/CID 字段大量为空是采集端的日志级别没开全。try: df pd.read_csv(file, sep|, dtypestr) except pd.errors.EmptyDataError: print(f[warn] empty file: {file}) return None except UnicodeDecodeError: print(f[warn] encoding error: {file}, skip gbk check) df pd.read_csv(file, sep|, encodinggbk, dtypestr) if df[imei].eq(000000000000000).mean() 0.2: raise RuntimeError(ftoo many dummy IMEI in {file}, check source)EmptyDataError对应空文件多半是压缩包内层目录结构不一致建议跳过而不是中断全任务。UnicodeDecodeError对应 GBK 文件用encodinggbk回退读取。全零 IMEI 比例超过 20% 时直接RuntimeError中断因为继续做出来的报告没有参考价值宁可报警等人介入。6. 用文本抄表报告验证流水线结果抽 10% 人工核对6.1 对比原始记录数与清洗后记录数自动化流水线输出结果后第一件事不是直接看聚合表而是做往返核对。用一个简单命令把各阶段的记录数拉出来printf raw lines: %d\n $(cat /data/raw/*.txt | wc -l) printf clean lines: %d\n $(wc -l /data/out/clean_imei.csv)行数减少在 5% 以内通常是正常清洗全零 IMEI、校验位错误、空行减少超过 20% 就要怀疑正则或列分隔符配置有误。异常比例要和前面INVALID_RATIO_ALERT参数的阈值对照。6.2 生成抽样核对脚本附上校验位结果人工核对不宜看全量数据按基站随机抽 10% 的输出即可。我习惯让脚本直接生成可读的文本报告每一行包含原始 IMEI、校验结果、所在基站和去重标记sample summary[summary[unique_imei] 0].sample(frac0.1, random_state42) for _, row in sample.iterrows(): imei_valid luhn_checksum(str(row[imei])) print(f{row[cell_key]} | imei{row[imei]} | luhn{imei_valid} f| unique{row[unique_imei]} | hits{row[hits]})random_state42保证每次抽样结果一致便于前后两次运行对比。核对时重点看三处Luhn 校验位是否全部通过unique_imei是否小于等于hits以及同一cell_key下的经纬度是否集中在合理范围内。最后把报告文件和每批原始 RAR 包的 MD5 值一起存到report/2024-09-11/目录后续任何一次结果回溯都能确认数据版本不需要重新解压整个 RAR。本文还有配套的精品资源点击获取
基站IMEI数据处理全流程：RAR解压、Luhn校验与位置聚合
简介一套基于J2ME/MIDP的移动设备识别与基站信息获取示例工程面向需要开发设备管理、防盗追踪或基站定位应用的Java移动开发者适用于具备基础J2ME知识、希望掌握MIDlet中设备标识与小区定位API的读者。压缩包共20个文件涵盖4个Java源文件、6个class编译文件、1个JAD描述、1个JAR包以及properties/XML配置和NetBeans工程文件其中源文件用于查看实现逻辑编译产物可直接部署验证整体仅41KB从src到dist结构完整便于直接导入IDE分析。目前已有219人学习具备一定参考热度。资料核心价值在于完整演示通过System.getProperty(com.sun.radiomgt.imei)读取15位IMEI码的简洁方法同时给出利用位置API获取基站LAC/CID的代码思路这类信息可在GPS信号不佳时辅助估算终端位置并附有src源码与dist编译产物方便对照学习J2ME中设备标识与基站定位的关键技术可直接用于定位类、设备管理类应用的开发参考。研读该工程还能了解MIDlet工程从源码、JAD/JAR清单到打包的完整组织方式对规范开展J2ME项目开发有实际帮助。1. 基站采集的IMEI数据包为何都在RAR里处理过路测或基站工参数据的工程师大概率收到过类似IMEI.rar的压缩包。这类压缩包装的是从基站侧抓取或路测软件导出的IMEI记录配合LAC、CellID、时间戳能还原一部终端在某基站下的驻留情况。它经常被用于覆盖评估、用户分布分析、终端型号占比统计也会被安全团队拿去做异常号码追溯。反直觉的地方在于这类数据包往往不带数据库文件而是一堆几百MB的CSV或TXT压缩后以RAR分卷形式传递。原因不复杂——日志文件重复度高RAR的压缩率比ZIP更友好而且很多采集服务商仍用旧式脚本打包多卷没合并就直接发了出来。所以第一步不是分析数据而是先把解压、校验、字段恢复这几道工序做扎实否则后续所有聚合统计都会建立在脏数据上。下面按“解压→校验→定位→聚合→验证”的顺序把完整链路展开。2. 解压环节RAR批量解压与文件结构判断2.1 先判断压缩包内层结构再动手不要拿到IMEI.rar就直接解压。基站数据包存在大量同名文件、嵌套压缩、GBK编码文件名混用的情况直接解开会得到一层__MACOSX、._前缀文件和一堆无法识别的目录。常见做法是先列出压缩包内文件清单#!/bin/bash rar_file/data/IMEI.rar # 7z 也兼容 RAR能列出多卷和注释 7z l $rar_file | head -80 # 如果机器上有 unar则输出更干净 unar -f -o /data/raw $rar_file7z l会把文件路径、原体积、压缩后体积打出来先花十秒钟确认内层是单一文本文件还是按日期分目录还是TA/xxx/imei_log_2024-09-01.txt这种带网元编号的层级。看到File Name列里有中文乱码后面解压时要考虑编码转换看到多个.part1.rar、.part2.rar就要按顺序整体处理不能单独解开某一个分卷。我先用自己的判断说明一个通用结论从这类压缩包的命名习惯看绝大多数是采集程序按小时切分日志再用服务端脚本打包文件名形如20240910_1800_IMEI_UE_LOG.txt。这种文件每行的列位置固定但列分隔符可能是竖线、逗号或制表符下面几节的处理都基于这个前提。2.2 用 unar 批量解压嵌套 RAR 包macOS 下的The Unarchiver命令行版unar是目前处理混合压缩格式最省心的命令它比unrar强在两点自动处理文件名编码、自动展开嵌套压缩包。Linux 上可以用unar的发行包安装或者直接用unrar加循环#!/bin/bash # 批量解压 data 目录下所有 .rar 到 /data/raw for f in /data/*.rar; do echo [-] extracting $f unar -f -o /data/raw $f -D done参数从左到右依次是-f允许覆盖已存在文件避免重复任务中断-o指定输出目录-D跳过__MACOSX这类资源文件夹。unar的优势在于内层若是tar.gz或zip它会自动递归解到底这对乱套的基站数据包很有用因为经常出现“RAR 里面包着一个 ZIPZIP 里面才是 txt”的怪结构。没有unar时替代方案是7z x配合-y和-o但得手动处理嵌套。注意解压后立即用du -sh /data/raw核对总体积若解出来只有几 MB而 RAR 原本就有上百 MB说明解压被中断或压缩包被拆分过后续统计会缺一大块。2.3 加密 RAR 与“查看 RAR 密码”的常见误区热词里总能看到“16进制编辑器查看rar密码”“rar password cracker”这类搜索这里把结论说清楚用十六进制编辑器打开 RAR 文件能看到的是 RAR 文件头里的版本标记、压缩算法标识、文件大小的打包信息以及最关键的加密标记位但看不到密码本身。密码在计算头校验和时参与运算但不以明文或可逆形式存在于文件中。于是网上的“查看密码”基本是两类结果一种是把压缩包注释里的提示信息误当成密码另一种是用暴力恢复工具在本地跑字典。# 用十六进制方式查看 RAR 文件头确认是否加密 xxd /data/IMEI.rar | head -5观察输出RAR4 头以52 61 72 21 1A 07 00开头如果其中的HEAD_FLAGS位置出现0x80表示该文件被加密。真正需要的动作是如果密码还有线索先试压缩包注释和交接文档如果完全没有线索且确实是数据提供方设置的统一密码最合理的方式是联系对方要密码而不是自行跑暴力恢复。自己负责的、有明确权限的压缩包忘记密码时可以用知名的恢复类工具搭配基础字典跑一遍但这属于最后手段不能用来处理别人发来的陌生包。拿到正确密码后解压时用-p参数一次性传入unar -p YourPass -f -o /data/raw /data/IMEI.rar在自动化处理里不建议把密码硬编码在命令行里改用环境变量传入并关闭 shell 历史记录更安全。解压完成后如果后续工具不读 RAR顺手把明文结果重压为无密码的.tar.zst或.zip这也覆盖了“rar 密码移除”的真实需求——移除的是解压障碍不是文件头里的加密标记。unar 参数作用典型场景-o指定输出目录统一落到 /data/raw 便于后续处理-f覆盖已存在文件重复跑流程时防止中断-D跳过 __MACOSX 目录避免垃圾目录混入数据-p传入解压密码处理加密的基站数据包-e指定文件编码遇到 GBK 文件名乱码时使用3. IMEI 与 MEID 的校验和清洗Luhn 算法与字段抽取3.1 先分辨 15 位 IMEI、16 位 IMEISV 和 14 位 MEID拿到解压后的日志文件最常见的字段不是标准 15 位 IMEI而是三种形态混在一起。设备上报时GSM/WCDMA/LTE 终端给的是 IMEI 或 IMEISVCDMA 终端给的是 MEID部分老模块会把 MEID 转成伪 IMEI 上报。直接按 15 位数字去匹配会漏掉一批。标识类型长度格式校验方法IMEI15 位数字TAC(6) FAC(2) SNR(6) CD(1)Luhn 校验最后一位IMEISV16 位数字TAC(6) FAC(2) SNR(6) SVN(2)前 14 位按 Luhn 算后 2 位是软件版本MEID14 位十六进制RR(2) TAC(4) SNR(6) CD(2)十六进制 Luhn 变体这里有个容易踩的坑很多人把 16 位 IMEISV 直接截断成 15 位去校验结果发现校验位不对。正确的做法是先按位数判断类型IMEISV 的第 15、16 位是软件版本号不参与校验MEID 的十六进制字符包含A-F不能用纯十进制正则去匹配。从基站日志里做清洗时我先按类型拆开再分别校验避免脏数据混进聚合结果。3.2 用 Python 实现 Luhn 校验并批量验证Luhn 算法本身不复杂用于 IMEI 校验时注意方向从右往左奇数位翻倍翻倍后如果超过 9 就减 9累加结果对 10 取模应为 0。直接实现成可复用的函数再套到整个 DataFrame 上import pandas as pd def luhn_checksum(digits: str) - bool: 对 15 位 IMEI 做 Luhn 校验输入去掉空格 if len(digits) ! 15 or not digits.isdigit(): return False total 0 # 从右向左最后一位是校验位 for i, ch in enumerate(reversed(digits)): d int(ch) if i % 2 1: d * 2 if d 9: d - 9 total d return total % 10 0 df pd.read_csv(/data/raw/imei_log.txt, sep|, headerNone, names[ts, imei, lac, cid, rat], dtypestr) df[imei_valid] df[imei].apply(luhn_checksum) valid_mask df[imei_valid] (df[imei] ! 000000000000000) invalid df[~valid_mask] print(fvalid: {valid_mask.sum()}, invalid: {len(invalid)})逻辑说明reversed(digits)把字符串反转后索引 0 是校验位所在位置索引为奇数时翻倍正是标准算法中“偶数位置翻倍”的镜像实现。用dtypestr读入是为了防止 pandas 把 15 位数字转成科学计数法。0x000000000000000这种全零值在工程测试手机和部分物联网模块上常见需要单独统计不能直接判定为无效。对校验失败的记录如果只有几十条可以做人工复核如果超过总行数 5%说明上游字段错位需要回到原始 RAR 重新核对列分隔符。3.3 从原始日志中正则抽取 IMEI 与去重日志文件格式不总是规整的竖线分隔有时是自由文本比如[2024-09-10 18:00:12] imei: 864387030256890, rssi: -72。这种情况下用正则更稳妥import re def extract_imei(line: str): # 优先匹配 imei: 后的连续数字避免扫到时间戳 m re.search(rimei[:\s]*([0-9]{15}), line, re.I) if m: return m.group(1) # 没有显式标签时找一行中的 15 位连续数字 m re.search(r(?!\d)([0-9]{15})(?!\d), line) return m.group(1) if m else None正则里的(?!\d)和(?!\d)是前后边界断言防止匹配到 16 位 IMEISV 的前 15 位。用re.I处理不统一的大小写。推荐先以imei:标签为准因为路测软件的文本日志里时间戳也是连续数字不带标签的盲匹配风险较高。抽取完成后按基站维度去重时要注意同一个 IMEI 在一小时内多次出现在同一基站是正常的驻留记录不能算多台设备。先按[imei, lac, cid, date]去重再做聚合统计得到的结果才反映“独立终端数”。去重操作建议用subset参数显式指定列避免 pandas 默认按全行去重后保留无意义的重复时间戳df df.drop_duplicates(subset[imei, lac, cid, day])4. 基站数据落地从 LAC/CID 到经纬度聚合4.1 解析 LAC 和 CID统一十六进制与十进制基站日志里 LAC位置区码和 CID小区标识经常是混着来的有的设备上报十进制有的上报0x0A1B这样的十六进制字符串。如果不统一同一个小区会被拆成两条记录。解析时先按0x前缀判断进制再转成整数作为聚合键def parse_cell(v): 统一 LAC/CID 进制返回十进制整数值 s str(v).strip() if s.lower().startswith(0x): return int(s, 16) if : in s: parts s.split(:) return (int(parts[0], 16) 16) | int(parts[1], 16) return int(s) df[lac_int] df[lac].apply(parse_cell) df[cid_int] df[cid].apply(parse_cell) df[cell_key] df[lac_int].astype(str) - df[cid_int].astype(str)注意 5G 基站的日志结构更复杂一些LTE 用的是 LACCIDNR 接入网给的是 TAC跟踪区码 NRCellIDNRCellID 有的厂商按 24 位上报有的按 36 位全局小区标识上报。如果直接把 5G 日志里的cid当作 4G 的cell_id去查基站位置经纬度会偏掉。处理 5G 数据时我一般把聚合键改成tac nr_cell_id并且在字段名上单独标记ratnr避免落到老键里产生歧义。4.2 LAC 基站 CID 位置查询入口公开 API 与离线工参表要把lac-cid变成经纬度行业内常见做法有三条路第一是直接用厂商或运营商下发的工参表离线匹配准确率最高第二是通过 OpenCellID 这类开放基站数据库的 API 查询覆盖范围广但小区位置可能漂移第三是网上各色“基站定位查询入口”这类工具多是把同一个数据集包装成网页结果可信度参差。没有工参表时我优先用 OpenCellID APIimport requests def query_opencellid(api_key: str, lac: int, cid: int): 通过 OpenCellID 查询基站经纬度返回 (lat, lon) url https://opencellid.org/ajax/getCell.php params { key: api_key, mcc: 460, # 中国区 MCC按实际网络调整 mnc: 0, lac: lac, cell_id: cid, format: json, } resp requests.get(url, paramsparams, timeout8) resp.raise_for_status() return resp.json().get(lat), resp.json().get(lon)mcc460表示中国境内网络mnc要与实际运营商对应移动 0/2、联通 1、电信 3。这个接口的免费额度有限单一基站数据量上了千条建议转离线工参表。注意返回值里lat/lon缺失时接口只返回status: 404或空对象代码里要做异常处理避免整个任务中断。对于刚开站或室分站点OpenCellID 可能没有记录此时再退回“最近邻基站”的逻辑用已解析基站的经纬度做空间插值而不是直接丢弃。4.3 按基站聚合 IMEI输出多维度统计聚合统计是整个流水线里最有业务价值的一步。以cell_key为分组键分别统计原始 IMEI 出现次数、去重后的独立 IMEI 数以及该基站下采集到的最早和最新时间summary df.groupby([cell_key, lac_int, cid_int]).agg( hits(imei, count), unique_imei(imei, nunique), first_seen(ts, min), last_seen(ts, max), ).reset_index() summary[stay_span_min] ( pd.to_datetime(summary[last_seen]) - pd.to_datetime(summary[first_seen]) ).dt.total_seconds() / 60 summary.to_csv(/data/out/base_station_summary.csv, indexFalse)nunique比count更重要前者是独立终端数后者包含同一终端在覆盖内反复重选的次数。stay_span_min用来识别异常基站——如果一个基站的驻留跨度超过 24 小时同时独立 IMEI 数只有个位数大概率是测试环境下长期连接的工程机分析用户分布时应单独分组。输出到 CSV 后下一步再与经纬度表做left join就能在地图工具里直接拉点。5. 构建一条自动化的基站 IMEI 分析流水线5.1 用 Python 串联解压、校验、聚合全流程前面的步骤独立跑通后瓶颈变成手工操作太多。我习惯于用 Python 脚本把流程串成一个入口解压交给unar子进程清洗和聚合留在 pandas 里。这样做的好处是RAR 包是外部来源时不需要打开命令行一步步敲增量数据进来时全量重跑一次也就几分钟。import subprocess, glob, pandas as pd RAW_DIR /data/raw OUT_DIR /data/out def extract_all(glob_pattern/data/*.rar): for f in sorted(glob.glob(glob_pattern)): subprocess.run([unar, -f, -o, RAW_DIR, f], checkTrue) def process_all(): frames [] for txt in glob.glob(f{RAW_DIR}/*.txt): df pd.read_csv(txt, sep|, headerNone, names[ts, imei, lac, cid, rat], dtypestr) df[src_file] txt frames.append(df) data pd.concat(frames, ignore_indexTrue) # 按第 3 节逻辑做清洗 data[imei_valid] data[imei].apply(luhn_checksum) data data[data[imei_valid]] return data if __name__ __main__: extract_all() df process_all() df.to_parquet(f{OUT_DIR}/clean_imei.parquet)subprocess.run里的checkTrue保证解压失败时脚本直接退出而不是带着残缺数据继续跑。glob排序保证多分卷 RAR 按文件名顺序处理part1 到 part3 不会乱序。最终输出parquet而非 CSV是为后续大数据量迭代省时间和磁盘。文件级联时记录src_file字段出了问题可以直接定位到是哪一小时的日志。5.2 参数化配置时间窗口、阈值与输出目录不在脚本里写死路径和阈值用配置文件或环境变量统一管理是流水线能稳定跑下去的另一个关键。下面这些参数是我在类似处理链路里常用的起步值按数据量调整参数建议值说明TIME_WINDOW_MIN60 分钟同一 IMEI 在同一小区出现间隔小于窗口则视为同一驻留会话MIN_HITS3 次低于该阈值的基站记录在聚合时标记为“稀疏采样”仍保留但不参与覆盖分析UNIQUE_RATIO_MIN0.05独立 IMEI 数除以原始 hits 数低于该值说明有终端反复重选需要去重OUTPUT_FORMATparquet中间结果用列式存储最终呈现转 CSVINVALID_RATIO_ALERT0.1无效 IMEI 比例超过 10% 时触发告警停止生成报告5.3 常见异常场景与处理策略流水线跑多了问题往往不在算法而在数据本身。最常见的三类解压时报CRC Failed一般是压缩包传输不完整IMEI 校验批量失败是列顺序对不上LAC/CID 字段大量为空是采集端的日志级别没开全。try: df pd.read_csv(file, sep|, dtypestr) except pd.errors.EmptyDataError: print(f[warn] empty file: {file}) return None except UnicodeDecodeError: print(f[warn] encoding error: {file}, skip gbk check) df pd.read_csv(file, sep|, encodinggbk, dtypestr) if df[imei].eq(000000000000000).mean() 0.2: raise RuntimeError(ftoo many dummy IMEI in {file}, check source)EmptyDataError对应空文件多半是压缩包内层目录结构不一致建议跳过而不是中断全任务。UnicodeDecodeError对应 GBK 文件用encodinggbk回退读取。全零 IMEI 比例超过 20% 时直接RuntimeError中断因为继续做出来的报告没有参考价值宁可报警等人介入。6. 用文本抄表报告验证流水线结果抽 10% 人工核对6.1 对比原始记录数与清洗后记录数自动化流水线输出结果后第一件事不是直接看聚合表而是做往返核对。用一个简单命令把各阶段的记录数拉出来printf raw lines: %d\n $(cat /data/raw/*.txt | wc -l) printf clean lines: %d\n $(wc -l /data/out/clean_imei.csv)行数减少在 5% 以内通常是正常清洗全零 IMEI、校验位错误、空行减少超过 20% 就要怀疑正则或列分隔符配置有误。异常比例要和前面INVALID_RATIO_ALERT参数的阈值对照。6.2 生成抽样核对脚本附上校验位结果人工核对不宜看全量数据按基站随机抽 10% 的输出即可。我习惯让脚本直接生成可读的文本报告每一行包含原始 IMEI、校验结果、所在基站和去重标记sample summary[summary[unique_imei] 0].sample(frac0.1, random_state42) for _, row in sample.iterrows(): imei_valid luhn_checksum(str(row[imei])) print(f{row[cell_key]} | imei{row[imei]} | luhn{imei_valid} f| unique{row[unique_imei]} | hits{row[hits]})random_state42保证每次抽样结果一致便于前后两次运行对比。核对时重点看三处Luhn 校验位是否全部通过unique_imei是否小于等于hits以及同一cell_key下的经纬度是否集中在合理范围内。最后把报告文件和每批原始 RAR 包的 MD5 值一起存到report/2024-09-11/目录后续任何一次结果回溯都能确认数据版本不需要重新解压整个 RAR。本文还有配套的精品资源点击获取