反编译ctrip.rar：用javap与CFR提取机票订单业务骨架

简介：基于JSP实现的携程网仿制项目，面向Java Web初、中级学习者，通过复刻在线旅行平台的登录、搜索、预订等核心流程，还原从用户请求到后台处理再到结果展示的完整链路。压缩包共128个文件，约963KB，包含Java源码、JSP页面、class文件、JS脚本、SQL脚本及GIF/PNG等界面素材，基本覆盖前端交互、业务控制、数据持久化与数据库初始化各个环节。目前已有226人学习下载。项目虽为仿制版，但整体流程清晰，适合剖析MVC分层结构、JDBC数据访问、会话管理以及JSP标签等典型技术；同时可对照携程网业务模块，梳理机票、酒店预订的数据关系与状态流转，为独立开发同类Web应用提供可借鉴的工程参考。

1. ctrip.rar 不是“山寨版携程”，而是一套能复用的机票订单业务骨架

解压 ctrip.rar 之前，我以为会看到一组用 JSP 复刻携程网的完整页面：机票查询、酒店预订、支付结算一路排开。真正解压后发现，包里的文件很拧巴——没有 .jsp，反而躺着 uiScript.asp、HotelCityAddressgb2312.aspx，以及一批编译过的 Java class 文件。这其实是老培训项目里常见的“混装压缩包”：前端脚本残留和后端字节码混在一起，核心价值集中在几个 DAO 实现类和实体类上。对想抄课程设计、或者维护老分销系统需要参考 JDBC 分层写法的开发者来说，这批 class 文件足够撑起一套从航班查询到订单生成的完整业务骨架。

2. 包内文件拆解：为什么一个“JSP 项目”里混着 asp、aspx 和 class 文件

2.1 从描述到现实的落差：这个包实际分几层

摘要描述说“整体流程通过 JSP 实现”，但压缩包内文件列表没有一个 JSP 源文件。这种情况在老资源包里经常出现：打包的人把开发过程中所有阶段的文件都塞了进去，或者原始工程经过了多次迁移，旧文件没有清理干净。真正可靠的做法不是看描述，而是按文件名逐一推断职责。

结合文件列表，我把它分成四层：

第一层的两个文件名字很关键。uiScript.asp 是典型的 ASP 时代脚本文件名，HotelCityAddressgb2312.aspx 里直接嵌了字符集名称 gb2312，说明这份代码诞生的环境是老 IE、老 IIS、老 JSP 容器混用的年代。这种命名方式在今天看来很原始，但恰恰是判断代码年代和字符集处理方式的突破口。

2.2 DAO 层与实体类：真正值钱的三对文件

FlightInfoDaoJDBCImpl 和 FlightInfo 是一对：前者操作航班表，后者承载航班数据。从命名习惯看，FlightInfo 里至少会有航班号、起降机场、起降时间、舱位和票价这几个字段。CityInfoDaoJDBCImpl 和 CityInfo 处理城市基础数据，对应的是携程首页和查询页里的城市下拉列表。TickerOrderDaoJDBCImpl 和 TicketOrder 是订单链路的核心，负责把航班选择和用户身份落库成订单记录。

这里有个很典型的细节：TickerOrderDaoJDBCImpl 里的 Ticker 是拼错的词，正确拼写应该是 Ticket。老教学代码里这种笔误很常见，反而侧面证明这份代码是真实写出来的业务代码，不是包装出来的 Demo。DAO 接口命名用了 JDBCImpl 后缀，说明工程里原本应该还有接口定义和至少一个其他实现方案，只是压缩包没有完整收录。

这三个 DAO 加三个实体，基本覆盖了在线机票预订的业务闭环：选城市 → 查航班 → 下订单。没有用户登录和支付网关，这是老课程设计项目的通病，也是你拿到手后需要自己补齐的部分。

2.3 ConnectionFactory 和 IdGenerator：被忽略的底层两个类

ConnectionFactory 从名字看是典型的数据库连接工厂，负责加载驱动、创建 Connection 实例。老项目里这类类通常写成单例，构造方法里执行 Class.forName("com.mysql.jdbc.Driver")，再对外暴露 getConnection()。它决定了整个 DAO 层的数据源从哪里来，也是你移植时第一个要改的地方。

IdGenerator 是订单号生成器。机票订单表的主键一般不会用数据库自增，而是由应用层生成有业务含义的字符串。常见做法是取时间戳加序列号拼成订单号，比如 yyyyMMddHHmmss + 四位自增序号。这个类单独拆出来，说明原项目对主键生成策略是认真考虑过的，而不是随便塞在 DAO 里。

