爬取 CT 云影像的 DICOM 原始文件

发布时间：

最后更新：

很久之前我就觉得那个单张的实体胶片很不方便，不仅易损坏，信息量还很有限，那么小一点地方根本就不能展示所有的切面，而且转诊也很不便，换一家医院就得重做，不仅费钱还伤身，当然我没问过能不能提供其它载体比如光盘 U 盘之类的。

要是能建立一个医疗数据共享机制就好了，将数据保存成通用的格式，这样无论哪家医院都能读取。实际上这样的系统已经有了，叫医疗数字影像传输协定（DICOM）。

DICOM是以TCP/IP为基础的应用协定，并以TCP/IP联系各个系统。两个能接受DICOM格式的医疗仪器间，可借由DICOM格式的档案，来接收与交换影像及病人资料。

拍片 #

最近去做了个鼻子 CT，终于查出了经常头痛的原因，完事了发现报告单上有个二维码，记得去年还没这东西。

reportreport

扫了进去一个叫云影像网站，里头能查看诊断报告和在线阅片，其中阅片的页面张这样：

云影像云影像

看这瞎眼的配色、还有按钮的边距，好像是十八层转包给一个培训班做出来的，正好网站名字也叫青鸟，不会是什么北大青鸟吧……

不过网页再怎么垃圾，也比那一张胶片好，至少所有断层都能看到，通过滚动鼠标还能连续切换，再也不怕找不到位置了。

把它的功能都试了一遍后我发现没有下载，也不知道是不是故意的，让你非使用他的破网站不可。但重要的资料必须自己保存，首先不能断定他这网站能永远活着，万一哪天倒闭了，或者超过了存储限定日期，那再想看就没辙了。另外阅片软件还有很多，某些拥有 3D 重建和着色功能我想试试。

总之它没提供下载，咱就自己爬。

开爬 #

首先 F12 分析一下网络传输情况，一眼就看到个 Socket.io，再瞅瞅其它请求并没有大量图片或 DICOM 之类的响应，肯定是用的 WebSocket 传的没跑了。

网络请求网络请求 websocketwebsocket

虽然没用过 Socket.io，但请求格式基本上就是 JSON，很容易就分析出下载流程：

  1. 请求/socket.io/?EIO=3&transport=polling&t=随机获取一个 sid。
  2. 创建 WebSocket /socket.io/?EIO=3&transport=websocket&sid=${sid}，Cookie 中要带上io=${sid}。
  3. 发送2probe，服务端回复3probe
  4. 发送5
  5. 发送sendMessage请求，带上内容 { type: "saveC", hospital_id, study, password }，其中hospital_id, study, password 分别对应 URL 里的三个参数http://qr.szjudianyun.com/qingniao/?a=<hospital_id>&b=<study>&c=<password>
  6. 从响应中找到 series 和 series_dicom_number 分别是序列 ID 列表，以及每个序列的图像数。
  7. 再发sendMessage请求，仍然带上 URL 里的hospital_id跟study，另加series和series_in表示序列 ID 和要下载第几张，其它还有些参数都是常量。
  8. 每次请求图像都有两个回复，一个 JSON 的没用忽略，另一个就是 DICOM 文件了，依靠 128-132 位为"DICM"很容易判断。
  9. 遍历 series 和 series_in，重复 7-8 直到所有图都下完，最后的 difyfilm 不知道是什么就跳过了。

爬完一共才 42.3 MB，最长的序列 128 张，1mm 层间距，看来副鼻窦 CT 扫描量还是很小的。

阅片 #

下了个 RadiAnt，直接选择打开文件夹，里头的文件就全导入进去了。比起在线的那个垃圾浏览器，专用的软件功能就是多。

3D MPR3D MPR

整个序列

可以看到鼻中隔偏得很厉害，还有棘突阻碍空气流通，难怪后头的鼻窦炎症一直下不去。而且鼻子也有点歪我一直都没察觉。

中隔偏曲这事起源于我小学，某天放学后突然魔怔，双手各撑一个课桌前后荡，就跟老头玩双杠一样，然后桌子就倒了，我直接摔了个脸朝地。当时鼻子出了好多血，从此之后抠鼻的时候就能感到左侧比右侧更狭窄，但一直也没什么大问题就没管了。

其它的问题还有：

3D 建模

三维建模没有想象中的有趣，也看不到多少的细节。最后那张脸吓死我了，真他妈丑！

●
评论加载中