本文经授权转自公众号CSDN（ID：CSDNnews）
整理 | 郑丽媛
上周，科技媒体 ViewfromtheWing 报道称，美国三大航空公司（联合航空，达美航空及美国航空）遇到了一个看似微不足道、实则触及了航空业核心系统的问题：四位数字的航班号即将耗尽。
通常情况下，航空公司会使用四位数字来标识航班号。因此理论上来说，每个航空公司可以拥有高达 9999 个航班号（不存在 0 号航班）。这个数字看似非常充足，但随着航空业的合并与扩张，以及航空公司之间的代码共享，这一限制正在迅速逼近。
“航空公司能用的航班号越来越少，但他们也不知该如何是好……”
1、沿用 60+ 年前系统，4 位数字航班号即将耗尽
据了解，美国航空公司所使用的系统起源于 20 世纪 60 年代，至今已使用了 60 多年，能为每个航班分配一个唯一的标识符。出于存储和处理的原因，系统为了节约数据大小，用前 2 个字母代表航空公司，后 4 位数字代表航班号。
最初，这一系统足以应对航空公司的需求。然而，随着航空公司规模的扩大和航班数量的增加，该系统的局限性逐渐显现。例如，美国航空公司每天运营约 6700 个航班，距离 9999 个航班编号的上限已经不远。此外，代码共享也进一步增加了对航班编号的需求。
代码共享是航空公司之间的一种合作方式，即通过共享航班编号，合作伙伴航空公司可以销售由另一家公司运营的航班。例如，美国航空公司希望销售从多哈飞往印度和巴基斯坦城市的航班，而这些航班其实由其他航空公司运营。结果就是，目前美国航空公司、达美航空公司和联合航空公司等大型航空公司纷纷面临航班编号耗尽的问题。
在最近的一次美国航空员工会议上，这个问题被明确提出。一名 IT 部门的工作人员问：“我们的航班号快不够用了。我们是否考虑使用五位数或其他解决方法？”美国航空公司的网络规划高级副总裁 Brian Znotins 回答了这个问题，并解释了他们面临的挑战。
2、从四位到五位，系统升级的挑战
从技术层面来看，要在现有系统上增加第五位数字，看似简单，实际上却面临诸多挑战和极其复杂的工作——正如 Brian Znotins 所说，可将这个问题视作当年“千禧虫”的难度。
首先，现有的航空管理系统是一个庞大的综合体，包括预订系统、航班调度系统、地面服务系统等，这些系统彼此紧密连接，共同运作。任何对航班编号系统的改动，都会涉及到对整个航空管理系统的升级和调整。其次，这样的升级不仅需要巨大的技术投入，还需要大量的时间和人力资源，来确保系统在过渡期间的平稳运行。
更复杂的是，这一问题不仅仅是美国航空公司一家面临的挑战。达美航空公司和联合航空公司等大型航空公司同样面临航班编号耗尽的问题。全球范围内，许多航空公司也使用类似的系统，因此，任何系统升级都需要行业内的广泛合作与协调。
3、引起了部分开发者的关注
当前，美国航空公司已经采取了一些措施来应对航班号用尽的问题。例如，他们会运行转机航班，并采用所谓的“往返航班号”，即去程航班和回程航班使用相同的航班号，以此来节省航班号。此外，美国航空还在今年四月份调整了航班号，主线航班的编号从原来的 1 到 2999 扩展到了 3139。
不过此举也并非长久之计，因此美国航空公司 CEO Robert Isom 在回答关于航班号限制的问题时，也表达了自己的看法：“我们的目标是把规模变得更大，因此未来让我们会把这作为一项项目来推进。”
对于四位数字的航班号即将耗尽这件事，许多网友也对此十分关注。有人质疑代码共享航班的操作：“航空公司为什么要为代码共享航班单独设置航班号，为什么不在预订时使用运营航空公司的航班号呢？在我看来，这只徒增乘客的困惑。”
另外，也有不少开发者分享了他们的类似经验和相关建议：
“多年前，我在一家交易大厅工作。 传统的交易系统（基于 X Windows/Solaris/C++）最初是在市场交易量较低的情况下编写的，因此不能有超过 10000 个订单（由于订单 ID 字段的大小限制）。
2000 年代末，随着交易量的增加，我们也曾有过订单 ID 用完的危险。解决办法是什么呢？即使每周只有 5 天进行交易，也要让系统一周 7 天都生成订单 ID，这样我们就可以从周六‘借用’订单 ID。”
“显然，后续的解决方案是使用八组十六进制数字，每组四位，用冒号隔开。更重要的是，建议给三家公司其他未使用的前缀（如 D* U* 和 A*），让它们在代码共享航班上使用，这应该是最简单的解决方案了。”
参考链接：
https://viewfromthewing.com/airlines-are-running-out-of-flight-numbers-and-they-dont-know-what-to-do-about-it/
https://news.ycombinator.com/item?id=41155462
本文转自公众号“CSDN”，ID：CSDNnews
---END---