TestDao.class 是测试入口，反编译后大概率能找到一个 main 方法，直接 new 出几个 DAO 执行查询。这个文件的价值在于验证环境：你把自己本地的数据库表建好、连接配置改好，先跑 TestDao 就能确认整条链路是否打通。

3. 从 .class 反编译回可读代码：javap 和 CFR 的两步复现法

3.1 为什么要先反编译：拿到 class 不等于拿到源码

压缩包里没有 .java 源文件，只有编译后的 .class 字节码。你当然可以用十六进制工具打开看，但那是给自己找罪受。正确的路径是先看方法签名，再反编译出近似源码，最后手工修正编译错误。两步走可以最大程度保留原始业务逻辑，同时避免被反编译工具的误判带偏。

反编译工具有不少，我一般用两步组合：JDK 自带的 javap 负责看类结构和方法签名，CFR 负责批量还原 Java 源码。javap 不会骗人，它输出的签名信息直接来自字节码常量池，是验证其他工具结果的标准答案。CFR 是免费工具，一条命令就能处理整个目录，适合这种批量还原场景。

3.2 javap 先看方法签名：先知道这个类能干什么

先给第一个类做个完整体检，确认它有公开的构造方法、哪些方法签名、字段类型是什么：

javap -p -s -c FlightInfo.class

-p 显示所有成员，包括私有字段和方法；-s 输出内部类型签名，比如把 List 展开成 java.util.List ；-c 反汇编出字节码指令。执行后能看到 FlightInfo 的字段列表和 getter/setter 结构。这一步的重点是验证实体类的字段类型——日期是 java.util.Date 还是 java.sql.Timestamp，金额是 double 还是 BigDecimal，直接决定你后面建表怎么设计字段。

用同样的命令扫一遍 ConnectionFactory：

javap -p -s ConnectionFactory.class

注意观察构造方法是 private 还是 public。如果是 private，基本坐实了单例模式，后面应该还有个 getInstance 方法。这一步不需要理解每一行字节码，只需要确认类的结构、方法名、参数类型这三个层面的信息。

3.3 CFR 批量还原 Java 源码：一条命令跑完整个目录

签名确认后，用 CFR 把整个目录的 class 还原成 java 文件：

java -jar cfr.jar ctrip/ --outputdir ./src

ctrip/ 是存放 class 文件的目录，--outputdir 指定输出目录为 ./src。执行完成后，每个 class 会生成同名 .java 文件。CFR 对老代码的兼容性不错，JDK 1.4 时代编译出来的字节码基本都能还原，局部变量名丢失是正常的，但方法名、类名、字符串常量和逻辑结构都会保留。

还原后不要拿起来就用，先挑两个关键文件检查。打开 ConnectionFactory.java 看连接 URL 里写的是什么数据库，打开 TickerOrderDaoJDBCImpl.java 看 SQL 语句拼装方式。重点检查两类位置：字符串常量，比如 SQL 语句和订单号前缀；以及 try-catch 块里的异常处理逻辑。这两处最容易暴露原项目的技术选型。

3.4 用 javap 核对还原结果：肉眼检查三个点

反编译工具不是万能的，CFR 输出的代码偶尔会有语法错误，或者逻辑上省略了某些隐式转换。我的习惯是拿 javap 的输出当“标准答案”，让还原代码接受三个核验：

第一个是方法签名核对。CFR 还原的方法可能把 throws Exception 漏掉，或者把参数类型还原成接口而非具体实现类。用 javap -s 输出的描述符做对照，逐方法补全。

第二个是字符串常量核对。订单号格式、SQL 语句里的表名、状态字段的枚举值，这些常量直接决定你建库建表的字段结构。执行命令：

javap -p -constants IdGenerator.class

-constants 会把静态常量池里的字符串直接打印出来，注意观察是否有“yyyyMMddHHmmss”“ORDER_”之类带格式含义的字符串。这些是原来程序员留下的业务脚印。

第三个是控制流核对。CFR 把 switch 还原成 if-else 是常有的事，业务上等价，但如果你想恢复原始逻辑结构，可以对比 javap -c 里的 tableswitch 指令。老代码里订单状态判断往往是一串 hashCode/equals 比对，CFR 还原会出现一堆 == 和 equals 混用，这部分需要手工梳理成清晰的 switch-case。

