机场三字代码表全解析：从编码逻辑到离线查询工具

简介面向航空、旅游与出行服务领域从业者以及需要理解国际机场代码的初学者这份「机场三字代码表」以IATA标准为框架系统梳理三字代码的组成、分类、应用场景、命名规则以及标准化发展和调整方向。通过北京首都PEK、上海浦东PVG、广州CAN等实例帮助读者建立从代码到城市与机场的快速映射能力避免在查询和票务处理时混淆相近代码。资源打包为1个docx文档压缩包仅22KB内容精炼但信息密度高适合工作中随时查阅或打印备查。目前已有929人浏览/学习说明该资料在同类参考工具中具有实用价值。文档在知识点解析之外还附有一份覆盖国内大量机场的三字代码与城市对照表可直接用于航班查询、值机引导、机场管理等场景也可作为日常记忆练习与行业培训的基础素材。1. 机场三字代码表一本能直接对账的 IATA 编码册做航班数据的人手里必须有一份能直接对账的机场三字代码表。我拆过几个 OTA 和航司周边系统每次拿到新的票面数据或机场列表第一件事就是把三字码字段拉出来和代码表比对因为同一城市在不同数据源里可能挂着完全不同的码BJS、PEK、PKX 都能跟“北京”沾边但业务含义差出十万八千里。这份资源收了一百四十多个中国机场含部分周边通航点的 IATA 三字码每个码带中文城市名适合做票面解析、数据清洗、机场选项渲染和测试数据构造。它不是科普资料是能直接落进工程里的数据底表。下面按我的拆解习惯从编码逻辑讲到建表实操再到踩坑记录最后给一个离线查询工具。2. 三字码的命名逻辑城市码、机场码与拼音规则的例外刚接触三字码的人很容易把它理解成“城市名拼音首字母”北京应该叫 BJS上海应该叫 SHA广州应该叫 GZ。真把表摊开对一遍发现完全不是这么回事。2.1 城市码和机场码是两回事BJS/PEK 的双层结构IATA 实际维护着两套既有重叠、又不完全相同的代码体系。一套是城市代码表示“这个城市是一个航空服务点”比如 BJS 代表北京这座城市、SHA 代表上海这座城市另一套是机场代码表示“具体的物理机场”比如 PEK 是北京首都国际机场PVG 是上海浦东国际机场。这份资源里两类代码都收了。开头就能看到“BJS 北京”后面又跟着“PEK 北京首都机场”这种排版很容易让人误以为是重复数据。实际上 BJS 是城市层的查询码PEK 是机场层的执行码。搜索航班时用户输入“北京”系统先把城市码 BJS 展开成 PEK 和 PKX 两个具体机场码再分别去查运价和座位而出票、值机、行李分拣这些环节只认 PEK/PKX 这种机场码。我在实际项目里的一个习惯性做法是代码表里永远保留三列城市名、城市码、机场码而不是简单地把“码城市名”拍平。因为只存城市码出票阶段拿不到具体机场只存机场码搜索阶段又覆盖不了“北京上海”这种城市级行程。两套都保留才能在不同环节各取所需。2.2 拼音规则只覆盖了一部分PEK、CAN、TSN 这些例外从哪来很多三字码确实能靠拼音对上比如 CTU 成都、HRB 哈尔滨、KMG 昆明首字母和城市名拼音完全一致。但这套规律只适用于近三十年新建或更名的机场老牌机场的代码大多继承自旧地名转写。PEK 来自北京旧译名 PekingCAN 来自广州旧译名 CantonTSN 来自天津旧译名 TientsinSWA 来自汕头旧译名 SwatowURC 来自乌鲁木齐早期转写 UrumchiKHG 来自喀什的惯用拼法 Kashgar。这些代码进入 IATA 体系时用的是当时航空电报和导航资料里的标准拼写后来汉语拼音成为国内标准但 IATA 没有跟着改码。这就带来两个工程启示。第一不要试图通过“拼音转码”算法在运行时动态生成三字码风险极大。第二代码表里的每个字母并不能拆出独立含义网上流传的“P 代表所在城市、E 代表英文名、K 代表地区”属于事后附会设计数据字段时不必为这种解释留结构。代码城市来源拼写与拼音首字母PEK北京PekingBJJ不一致CAN广州CantonGZ不一致TSN天津TientsinTJN不一致SWA汕头SwatowST不一致URC乌鲁木齐UrumchiWLMQ不一致KHG喀什KashgarKS不一致CTU成都拼音一致HRB哈尔滨拼音一致这张表里的前六行就是踩坑高发区。凡是拿拼音首字母去反推代码的基本都会在这里翻车。2.3 先做“码-市-场”三级映射字段这样设计才不会翻车基于上面的逻辑我拿到这份资源后不会直接把它当最终表用而是先做一次结构映射拆成四个核心字段city_name中文城市名用于展示和模糊搜索city_codeIATA 城市代码可能为空表示该城市是否有独立城市码airport_name具体机场的备注名airport_codeIATA 机场三字码业务主键以“北京”为例映射出来是城市名: 北京 城市码: BJS 机场1: 北京首都机场 - PEK 机场2: 北京大兴机场 - PKX再以“上海”为例城市名: 上海 城市码: SHA 机场1: 上海虹桥机场 - SHA 机场2: 上海浦东机场 - PVG注意上海这里有个特例城市码恰好和虹桥机场码一样都是 SHA。很多人在做数据时会把“SHA”误认为只是城市码导致虹桥和浦东分不清也有的人会把它误认为只是虹桥机场码导致上海的城市级搜索直接缺失。这种“城市码与机场码重合”的情况在各城市里不算罕见处理方式是显式保留一个层级字段标记这一行是 city 还是 airport而不是靠代码是否相等去猜。这张三级映射表就是后面所有查询、校验和业务拼接的地基。地基打歪了后面每个环节都要返工。3. 解析与建表把文本代码表变成可查询的结构化数据原始资源长什么样长这样AAT阿勒泰 HAK海口 LUM德宏芒市 WEH威海 WUH武汉 CTU成都 ...整份是一长串“三个大写字母 中文名”的拼排文本。粘贴到 Excel 里都还算整齐但直接落到接口或数据库里没法用。第一步是解析。3.1 用正则把“码中文名”拆开我的做法是写个小脚本用正则一次性把“码”和“中文名”拆成二元组。import re raw AAT阿勒泰 HAK海口 LUM德宏芒市 WEH威海 WUH武汉 CTU成都 CKG重庆 CSX长沙 HGH杭州 # 先把连续空白统一成半角空格防止全角空格干扰匹配 raw re.sub(r\s, , raw) # 三位大写字母 中文名允许出现斜杠和括号 pattern re.compile(r([A-Z]{3})([\u4e00-\u9fa5/()])) rows pattern.findall(raw) print(f解析出 {len(rows)} 条记录) for code, name in rows[:6]: print(code, name)正则里[A-Z]{3}匹配三字码[\u4e00-\u9fa5/()]匹配中文名。为什么要把“/”和全角括号放进字符集因为表里有“长沙/黄花”“德宏芒市”这种带斜杠或说明性字词的写法不放进字符集匹配到“长沙”就停了后面的“/黄花”会变成孤立文本。findall会返回所有符合模式的元组列表。跑完这一步得到的 rows 就是干净的(code, name)对。如果你用的是完整资源文本解析出来的行数应当在一百四十以上如果偏少优先检查是否粘贴时丢了换行符或全角空格。3.2 清洗入库去重、补列、标记历史状态解析出来的二维表还不能直接进库。第二步是清洗主要做四件事。第一件是去重。这份资源里“CSX 长沙”和“HHA 长沙/黄花”同时存在两者都指向长沙但一个偏历史来源一个是现行标准码。直接去重会误删有效信息我的做法是保留 CSX 为主记录HHA 降级进别名表。第二件是补 city_code 字段。解析结果里只有机场码没有城市码需要按城市维度人工归并把 BJS、PEK、PKX 归到北京名下。第三件是补 status 字段我一般用三个状态active 表示在用机场historical 表示已停用或已更名的旧码overseas 表示非中国大陆的通航点。这份表里的 ALA 阿拉木图、LIA 梁平、LZD 兰州东都应该在清洗时打上非 active 的标签。第四件是统一中文名格式。资源里有“德宏芒市”“长沙/黄花”“襄樊”这种带历史地名的写法落到线上前建议按民航局公开的机场名称做一次规范化避免同一个机场在票面、展示、报表三处出现三个名字。清洗完的落地结构我一般会建成这样CREATE TABLE airport_code ( id INTEGER PRIMARY KEY, airport_code TEXT NOT NULL UNIQUE, -- IATA 三字码 airport_name TEXT NOT NULL, -- 规范中文名 city_name TEXT NOT NULL, -- 所属城市 city_code TEXT, -- IATA 城市码可能为空 status TEXT NOT NULL DEFAULT active, -- active / historical / overseas alias TEXT -- 别名或历史码逗号分隔 );这里最重要的一条规定是airport_code必须唯一。三字码在 IATA 体系里是全球唯一的如果同一份数据里出现重复说明清洗环节有遗漏。3.3 增量更新用脚本比对新旧两版代码表机场三字码不是一成不变的我遇到过几次机场更名后代码变化的情况。所以代码表要能增量更新不能每次手动覆盖。我一般会保留上一个版本跑一次比对输出新增、失效、变更三组结果。old {PEK: 北京首都, PVG: 上海浦东, CSX: 长沙黄花} new {PEK: 北京首都, PKX: 北京大兴, CSX: 长沙黄花} # 找出新增的代码 added set(new) - set(old) # 找出失效的代码 removed set(old) - set(new) print(新增:, {k: new[k] for k in added}) print(失效:, {k: old[k] for k in removed}) # 找出名称发生变化的代码 changed { k for k in set(old) set(new) if old[k] ! new[k] } print(变更:, {k: (old[k], new[k]) for k in changed})这段脚本的思路很直接集合求差集得到新增和失效遍历交集得到名称变更。跑完看输出人工确认一遍再合入主表比直接拿新版覆盖稳得多。4. 避坑清单这些机场代码最容易读错、用错下面几个坑是我在真实项目里踩过或帮别人擦过屁股的全部按“现象 → 原因 → 解决”写可以直接对照排查。4.1 同一城市出现两个码长沙到底用 CSX 还是 HHA现象代码表里既有“CSX 长沙”又有“HHA 长沙/黄花”。新同事拿 HHA 建了航班缓存表结果中航信接口返回的航班一个都对不上。原因CSX 是长沙黄花国际机场现行有效的 IATA 代码HHA 是历史遗留代码只出现在部分老数据源和旧版航图里。三字码的唯一性只针对“当时”机场更名或迁建后旧码会继续在旧数据里游荡。解决主键用 CSXHHA 只能出现在 alias 字段里。查询入口做成“输入 HHA 也能命中长沙”但落库和出票必须统一转成 CSX。4.2 城市码当机场码用BJS 查不到航班现象用户选了“北京”作为出发地系统拿 BJS 去请求航班接口返回空列表换成 PEK 立刻有数据。原因BJS 是城市码不是机场码。大多数航班运价和动态数据都挂在具体机场码维度发布城市码在运价接口里通常不直接支持查询。解决在查询层做一次“城市码展开”把 BJS 映射成 PEK 和 PKX 两条请求再合并结果。展开逻辑要放在服务端不要依赖客户端自己处理。4.3 表里混进了境外和历史代码ALA、LIA、LZD 怎么办现象代码表里出现“ALA 阿拉木图”“LIA 梁平”“LZD 兰州东”有人觉得数据错了直接删掉。原因这份资源覆盖范围不只是中国大陆还包含周边通航点和历史通用机场。梁平机场已经基本不承担民航运输兰州东也属于历史场站但这类代码在历史票证和备降记录里仍然会出现。解决不要删打上 status 标记再决定是否进入线上环境。线上查询用WHERE status active过滤历史数据解析单独保留一张全量表。4.4 同城双场分配错误上海 SHA/PVG 的映射不能只看城市名现象拼接“上海到北京”行程时系统把上海统一映射成 SHA浦东 PVG 出发的航段被错误地挂到虹桥机场名下。原因SHA 既是上海城市码又是虹桥机场码很容易让开发者在做映射时忽略机场维度直接把城市名和 SHA 画上等号。解决凡是涉及具体航段、值机、行李的环节一律使用机场码城市码只允许出现在“城市选择”阶段的搜索逻辑里。代码表里为上海保留两条 active 记录SHA 和 PVG 分别对应虹桥和浦东城市码字段单独存 SHA。5. 业务落地联程拼接、备降场和离港数据里的代码处理把三字码表接进真实系统后有三个场景最容易暴露设计缺陷我逐个说清楚。5.1 联程票拼接同一个城市两段航程怎么选码旅客搜“北京到昆明”系统拿城市码找到 BJS-KMG出票时拆成 PEK-KMG 的具体航段。但如果旅客从北京大兴出发联程方案里塞进去 PEK 起飞的航班值机时就会出问题。常见做法是搜索阶段用城市码圈定候选集到选班阶段立即把航段的起降机场码展开统一按“机场码 航班号 日期”去请求运价。对同一城市有两个机场的航点候选集不能合并成一条要按机场分别显示。如果乘客对机场有明确偏好再按机场码做二次过滤。我在做这类功能时习惯在缓存 key 里直接带机场码比如flight_search:PEK:KMG:20240815而不是flight_search:BJS:KMG。因为城市码是集合概念两个机场的运价和余票完全独立合在一个 key 里很容易串数据。5.2 备降场必须锁定“机场码”不能退回城市码航班因天气备降时签派系统写的备降场永远是具体机场码比如首都机场进近天气不好备降到石家庄正定记录里写的是 SJW而不是石家庄城市码。因为备降涉及停机位、加油、旅客安置全部依赖机场级的调度信息。我见过一个翻车案例某系统的备降通知模块为了“页面展示好看”把备降场转成了城市名结果同一个城市两个机场时旅客端展示的备降地和实际降落点对不上客服电话被打爆。从那以后我经手的系统都强制规定备降场字段只允许存机场码展示层要做转换必须带着航站楼和跑道信息一起转。5.3 对接离港系统和运价接口的三字码规范不管是中航信的离港前端还是 GDS 的运价接口航段识别的主键永远是“两字航司码 三字机场码 航班号 日期”。机场三字码在这个结构里是稠密字段不能为空也不能存中文。实际联调时要注意大小写。IATA 码按规范用大写但有些海外接口回传的是小写比如pek如果不做统一大写转换直接用字符串去 join 两套数据会悄悄丢行。我的做法是在建表阶段就把airport_code统一UPPER()后存入并在 ORM 层加一个校验器任何写入的代码必须先满足^[A-Z]{3}$正则。6. 把代码表做成离线查询器一个 60 行的 CLI 工具最后分享一个我常用的收尾动作把清洗好的代码表压成一个不依赖网络的命令行查询器。机场数据敏感度不高但接口偶尔抖动备一个离线工具能解决很多临时排查需求。#!/usr/bin/env python3 import argparse import sqlite3 import re DB_PATH airport.db def init_db(rows): conn sqlite3.connect(DB_PATH) conn.execute(DROP TABLE IF EXISTS airport_code) conn.execute( CREATE TABLE airport_code ( airport_code TEXT UNIQUE, airport_name TEXT, city_name TEXT, city_code TEXT, status TEXT ) ) conn.executemany( INSERT INTO airport_code VALUES (?, ?, ?, ?, ?), rows ) conn.commit() return conn def query(keyword): conn sqlite3.connect(DB_PATH) like f%{keyword.upper()}% cur conn.execute( SELECT airport_code, airport_name, city_name, city_code, status FROM airport_code WHERE airport_code LIKE ? OR city_name LIKE ? OR airport_name LIKE ?, (like, f%{keyword}%, f%{keyword}%) ) for row in cur.fetchall(): print( | .join(str(x) for x in row)) if __name__ __main__: parser argparse.ArgumentParser(description机场三字码离线查询器) parser.add_argument(keyword, help输入机场码、城市名或机场名) args parser.parse_args() query(args.keyword)用法很简单比如查杭州相关机场python airport_query.py 杭州 python airport_query.py HGH python airport_query.py 萧山三条命令分别走城市名、三字码、机场名匹配。查询逻辑里那个like参数要特别注意机场码匹配用大写keyword.upper()城市名匹配保留原始大小写这样中英文输入都能命中。如果你打算把这份资源真正用起来建议先跑一遍第 3 章的解析脚本把全量数据灌进来再做一次去重和状态标记最后落到这个 SQLite 里。我从那以后每次拿到新的机场代码表都强制走一遍“解析 → 清洗 → 增量比对 → 入库”的流程四步一步不省。航信数据接口换了一茬又一茬但三字码这张底表稳住了后面所有解析逻辑就都稳得住。希望帮到你。本文还有配套的精品资源点击获取