# mirth

**Repository Path**: chen-xueyuan/mirth

## Basic Information

- **Project Name**: mirth
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-10-23
- **Last Updated**: 2026-10-23

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 源码分析 & 迁移到 Mirth Connect：交付说明

## 你给的程序是什么

`源码 - 副本.rar` 里是一个 **VB6 桌面后台程序**（`工程1.vbp` → `批量生成QRURL.exe`），它不是一个 HTTP 接口服务，而是：

1. 每 10 秒查一次 Oracle 视图 `QRURLQUERY`（`SELECT RIS_NO FROM QRURLQUERY where rownum < 101`）；
2. 对每条检查：取 `EXAM_MASTER.patient_local_id`，用 **AES-128-CBC/PKCS7**（key/iv 写死在代码里）生成
   `https://ftimage.jnkyzx.cn/QR/index.html?accessionNumber=<32位大写HEX>&hsCode=05319713&date=yyyyMMdd`，
   并 `UPDATE EXAM_MASTER SET QRURL=...`；
3. 再取患者/报告信息拼 `mrInDicom` XML，用 **SM4-ECB/零填充 + Base64** 加密后套上 `<message>` 信封；
4. 用 `WinHttp` POST 到 `http://11.0.0.132:7003/tda_accept/acceptXML/mrInterface`，解析返回的 `msg_rspcode`。

> 关键发现：**源码里报文体被写死成了一条 2024-03-26 的历史报文**（`Form1.frm` 第 615 行覆盖了刚算出的密文），
> 而且它依赖的 `ReportContent.dll` COM 组件在本机已不可用（日志里 `对象不支持该属性或方法`）。
> 迁移到 Mirth 后这两个问题都会消失。

两种加密的精确参数（已用旧程序里残留的**真实数据**做过闭环验证：密文能解出明文、明文能加回同一密文）：

| 用途 | 算法 | 参数 | 输入 → 输出 |
|---|---|---|---|
| 二维码 URL | AES-128-CBC / PKCS7 | key `fbda6z8uvynw042g`、iv `mw059oqpztjbkh7n`（ASCII） | `patient_local_id` → 32 位大写 HEX |
| 平台报文 | SM4-ECB / 零填充 | key `8BC1B01E4709E19AF7D92BC8616D5708`（hex） | XML 的 UTF-8 字节 → Base64 |

想先了解细节：见 [`01-源码分析报告.md`](01-源码分析报告.md)。

## 迁移结果（一个 Mirth 通道即可取代旧程序）

```
QRURL-影像上传
├─ Source:  Database Reader (Oracle)，10 秒轮询，SQL 与旧程序一致
│    └─ JS 转换器：查库 → AES 生成二维码 URL → 回写 EXAM_MASTER.QRURL
│                  → 组 mrInDicom XML → SM4+Base64 → <message> 信封
└─ Destination: HTTP Sender，POST 到医联体平台
     └─ 响应转换器：msg_rspcode=0 成功；否则抛错进错误队列
```

服务器上只跑 Mirth 服务，**不再需要运行 `批量生成QRURL.exe`，也不再需要 `ReportContent.dll`**。
加密算法在 Mirth 里用 JDK 自带 JCE（AES）+ 纯 JavaScript（SM4）实现，不装任何第三方组件。

## 怎么用（3 步）

1. 打开 [`mirth/QRURL-Sender.xml`](mirth/QRURL-Sender.xml)；
2. 按 [`02-Mirth迁移部署说明.md`](02-Mirth迁移部署说明.md) 第四节，把 3 处配置改成现场值
   （Oracle 地址/账号、脚本里的 `QRURL_DB`、平台 HTTP 地址）；
3. Mirth Administrator → Channels → **Import Channel** 导入 → **Deploy**，停掉旧 exe。

详细步骤、上线切换、排障、回滚、安全提示都在 [`02-Mirth迁移部署说明.md`](02-Mirth迁移部署说明.md)。

## 交付文件

| 路径 | 说明 |
|---|---|
| [`mirth/QRURL-Sender.xml`](mirth/QRURL-Sender.xml) | **要导入 Mirth 的通道文件**（含全部脚本，严格 UTF-8） |
| [`mirth/src/QRURL_Lib.js`](mirth/src/QRURL_Lib.js) | AES / SM4 / Base64 / XML 组包库（纯 JS + JCE） |
| [`mirth/src/QRURL_SourceTransformer.js`](mirth/src/QRURL_SourceTransformer.js) | 源转换器主流程 |
| [`mirth/src/QRURL_ResponseTransformer.js`](mirth/src/QRURL_ResponseTransformer.js) | 平台响应解析 |
| [`mirth/src/BuildQRURLChannel.java`](mirth/src/BuildQRURLChannel.java) | 用 Mirth 官方模型类生成通道 XML 的工具 |
| [`test/test_vectors.json`](test/test_vectors.json) | 加密测试向量（来自旧程序真实报文） |
| [`test/test_node.js`](test/test_node.js) | Node 回归测试（`node test_node.js`，10 项全通过） |
| [`test/test_in_mirth.js`](test/test_in_mirth.js) | 在 Mirth 里 3 分钟自检加密是否一致 |
| [`01-源码分析报告.md`](01-源码分析报告.md) | 旧程序逐行逻辑、加密参数推导过程、发现的问题 |
| [`02-Mirth迁移部署说明.md`](02-Mirth迁移部署说明.md) | 部署/配置/切换/排障/回滚/安全 |

## 已经验证到什么程度

用官方 `mirthconnect-3.9.0.b2526-windows-x64.zip` + JRE 8 在本机完整起了一套 Mirth 3.9.0：

- ✅ 通道 XML 导入成功（REST `POST /api/channels` / `PUT ...?override=true` → `{"boolean":true}`）；
  服务器导出的通道与交付文件（去掉 XML 声明与 exportData 空节点后）**逐行 0 差异**，脚本 20011 字符完全一致、中文无损；
- ✅ 在 Mirth 自带 Rhino 1.7.9 里：AES 输出 `09FE810B94BB78C2CF45CC76D4DD97C1`、SM4 输出与真实报文 Base64 完全一致；
- ✅ 源转换器里 `DatabaseConnectionFactory` 建连接、`prepareStatement/executeQuery/close` 正常；
- ✅ 源转换器末尾 `msg = "任意字符串"` 会原样成为 HTTP 请求体；
- ✅ 响应转换器：`msg_rspcode=0` 记成功，`01` 抛异常使消息进入 ERROR。

唯一没能在本机做的是“连真实 Oracle + 真实平台”的端到端跑通（本机没有那套库/网络），
所以上线前请按部署文档第五节先小流量观察 Dashboard / Messages。