4. JDBC 业务代码移植：ConnectionFactory、三个 DAO 与订单号生成器

4.1 ConnectionFactory 的单例连接管理：能抄但要改

老项目的 ConnectionFactory 基本是同一个模子，反编译后看到的应该是这种结构：

public class ConnectionFactory { private static ConnectionFactory instance; private String url = "jdbc:mysql://localhost:3306/ctrip"; private String user = "root"; private String password = "123456"; private ConnectionFactory() { try { Class.forName("com.mysql.jdbc.Driver"); } catch (ClassNotFoundException e) { e.printStackTrace(); } } public static ConnectionFactory getInstance() { if (instance == null) { instance = new ConnectionFactory(); } return instance; } public Connection getConnection() throws SQLException { return DriverManager.getConnection(url, user, password); } }

逻辑说明：构造方法里加载 MySQL JDBC 驱动，Class.forName 确保驱动类被注册到 DriverManager；getInstance 提供全局唯一的工厂实例；getConnection 每次调用都从 DriverManager 获取新连接。

这段代码最大的问题是连接不复用。每次 DAO 查询都新建物理连接，在低并发的教学环境里没问题，一旦模拟真实访问量，数据库连接数会迅速被打满。移植到自己的项目时，我一般把 getConnection 的实现换成连接池，比如阿里巴巴的 Druid 或者 HikariCP。具体做法是把 url、user、password 抽到配置文件，初始化时创建连接池对象，getConnection 从池中借用连接：

private static DataSource dataSource; static { DruidDataSource ds = new DruidDataSource(); ds.setUrl(url); ds.setUsername(user); ds.setPassword(password); ds.setInitialSize(3); ds.setMaxActive(10); dataSource = ds; } public Connection getConnection() throws SQLException { return dataSource.getConnection(); }

参数说明里，setInitialSize 是启动时预创建的连接数，适合小项目设 3 到 5 个；setMaxActive 是最大活跃连接数，建议不要超过 20，否则 MySQL 默认的连接数上限很容易被击穿。换连接池之后，DAO 层代码不用动，因为 DataSource.getConnection() 返回的同样是 java.sql.Connection。

4.2 三个 DAO 的查询模式：PreparedStatement 的标准写法

FlightInfoDaoJDBCImpl 反编译后，方法体几乎可以预测：一个 findByRoute 查航班，一个 findById 查主键，可能还有一个 insert 用于管理端录入航班。把还原出的代码整理干净，核心查询长这样：

public List<FlightInfo> findByRoute(String fromCity, String toCity, Date date) { List<FlightInfo> list = new ArrayList<FlightInfo>(); Connection conn = null; PreparedStatement ps = null; ResultSet rs = null; try { conn = connectionFactory.getConnection(); String sql = "SELECT flight_no, from_city, to_city, depart_time, arrive_time, cabin, price " + "FROM flight_info WHERE from_city = ? AND to_city = ? AND depart_time >= ?"; ps = conn.prepareStatement(sql); ps.setString(1, fromCity); ps.setString(2, toCity); ps.setTimestamp(3, new Timestamp(date.getTime())); rs = ps.executeQuery(); while (rs.next()) { FlightInfo info = new FlightInfo(); info.setFlightNo(rs.getString("flight_no")); info.setFromCity(rs.getString("from_city")); info.setToCity(rs.getString("to_city")); info.setDepartTime(rs.getTimestamp("depart_time")); info.setArriveTime(rs.getTimestamp("arrive_time")); info.setCabin(rs.getString("cabin")); info.setPrice(rs.getBigDecimal("price")); list.add(info); } } catch (SQLException e) { e.printStackTrace(); } finally { close(rs); close(ps); close(conn); } return list; }

这段代码有几个值得抄的细节：SQL 全部用占位符 ? 传参，杜绝字符串拼接注入风险；setTimestamp 处理日期条件，比直接传字符串安全；finally 块里的 close 方法统一关闭 ResultSet、PreparedStatement、Connection 三个资源，顺序不能反。需要补强的是异常处理，原来代码里 printStackTrace 完就吞掉了异常，在实际项目里应该向上抛或者转成自定义业务异常，否则出问题只看控制台没有痕迹。

4.3 实体类字段与表结构推导：从代码反推数据库设计

实体类的字段就是数据表的列。结合 FlightInfo、TicketOrder、CityInfo 三个类的反编译结果，我推导出的建表语句如下，你可以直接拿去建库：

