Android离线查询实战：身份证校验与手机号归属地数据库应用

简介这是一份Android手机号归属地、身份证归属及区号查询的APP实例源码定位为Android入门级练手项目特别适合刚接触Android开发的初学者通过三个贴近生活的查询功能快速熟悉界面搭建与基础逻辑。资源包共69个文件包含25个Java源文件、18个XML布局与配置文件、22张PNG图片另有工程配置所需的properties、cfg、project等文件整体压缩后仅76KB结构紧凑便于整体翻阅。该资源已有1656人学习/下载在同类基础实例中具备一定参考热度。阅读Java源码可掌握查询业务的后台调用与数据组织方式查看XML布局能学会常见控件搭配和界面设计技巧对照assets、gen等工程目录还能加深对Android项目结构的理解适合作为课程设计或课余自学的直接参考。 拿到这个“Android身份证、手机号码、区号查询APP实例.rar”标题的时候我心里大概就有数了——又是一个典型的Android入门到进阶的练手项目。别看它文件不大功能也看似简单但身份证校验、手机号归属地、区号查询这几个模块凑在一起几乎把Android开发里最常见的几个技术点都串了一遍SQLite数据库操作、Assets资源预加载、字符串正则校验、ListView/RecyclerView列表展示、Activity与Fragment布局通信。对于正在学Android、想找个完整项目练手的朋友来说这个东西的价值不在于“查询”本身而在于它是一套能跑通“数据准备 → 数据存储 → 业务处理 → 界面展示”全链路的微型样板工程。我会按自己做项目时的习惯把这个实例从里到外拆开讲清楚。先把功能需求和技术选型讲明白再把身份证、手机号、区号这三块数据结构逐一解析然后进入实操环节最后把当年踩过的坑和排查思路一并交代。无论你是刚装好Android Studio的新手还是写过几个Demo想系统整理一遍的老手读完这篇文章应该都能把这套实例吃透甚至改造成自己的工具箱。1. 功能需求与整体设计拆解1.1 三个查询功能背后的真实业务场景先聊聊这个例子到底在解决什么问题。身份证查询、手机号码归属地查询、区号查询这三个功能在实际生活中各有各的使用场景。身份证查询最常见的用途是“验真”和“还原信息”。你在做实名认证、后台审核、用户注册时经常需要判断一个18位身份证号是否格式合法以及从号码里提取出户籍所在省份、城市、出生日期、性别。身份证号码本身是一套高度结构化的编码不需要联网只要懂规则就能解析出大部分信息。手机号码归属地查询应用场景就更广了。运营商的号段一直在变从最早的13x、15x到后来的17x、19x每个号段对应的运营商和地区都在动态调整。一个能离线查询的本地库在CRM系统、客服工单、营销筛选、通讯录管理这些场景里都很实用尤其适合那些不能随时联网的内部系统。区号查询本质是一个静态数据表查询。虽然现在手机普及、固话使用率下降但很多企业通讯录、客服外呼系统、甚至个人给外地公司打电话时都还需要查区号。这个模块的数据量不大但非常考验一个初学者对SQLite索引和数据格式化的把握。所以这个项目的核心价值就是用一个完整的离线工具箱覆盖了几类真实、高频、不依赖网络的数据查询需求。做出来以后不仅能当作业交还能真正装到手机上日常使用。1.2 技术选型为什么要用本地数据库而不是在线接口很多刚接触Android的朋友看到“查询”两个字第一反应是“HttpURLConnection调接口不就行了吗”。这个思路没毛病但在当前这个实例的场景下选本地数据方案有充足的理由。在线接口的问题是身份证明文查询接口属于敏感数据访问个人开发者基本拿不到公开免费的稳定接口手机号归属地接口倒是有不少但要么有每日调用次数限制要么返回的字段不完整而且一旦断网就全盘罢工。本地数据库方案则把整个查询链条都攥在自己手里。Android内置的SQLite是轻量级嵌入式数据库完全满足这个体量的数据读写需求。身份证数据量小用代码硬编码或JSON都能存手机号码归属地可以整理成一张几万条的号段表区号表撑死几百条。把这些数据在App首次启动时导入SQLite之后所有查询都是毫秒级的纯本地IO完全离线可用也没有接口鉴权的麻烦。从学习角度说这个选择也更合适。这个例子的核心不是教你怎么写网络请求而是让你理解数据如何在Android App里流动从raw资源或assets到SQLite从SQLite到Cursor从Cursor到Adapter再从Adapter到ListView。这一条链路是Android开发的地基地基打不牢后面学Retrofit、Room、Jetpack Compose都会觉得飘。1.3 项目结构规划按模块拆分还是一个Activity走天下拿到实例源码后第一步不是急着跑起来而是先看它的包结构。好的项目结构功能一目了然烂的项目结构一个类几千行谁看谁头疼。我建议的划分方式是这样com.example.idquery/ ├── activity/ │ ├── MainActivity.java // 容器Activity承载三个Tab │ ├── IdCardQueryActivity.java // 身份证查询页 │ ├── PhoneQueryActivity.java // 手机号查询页 │ └── AreaCodeQueryActivity.java // 区号查询页 ├── db/ │ ├── DBHelper.java // SQLiteOpenHelper实现数据库创建与升级 │ ├── AssetsDatabaseManager.java // assets目录下数据库文件的复制与加载 │ └── QueryDao.java // 封装三类查询的数据访问逻辑 ├── model/ │ ├── IdCardInfo.java // 身份证信息实体 │ ├── PhoneInfo.java // 手机号归属地实体 │ └── AreaCodeInfo.java // 区号实体 └── utils/ ├── IdCardUtils.java // 身份证编码校验、生日性别解析 ├── PhoneValidateUtils.java // 手机号格式校验 └── RegexUtils.java // 通用正则工具如果原始实例只有一个Activity、几百行代码解决战斗也不奇怪很多教学项目都这么干。但你要自己动手改造的话建议按这个分层的思路来。Model层管数据实体DB层管数据存取Utils层管规则算法Activity只负责界面和交互。这样代码可读性和可维护性会有肉眼可见的提升后面加功能、修Bug也会轻松很多。2. 核心数据与编码规则解析2.1 身份证号码的结构18位数字是怎么“翻译”成信息的身份证查询模块的灵魂在于对18位身份证编码规则的理解。每个人的身份证号码不是随机生成的而是一串严格按国家标准编码的“信息压缩包”每一位都有明确含义。先说结构前6位是地址码表示编码对象常住户口所在县市、旗、区的行政区划代码例如110105代表北京市朝阳区第7到14位是出生日期码格式是YYYYMMDD第15到17位是顺序码表示同一地址码所标识的区域范围内、同年同月同日出生的顺序号其中第17位还用于标识性别奇数为男性、偶数为女性第18位是校验码由前17位数字通过特定算法计算得出校验码可能是0到9也可能是字母X。这个编码规则意味着只要拿到一个合法的18位身份证号就能离线解析出户籍地、出生日期、性别这三项核心信息。你在界面上看到的结果本质上就是把这串数字按照规则“翻译”成中文。校验码的算法是这个模块里一个特别适合学习的小细节也是面试官最爱问的一个点。算法流程是将身份证号码的前17位数字分别乘以对应的加权因子加权因子的固定的7 9 10 5 8 4 2 1 6 3 7 9 10 5 8 4 2将17个乘积相加除以11取余数。余数的范围是0到10每个余数对应一个校验码字符余数: 0 1 2 3 4 5 6 7 8 9 10 校验码: 1 0 X 9 8 7 6 5 4 3 2为什么偏偏是这个加权因子序列、这个校验码映射表这是设计者基于模11运算的特性为了尽可能让相邻位或替换错误暴露出校验差异而选定的。作为学习者你不需要重新推导这套数学原理但要能在代码里原样实现出来。2.2 手机号码归属地号段数据表的组织逻辑手机号码归属地查询和身份证解析完全不是一个思路。身份证是“算出来的”手机号归属地则是“查表查出来的”。一个手机号是11位前3位是网络识别号比如139、188、199等第4到第7位是地区编码后4位是随机分配的用户号。历史上前7位就能基本确定一个号码的归属地和运营商因为运营商在开号时是按号段批量分配给省市的。所以本地方案里手机号归属地查询表的核心字段就三个字段名类型说明prefixTEXT前7位号段作为主键或唯一索引cityTEXT归属地城市operatorTEXT运营商类型移动/联通/电信/广电等数据表结构不复杂真正的难点在数据来源。要整理一张完整的号段表通常需要从运营商公开资料、行业数据平台等处收集数据量一般在几万行左右。教学实例里通常不会放全量数据而是用一部分有代表性的号段演示逻辑。你在用的时候心里要有数示例数据覆盖不了全量号码生产环境一定要换全量库。查询流程也很直接拿到一个11位手机号先取前7位去号段表里按prefix精确匹配查到就返回城市和运营商。如果查不到就逐步退而求其次——用前3位粗查运营商因为网络识别号的前3位本身就对应运营商归属地则标明“未知”。2.3 区号查询表小而美的数据格式化案例区号查询是三块里数据最少的模块全国固定电话区号一共几百条但它有两个值得注意的细节。第一个细节是“0”和“去0”。查询展示时用户输入习惯千差万别有人输010有人输10有人输010-12345678有人直接输区号电话号码。所以查询前要统一做格式化先把电话号码和区号一起完整输入里拆出来再判断区号部分是否以0开头然后按标准格式去数据表匹配。数据表里存储的是不带0的区号比如北京存10广州存20查询时再补上0展示或者反过来存带0的表头查询时去掉0再去匹配两种方式都可以但要统一。第二个细节是区号与城市的多对多关系。有些城市有多个区号比如一个地级市下属县市可能共用一个区号但有些城市本地网与下属区县分开排号。数据表最好把同一个区号对应的所有城市都查出来用列表展示不要只显示一条。比如查询021应该返回上海含部分下属区域查询0311要返回石家庄全境。这是体现一个开发者是否考虑过数据边界的好细节。3. Android Studio中的环境准备与项目导入3.1 拿到.rar压缩包后的正确处理姿势当你手上只有一个“Android身份证手机号码、区号查询APP实例.rar”文件时第一步肯定是解压。但解压之后不要急着用Android Studio直接打开先看压缩包内层的目录结构。一般这种实例压缩包内部会有两种可能一种是打包了完整Android工程包含settings.gradle、build.gradle、gradle.properties、app模块等另一种是只打包了src源码和资源文件需要你自己新建工程再拷贝。完整工程的导入方式很简单Android Studio左上角“File → New → Import Project”选中解压后的目录IDE会识别Gradle工程并自动同步。如果同步过程中报Gradle版本不匹配、SDK版本缺失的错误大概率是你本地的Gradle版本和工程里配置的版本不一致。处理办法也直接根据Android Studio的报错提示点击“Install Gradle”或者修改gradle-wrapper.properties里的distributionUrl把它改成你本地已有的Gradle版本。如果是只有源码和res的打包方式就得自己新建工程然后把代码拷进去。这里要特别注意包名和R文件的引用问题源码里的import com.example.xxx.R会被Android Studio根据你新工程的包名自动修正但如果原包名不一致可能引发大量报错。最简单的避免方式是新建工程时把包名直接起成源码里的包名。3.2 Gradle与SDK版本配置的经验之谈实例项目大多是两三年前写的而Android Studio的版本迭代非常快所以“旧代码跑在新环境上”的版本冲突问题基本百分之百会发生。我自己的经验是不要追求原工程里的gradle和SDK版本原封不动而是做一次“顺向升级”。具体来说在app模块的build.gradle里把compileSdkVersion和targetSdkVersion调到当前Android Studio推荐的稳定版本比如compileSdk 33或34targetSdk 33或34minSdkVersion保持16到21都可以这样既能跑在新SDK上也能兼容老设备的测试。dependencies里的依赖版本同样建议用最新稳定版尤其是androidx.appcompat:appcompat和material这类包。老项目可能还在用com.android.support:appcompat-v7这种依赖在新SDK环境下容易出兼容问题建议整体迁移到AndroidX。3.3 真机调试前必做的两个环境检查代码同步完成后别急着点Run。先检查两件事。第一件事是USB调试授权。Android Studio 4.0以上版本跑真机时手机上必须开启“开发者选项”和“USB调试”并且在手机上确认授权弹窗。很多新手在第一步就被卡住屏幕上一直显示“no devices found”其实不是电脑没识别到手机而是手机上没授权。第二件事是SDK Platform版本。如果编译时提示“SDK component platform-tools is missing”需要到Android Studio的“SDK Manager”里把对应版本的SDK Platform和Build-Tools组件装上。这两步检查完点击运行按钮项目就应该在模拟器或真机上跑起来了。4. 核心功能实现细节数据库初始化与业务封装4.1 SQLite数据库初始化的两种方案对比数据库是这套实例的真正核心。很多初学者会问项目里那些.db文件、.sqlite文件要放哪里才能被App读取答案通常是两个assets目录或res/raw目录两种方式的处理逻辑略有差别。assets方式是把数据库文件放进src/main/assets/然后通过AssetsDatabaseManager类把文件复制到App的私有目录/data/data/包名/databases/。为什么要复制因为assets目录是只读的而SQLite需要在文件系统上创建写锁和日志文件直接在assets里打开数据库会报只读错误。复制完成后后续对数据库的增删改查都在私有目录副本上进行不影响原始包。raw方式则稍微有限制文件大小不能太大、文件名要求小写字母数字下划线开头而且R资源访问方式对文件名有约束。assets在存放通用数据文件时更灵活。我建议不管是写项目还是看别人的代码优先用assets方案。后续如果想升级号段数据库只需要替换assets里的文件、调整数据库版本号就能完成更新。首次启动复制数据库的代码骨架大致如下public class AssetsDatabaseManager { private static final String DB_NAME query_data.db; private static final String DB_PATH /data/data/ BuildConfig.APPLICATION_ID /databases/; public static boolean copyDatabase(Context context) { File dbFile new File(DB_PATH DB_NAME); if (dbFile.exists()) { return true; // 已存在则不重复复制 } try { File dir new File(DB_PATH); if (!dir.exists()) { dir.mkdirs(); } InputStream is context.getAssets().open(DB_NAME); OutputStream os new FileOutputStream(dbFile); byte[] buffer new byte[1024]; int length; while ((length is.read(buffer)) 0) { os.write(buffer, 0, length); } os.flush(); os.close(); is.close(); return true; } catch (IOException e) { e.printStackTrace(); return false; } } }4.2 身份证查询的业务实现与校验算法身份证查询的Activity逻辑可以拆成三步输入校验、信息解析、结果展示。输入校验用正则表达式就可以完成18位身份证的基本正则如下public static boolean isValidIdCardPattern(String idCard) { String regex ^[1-9]\\d{5}(18|19|20)\\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\\d|3[01])\\d{3}[0-9Xx]$; return idCard.matches(regex); }但正则只能做初步判断真正判断一个身份证号是否合法必须走校验码算法。上面提到的那套加权因子和校验码映射表代码实现如下public static boolean isValidIdCardNumber(String idCard) { if (!isValidIdCardPattern(idCard)) { return false; } int[] weights {7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2}; char[] checkCodes {1, 0, X, 9, 8, 7, 6, 5, 4, 3, 2}; int sum 0; for (int i 0; i 17; i) { sum (idCard.charAt(i) - 0) * weights[i]; } int mod sum % 11; char expected checkCodes[mod]; return Character.toUpperCase(idCard.charAt(17)) expected; }前6位地址码的解析需要一张行政区划代码表。实例项目里一般会打包一张全国省市县三级代码表用前6位作为主键去匹配。如果匹配不到不要直接报错要提示“该地址码暂未收录或为特殊权限码”比如有些历史上的撤销行政区划代码也需要兼容处理。出生日期直接取第7到14位子串按年、月、日拆分并格式化。性别判断则看第17位的奇偶奇数对应“男”偶数对应“女”。这三项解析完后把结果通过Intent传递或界面刷新显示即可。4.3 手机号归属地查询String取子串与模糊兜底手机号归属地查询的代码流程要简单不少。拿到完整号码先做基础格式校验public static boolean isMobileNumber(String number) { String regex ^1[3-9]\\d{9}$; return number.matches(regex); }校验通过后取前7位“prefix”直接执行SQL查询public PhoneInfo queryByPrefix(String prefix) { SQLiteDatabase db helper.getReadableDatabase(); Cursor cursor db.rawQuery(SELECT city, operator FROM phone_prefix WHERE prefix ?, new String[]{prefix}); PhoneInfo info null; if (cursor.moveToFirst()) { info new PhoneInfo(); info.setCity(cursor.getString(cursor.getColumnIndexOrThrow(city))); info.setOperator(cursor.getString(cursor.getColumnIndexOrThrow(operator))); } cursor.close(); return info; }如果前7位查不到就得做降级处理。有些新号段、携号转网号码前7位数据表里不一定能及时收录。这时候可以用前4位或前3位再查一次只返回运营商。这个兜底逻辑非常容易忽视但实际体验差距很大——与其显示“未知”不如先把运营商显示出来归属地留下“识别中”。这里的表结构还可以顺手优化一下查询速度给prefix字段建唯一索引几万条数据查起来就是毫秒级不加索引虽然也不会卡但加分项不拿白不拿。4.4 区号查询的输入清洗与结果展示区号查询模块的代码实现重心在“输入清洗”这个环节。用户输入的字符串五花八门可能是“010-62251234”这样的固话可能是“010 62251234”甚至可能是“01062251234”。如果不做清洗substring拿到的区号就是错的。推荐的清洗逻辑是去掉字符串中所有空格、短横线、括号等分隔符如果长度大于6通常说明用户输的是“区号电话号码”的组合可以从开头的0开始截取3到4位作为区号候选如果本身就是3到4位数字且以0开头直接作为区号处理如果开头不是0尝试补0后再查。查询结果展示时注意数据去重同一个区号对应多个城市的场景很常见用TextView拼接城市名时建议写成“上海本地网、上海崇明”之类的格式或者用Dialog列表展示。4.5 界面骨架Tab布局与查询结果自适应这个例子的UI层面做好看不是第一要务但交互逻辑必须顺。最常见的实现方式是MainActivity里放三个Tab可以用TabLayoutViewPager2也可以直接用TabHost每个Tab对应一个独立的查询页面。每个查询页面的基础组件组合是一个EditText用于输入一个Button用于触发查询一个TextView或者ListView用于展示结果。为了体验更好EditText的inputType建议做区分身份证和手机号输入框用android:inputTypenumber区号输入框用phone类型这样弹出来的是数字键盘。结果展示方面身份证解析结果字段多省份、城市、区县、出生日期、性别、是否合法建议用一个轻量的结果卡片布局用LinearLayout纵向排列一行行“标签值”。手机归属地和区号结果字段少直接用TextView显示“归属地某某市\n运营商某某”即可。5. 常见问题与排错实录5.1 数据库文件打不开只读复制异常这是我在处理各类Android实例时遇到概率最高的问题。症状表现为首次启动App时数据库相关的查询全部报错Logcat里出现“unable to open database file”。排查思路是按顺序看三步。第一步看assets路径是否正确。数据库文件必须放在app/src/main/assets/下而不是res/raw/下。很多人的压缩包里数据库文件放在了项目的根目录复制代码用的路径却是assets路径自然打不开。第二步看数据库文件是否损坏。可以直接在电脑上用SQLite工具打开assets里那个.db文件看看里面的表名和字段是否和代码里一致。老实例常见的问题是表名、字段名大小写不一致执行rawQuery时直接报“no such table”。第三步看复制后用InputStream读取时是否出现“BufferTooSmallException”这种情况多半是数据库文件没拷贝完整或者拷贝过程中并发访问了数据库。5.2 身份证校验结果与预期不符X的大小写问题身份证校验码为10时对应的字符是X而用户在输入时可能输入小写x也可能输入大写X。代码里如果不做统一会出现同一个号码有的机器上判合法、有的机器上判非法。处理方式很简单比对前统一转成大写参考上面代码示例里的Character.toUpperCase(idCard.charAt(17))。另外要提醒的是正则表达式里也要同时兼容大小写[0-9Xx]比[0-9X]更稳妥。5.3 手机号查询结果为空号段数据覆盖不足手机号归属地经常出现“查不到”的情况尤其是17x、19x的新号段和部分虚拟运营商号段。很多新手第一反应是代码写错了但用SQLite工具一查原始表才发现表里压根没有这条号段记录——这不是代码Bug是数据问题。要解决这个问题优先找一份最新全量的号段数据源替换assets下的数据库文件。如果找不到合规的数据源至少要在代码里做好降级提示不要直接显示“不存在”或“查询失败”。显示“该号段暂未收录可能为新号段或虚拟运营商”会让用户更容易接受。5.4 EditText只输入了半截号码就点击查询用户输入是个不可控行为。有人身份证号输到一半就去点击查询按钮有人手机号输入了10位就提交有人把“86 138xxxx”整个粘贴进来。这些都是要在代码里拦截的边界状态。我的做法是在点击查询按钮的事件回调里先对输入内容做trim再去掉“86”前缀然后走各自的校验器校验不通过就Toast提示具体原因。正常情况下给用户明确的错误反馈比查询结果本身更重要。5.5 离线数据库更新的升级策略这个坑一般是项目上线后才会发现的。如果App已经发布了一段时间用户手机里的数据库还是旧版本而你在新版里更新了号段表怎么让老用户的本地数据库自动升级答案是利用SQLiteOpenHelper的onUpgrade方法或者自定义数据库版本表。每次把数据库文件复制到私有目录时先读assets里新db文件的版本号可以存在一个meta表里与当前私有目录里的版本号做比较新版本大于旧版本就删除旧副本、拷贝新文件。这个思路虽然简单粗暴但在这个体量的项目中足够可靠。6. 实例改造扩展建议实例跑通不是终点能改造成自己想要的样子才是收获。基于这个例子我给出几个方向供参考。第一个方向是“加数据维度”。目前的区号查询只有“区号→城市”可以反向扩展“城市→区号”做成双向查询。手机号归属地还可以加入“卡类型”3G/4G/5G套餐、“地区邮编”等字段。每加一个字段就是对数据库设计和界面布局的一次小升级。第二个方向是“换个UI框架”。如果已经熟练掌握了传统View体系可以尝试把界面迁移到Compose。三个查询页面的逻辑保持不变只替换UI层渲染方式对比一下新旧方案的开发效率和运行表现会是一次很有价值的学习体验。第三个方向是“数据同步化”。保持本地库为主、在线更新为辅的双模式。App每次启动时后台检查服务器上的号段数据版本如果有更新增量下载并替换本地库。这样一来既保留了离线查询的快速响应又解决了数据时效性问题。这个方向的复杂度会上一个台阶涉及协程、网络请求、版本管理和文件下载适合作为进阶项目来练手。7. 一点实际操作中的体会按我自己的经验这种打包成.rar的教学实例看十遍源码不如亲手敲一遍。特别是身份证校验码计算、SQLite数据库从assets复制到私有目录这两个环节光看代码会觉得也就那样真到自己动手写的时候才发现到处都是细节——文件路径写错一个字母、数据库表字段名对不上、输入框没有过滤空格全都会变成折磨人的Bug。我建议你拿到这个实例后先按原样跑通然后做两件“破坏性改造”第一删掉手机号查询模块的代码不看参考答案自己重新写一遍完全想不起来再看源码第二把数据库里的行政区划表换成最新版看看导出、清洗、导入、替换整个流程能不能自己走通。这两个改造做完你对Android离线数据查询这套东西的掌握程度基本就超过了能照着敲代码的水平。写这篇文章时我特意把一个原则放在最后说教学实例教你的是思路和套路而不是死记代码。这个查询App的每一个模块都是Android开发里最常用的能力切片——正则校验、数据库读写、列表展示、输入容错、版本更新。把这些能力切片吃透比你机械地完成十个类似练手项目更有意义。希望这篇拆解能帮你把这个小实例真正变成自己的东西。本文还有配套的精品资源点击获取