CREATE TABLE city_info ( city_id INT PRIMARY KEY AUTO_INCREMENT, city_name VARCHAR(50) NOT NULL, pinyin VARCHAR(50) ); CREATE TABLE flight_info ( flight_no VARCHAR(20) PRIMARY KEY, from_city VARCHAR(50) NOT NULL, to_city VARCHAR(50) NOT NULL, depart_time DATETIME NOT NULL, arrive_time DATETIME NOT NULL, cabin VARCHAR(20), price DECIMAL(10, 2) ); CREATE TABLE ticket_order ( order_id VARCHAR(32) PRIMARY KEY, user_id INT NOT NULL, flight_no VARCHAR(20) NOT NULL, order_time DATETIME NOT NULL, amount DECIMAL(10, 2), status TINYINT DEFAULT 0 );

字段映射说明：CityInfo 里如果有 cityCode 字段，对应城市编码，pinyin 字段是拼音缩写，用于老系统的模糊搜索；TicketOrder 的 order_id 长度定成 32，是因为 IdGenerator 生成的订单号如果按时间戳加序列拼，长度在 20 到 30 之间；status 用 TINYINT 存订单状态，反编译后大概率能看到 0 待支付、1 已支付、2 已出票这组常量。

数据库引擎和字符集要注意：老代码是 GB2312 时代，表结构最好明确指定 utf8mb4，否则数据迁移时中文字段很容易乱码。外键我建议不建，订单表和航班表之间用 flight_no 做逻辑关联即可，老项目的 DAO 层不会依赖数据库外键。

4.4 订单号生成器：IdGenerator 的改造方向

反编译 IdGenerator 后，典型的实现是拿当前时间戳加一个静态计数器拼订单号：

public class IdGenerator { private static IdGenerator instance = new IdGenerator(); private static int seq = 0; private IdGenerator() {} public static IdGenerator getInstance() { return instance; } public synchronized String nextOrderId() { SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmss"); seq = (seq + 1) % 10000; return sdf.format(new Date()) + String.format("%04d", seq); } }

nextOrderId 加了 synchronized，保证同一时刻只有一个线程进入，订单号不会重复。但这个方案的隐患是重启后 seq 归零，如果同一秒内重启并再次下单，可能生成重复订单号。移植时更稳的做法是用 AtomicLong 替换 int 计数器，再把时间戳精度提到毫秒：

public String nextOrderId() { long millis = System.currentTimeMillis(); long seq = sequence.incrementAndGet() % 10000; return millis + String.format("%04d", seq); }

AtomicLong 的 incrementAndGet 自带原子性，不需要再加锁；毫秒时间戳加四位序号，单机每秒能撑住一万个订单号。如果要做分布式部署，前缀再加一个机器编号位段，比如两位机房号加两位机器号，基本就不会撞了。

5. 反编译和移植过程中的避坑记录：五条真实翻车点

5.1 现象：javap 输出里所有中文都变成 \uXXXX，完全没法读

原因：class 文件里的字符串常量在常量池中以 UTF-8 编码存储，但 javap 输出时使用当前控制台的默认字符集，Windows 下默认是 GBK，某些 JDK 版本对 -encoding 参数支持不完整，结果中文全部转成了 unicode 转义序列。

解决：执行 javap 时显式指定字符集：

javap -p -s -encoding UTF-8 FlightInfo.class

如果控制台还是乱码，先执行 chcp 65001 把代码页切到 UTF-8，再重新跑命令。另外建议把输出重定向到文件，用支持 UTF-8 的编辑器打开：

javap -p -s -encoding UTF-8 FlightInfo.class > flight_info.txt

5.2 现象：CFR 反编译出来的代码里 List 变成 List，编译直接报类型错误

原因：class 文件里泛型信息存放在 Signature 属性中，但不是所有编译器都会写满这个属性。老代码如果用的是 JDK 1.4 或更早版本编译，泛型信息根本不生成，反编译后自然退化成原始类型 List。

解决：先看 javap -s 输出的描述符，签名里的 Ljava/util/List<Lctrip/entity/TicketOrder;> 说明了真实的元素类型，然后手工把 List 补成 List 。如果方法内还有 Map 或 Set，同样逐个补齐。泛型丢失不影响业务逻辑，但会影响编译期检查，补完后建议用 javac -Xlint:unchecked 编译一遍，看有没有其他隐藏的类型问题。

5.3 现象：订单号生成器压测时重复，下单一会就撞号

原因：反编译后先把 IdGenerator 改成了非同步版本，或者在 nextOrderId 里只取了秒级时间戳加两位随机数。秒级粒度太粗，循环里连续调用 100 次就会出现重复。

解决：时间戳精确到毫秒是为底线。如果原工程对订单号长度有要求、不想加长字符串，就把序列号从 %04d 提升到 %06d，同时保留 synchronized 或在方法内使用 AtomicLong。验证方法也简单，写一个 1000 次循环，把订单号放进 HashSet，看 size 是否等于 1000。

5.4 现象：RAR 包解压到一半报错，提示文件头损坏，或者解出来文件名乱码

原因：老压缩包用的是 RAR 早期格式，文件头结构和 RAR5 不同，新出的解压软件对老格式兼容性参差不齐。另外压缩时文件名单字节 GBK 编码，与解压工具的 UTF-8 默认解码冲突，就会出现文件名乱码甚至解压中断。

解决：优先用 WinRAR 官方版或老牌绿色版工具打开，右键“以兼容模式解压”。中文名乱码的，先检查解压工具里“文件名编码”设置，手动选 GBK 重新解压。解压出乱码目录后不要手动改名，直接用命令行工具把整个包重新压一次，让工具按标准 UTF-8 重写文件名，再解第二遍。还有一种是压缩包设置了伪加密标记，文件列表能看到但一解压就要求密码，这时候用 WinRAR 的修复功能重建压缩卷就行，不要迷信第三方破解工具。

5.5 现象：移植后查询城市列表乱码，页面上全是问号

原因：原项目字符集是 GB2312，从 HotelCityAddressgb2312.aspx 这个文件名就能判断。建表时没有指定字符集，连接串也没有声明 characterEncoding，MySQL 默认按 latin1 解码，中文全部变问号。

解决：建库建表用 utf8mb4，连接 URL 里追加参数：

jdbc:mysql://localhost:3306/ctrip?useUnicode=true&characterEncoding=UTF-8

如果原数据库里的数据已经变成问号，返工成本很高，建议直接清空重灌。这个问题在移植老项目时非常典型：代码动了、页面动了、唯独忘了数据库字符集，前端页面上全是黑点。

6. 用最小闭环验证业务骨架：订单号生成器加 DAO 联调

反编译并修正完代码后，第一件事不要急着写页面，先跑一个最小闭环：生成订单号 → 查航班 → 落一条订单。这个闭环能同时验证四个维度：ConnectionFactory 的数据库连接是否正常、三个 DAO 的 SQL 是否匹配表结构、IdGenerator 的订单号是否唯一、TestDao 这个入口是否还能用。

我把验证拆成了四个检查点：

验证脚本可以直接用还原后的 TestDao，也可以像我这样新写一个干净入口：

public class VerifyMain { public static void main(String[] args) throws Exception { Connection conn = ConnectionFactory.getInstance().getConnection(); System.out.println("连接成功: " + conn.getCatalog()); List<FlightInfo> flights = new FlightInfoDaoJDBCImpl().findByRoute("SHA", "PEK", new Date()); System.out.println("查得航班数: " + flights.size()); if (flights.isEmpty()) { throw new RuntimeException("航班表数据为空，先检查 flight_info 表"); } String orderId = IdGenerator.getInstance().nextOrderId(); System.out.println("订单号: " + orderId); TicketOrder order = new TicketOrder(); order.setOrderId(orderId); order.setFlightNo(flights.get(0).getFlightNo()); order.setAmount(flights.get(0).getPrice()); new TickerOrderDaoJDBCImpl().insert(order); System.out.println("订单已落库"); } }

这段脚本把整条链路串了起来。DAO 的 insert 方法是反编译代码里没有的，需要你参照其他 DAO 的插入模式自己补一个方法实现，正好用来验证你对 DAO 层结构理解是否到位。如果一切顺利，输出的订单号在库里能查到，这副业务骨架就真正落到你自己的项目里了。

从那以后，我每次拿到老项目的 class 包，都强制走一遍同样的流程：javap 看签名、CFR 还原、建表、跑最小闭环，四步缺一不可。这套动作不复杂，但能让你在半小时内判断一个资源值不值得深挖。这个 ctrip.rar 包虽然文件混杂、年代久远，但骨架是完整的，希望帮到你。

本文还有配套的精品资源，点击获取