为何老牌 MTP 工具在 Switch 2 上全线崩溃？基于纯基线 PTP 与 IOUSBHost 的 Tethersnap 逆向导出解密

随着任天堂新一代主机 Nintendo Switch 2 的问世，许多主机玩家与视频创作者在体验完震撼的画质提升后，迅速遭遇了一盆猝不及防的冷水：

在掌机上打开“设置 → 数据管理 → 管理截图与视频 → 通过 USB 复制到电脑”（Copy to PC via USB）后，用原装全功能数据线将 Switch 2 接入 Mac，系统没有任何反应。访达（Finder）不挂载、“照片”与“图像捕捉”不识别，而在初代 Switch 时代被大家广泛倚重的跨平台工具——OpenMTP（Kalam 模式报错退出，Legacy 模式空白）、MacDroid、以及 Google 早已废弃的 Android File Transfer，在面对 Switch 2 时全部失灵暴毙。

查阅任天堂官方支持文档，得到的只有冷冰冰的一句话：“请使用支持 MTP 的操作系统；其他平台用户请自行寻找第三方 MTP 软件，任天堂不承担兼容性责任。”然而，macOS 诞生至今二十余年，官方内核从未内置过 MTP 协议栈。

老牌工具究竟卡死在哪里？Switch 2 的底层 USB 协议栈到底发生了什么变化？

独立开发者 Luminoid 开源的全新工具 Tethersnap（GitHub：Luminoid/Tethersnap）给出了教科书级的答案：它没有依赖庞大的第三方 C 动态库，而是用纯 Swift 语言直接站在 macOS 现代驱动框架 IOUSBHost 之上，精准还原了最纯粹的十条 PTP 基线指令（Picture Transfer Protocol），不仅实现了截图与 4K 视频的极速秒级导出，更揭示了真实硬件与官方协议标准之间一系列令人拍案叫绝的“工程暗坑”。

本文将以底层协议逆向与第一手调试日志为线索，深度解构 Switch 2 的通信真面目与 Tethersnap 的架构精髓。

1. 现场溯源：为什么初代 Switch 能用的工具在 Switch 2 上全灭？

在深入代码之前，我们首先需要澄清一个在消费电子领域被混淆了近二十年的概念：PTP 与 MTP 的本质区别。

很多开发者常年把 PTP 和 MTP 混为一谈，甚至不少第三方文件管理工具直接将它们封装在同一个驱动抽象下。然而，正是二者之间微妙的代际鸿沟，构成了此次 Switch 2 在 Mac 平台上集体瘫痪的根本诱因。

flowchart TD
    subgraph ProtocolEvolution ["图像与多媒体传输协议演进史"]
        direction TB
        PTP["PTP (Picture Transfer Protocol)<br/>• 诞生于 2000 年 (PIMA 15740 / ISO 15740)<br/>• 专为数码相机设计，挂载于 USB 静态图像类 (0x06:0x01:0x01)<br/>• 极简十条基线操作，元数据逐个拉取 (GetObjectInfo)"]
        
        MTP["MTP (Media Transfer Protocol)<br/>• 微软于 2004 年基于 PTP 扩展，2008 年成为 USB-IF 官方标准<br/>• 针对大容量媒体播放器与手机优化<br/>• 引入关键扩展指令：GetObjectPropList (0x9805) 一次性拉取全目录元数据"]
        
        PTP -->|微软扩展 Vendor Extension 6| MTP
    end

1.1 协议核心杀手锏：`GetObjectPropList`

在传统的 PTP 规范中，主机如果要列举一个文件夹里的内容，必须先调用 GetObjectHandles 获取该目录下所有文件的 32 位句柄数组，然后针对每一个句柄，分别发起一次 GetObjectInfo 请求以获取文件名、大小、创建时间等元数据。

对于早期的数码相机（存储卡里只有几十张照片），这种逐个往返（Round-Trip）的设计完全可以接受；但对于现代动辄存储上万张照片与长视频的 Android 手机，单次往返几毫秒的开销累加起来就是数十秒的严重卡顿。

为此，微软在 MTP 扩展中引入了 GetObjectPropList（操作码 0x9805）：主机只需发送一条指令，设备端就会将目标目录下所有子项的属性打包在一个连续的数据流中整体返回。几乎所有现存的 Android/MTP 跨平台传输软件（包括 OpenMTP、MacDroid、Android File Transfer），其目录树构建逻辑都重度绑定了 GetObjectPropList。

1.2 Switch 2 真实硬件描述符现形记

当我们在终端中通过 tethersnap probe 对连接到 Mac 的 Switch 2 进行底层 USB 描述符与 PTP 探测时，控制台吐出了这样一份令人震惊的硬件真相（序列号已脱敏）：

DeviceInfo
  Manufacturer:     Nintendo
  Model:            Nintendo Switch 2
  Version:          22.5.0
  PTP version:      1.00
  Vendor extension: 0xFFFFFFFF "nintendo.com: 1.0; "
  Operations:       0x1001 0x1002 0x1003 0x1004 0x1005 0x1006 0x1007 0x1008 0x1009 0x100A

仔细审视这份仅有 7 行的设备信息报文：

Vendor Extension 是 0xFFFFFFFF：这标志着该设备 根本没有声明微软的 MTP 厂商扩展（Extension ID 应为 6），其扩展字符串仅仅是任天堂自定义的占位符；
操作集被严格限制在最基础的十条指令：
- 0x1001: GetDeviceInfo
- 0x1002: OpenSession
- 0x1003: CloseSession
- 0x1004: GetStorageIDs
- 0x1005: GetStorageInfo
- 0x1006: GetNumObjects
- 0x1007: GetObjectHandles
- 0x1008: GetObjectInfo
- 0x1009: GetObject
- 0x100A: GetThumb
甚至不支持通用 PTP 常用指令：连数码相机普及了二十年的区间对象读取 GetPartialObject（0x101B）都被刀掉了；
全机身唯一的 MTP 痕迹：在支持的文件格式列表中，声明了 0x3801（EXIF/JPEG 截图）与 0xB982（MP4 录屏）。其中 0xB982 这个魔数来自于 MTP 的格式号段，这是全设备全协议上下唯一能找到与 MTP 沾边的地方。

真相水落石出：Nintendo Switch 2 在 USB 端完全是一个彻头彻尾的纯血 PTP 1.00 响应器（Responder），压根没有实现 MTP！

老牌 MTP 工具一旦接入，第一反应就是向主机索要 GetObjectPropList，Switch 2 底层立即返回 OperationNotSupported（操作不受支持）。缺乏降级保护机制的老旧客户端要么抛出未捕获异常当场断开（如 OpenMTP 臭名昭著的 Issue #460），要么直接陷入无限卡死或列出空目录。

2. 架构抉择：为何抛弃 libmtp，拥抱原生 IOUSBHost？

既然只要退回纯 PTP 逻辑就能通信，那 Linux 平台是如何解决的呢？

查阅开源驱动库 libmtp 的维护记录可以发现，社区早在 1.1.23 版本就将 Switch 2 录入了设备识别表：

{ "Nintendo", 0x057e, "Switch 2", 0x2061, DEVICE_FLAG_NONE }

由于将其打上了 DEVICE_FLAG_NONE（无任何特殊 Hack 标记），具备成熟回退机制的 libmtp 在 Linux 下可以丝滑降级为基线 PTP 顺利读取。

那么，在 Mac 上直接拉取 libmtp 编译一个 GUI 包装器不好吗？Tethersnap 的作者做出了极其克制且深思熟虑的架构选型：

flowchart LR
    subgraph TraditionalApproach ["方案 A：传统动态库嫁接 (淘汰)"]
        direction TB
        A1["Swift UI 界面"] --> A2["C / Objective-C 桥接层"]
        A2 --> A3["libmtp (LGPL 协议动态库)"]
        A3 --> A4["libusb 运行库"]
        A4 --> A5["macOS 底层 USB 通信"]
    end

    subgraph TethersnapApproach ["方案 B：Tethersnap 纯原生直连 (采纳)"]
        direction TB
        B1["SwiftUI 界面 + CLI"]
        B2["MTPSession / PTP 纯 Swift 状态机 (仅数百行代码)"]
        B3["Apple 原生现代 IOUSBHost 框架 (macOS 10.15+)"]
        B4["Switch 2 硬件节点 (057e:2061 / 057e:201d)"]
        
        B1 --> B2 --> B3 --> B4
    end

2.1 依赖与授权负担的彻底剥离

libmtp 采用 LGPL 开源协议，并强依赖底层 libusb。如果采用封装方案，用户必须安装庞大的环境依赖（或开发者在 App 内部打包笨重的 dylib），对于一个仅需要使用十条基础指令的场景而言，无异于“为了喝一口牛奶而建了一座牧场”。

2.2 USB 边角料异常与状态黑盒

在低层级硬件通信中，不同厂商的 USB 控制器在封包时存在极大的行为差异：有的厂商会将 PTP 容器头与数据载荷合并为一个 Bulk 传输，有的则切分为两个独立的 Transfer，更有的会产生意外的零长度包（Zero-Length Packet, ZLP）。第三方库往往会将底层异常封装为粗粒度的错误码，一旦硬件发生握手悬挂，上层根本无法感知线路上最后一个字节究竟停在哪里。

2.3 利用 macOS 系统特质实现“免驱动独占”

这也是整套架构最精妙的地方：由于苹果从未给 macOS 开发过内置的 MTP/PTP 存储驱动，当 Switch 2 插入 Mac 时，系统内核中的 IOService 不会被任何系统内置驱动抢占声明（不同于 Windows 或相机会自动挂载驱动）。

借助 Apple 在 macOS 10.15 引入的现代化用户态 USB 框架 IOUSBHost（取代了陈旧复杂的 COM 风格 IOUSBLib），一个普通的非沙盒用户态进程可以在不安装任何内核扩展（Kext）、不申请驱动签名、不提权 root 的前提下，直接独占接管 USB 接口管道（Bulk-In / Bulk-Out Pipes）！

3. 实机对抗：任天堂未在标准中提及的四大“硬件暗坑”

当开发者拿着标准 PIMA 15740 规范开始用纯 Swift 与 Switch 2 对话时，真正的硬核挑战才刚刚拉开帷幕。真实的物理硬件充满了协议白皮书上从未记载的“特异行为”，Tethersnap 在源码中完整踩平了以下四大深坑：

暗坑 1：平铺列举被彻底拒绝（Flat Listing is Rejected）

在标准 PTP 协议中，如果要一次性获取存储卷上的所有文件，规范规定可以调用 GetObjectHandles，传入对应的 StorageID，并将 Format 置为 0、Parent 句柄置为 0x00000000（代表查询整盘根部全部对象）。

当 Tethersnap 向 Switch 2 发出这组标准参数时，硬件直接返回了 InvalidObjectHandle（0x2009）错误，并附送了一个 4 字节的空数据载荷！

→ GetObjectHandles tx 2 [0x00260001 0x00000000 0x00000000]
← InvalidObjectHandle (0x2009) tx 2, 4 data bytes

破解方案：强制树状递归遍历
Switch 2 拒绝了平铺查询，但支持显式的树状递归。必须首先传入 Parent 为 0xFFFFFFFF 查询根目录关联项：

→ GetObjectHandles tx 3 [0x00260001 0x00000000 0xFFFFFFFF]
← OK tx 3, 8 data bytes                       获得一个根句柄：0x0000088D
→ GetObjectInfo tx 4 [0x0000088D]
← OK tx 4, 88 data bytes                      类型为 Association（目录），对应具体游戏
→ GetObjectHandles tx 5 [0x00260001 0x00000000 0x0000088D]
← OK tx 5, 16 data bytes                      获得该游戏文件夹下的截图文件句柄列表

这一发现同时带来了一个意外收获：在初代 Switch 上，底层相册目录是按照 Album/YYYY/MM/DD（年月日）进行物理归档的；而在 Switch 2 上，根目录下的每一个 Association 文件夹天然直接对应一款游戏的名字！Tethersnap 顺水推舟，无需额外发包查询关联游戏元数据，在遍历目录层级的同时就原生实现了“按游戏自动聚合”的展示体验。

暗坑 2：存储卷 ID（Storage ID）随会话动态漂移

在常规数码相机中，相机的存储卡 ID（如 0x00010001）通常是固定的。许多客户端为了提速，会在初次连接后将 StorageID 缓存至本地配置文件中。

但在 Switch 2 上，唯一名为“Album”的存储卷，其 ID 在每次重新进入连接模式时都在不断自增变化：

第一次会话：0x000F0001
第二次会话：0x00140001
第三次会话：0x00260001

高 16 位的计数器不断递增，猜测与系统切入“USB 复制”界面的内部次数有关。因此，客户端严禁持久化保存任何包含 Storage ID 的状态，每次握手必须重新执行 GetStorageIDs。

同时，Switch 2 返回的 StorageInfo 中，MaxCapacity（最大容量）与 FreeSpaceInBytes（剩余空间）两个 64 位整数均被暴力填充为全 1（0xFFFFFFFFFFFFFFFF）。如果客户端没有对此做防御性校验，就会直接在界面上计算出一个 16 EB（Exabytes）的荒谬外星容量。

暗坑 3：标准握手流程的“一次性失效”

按照 PTP 规范，客户端在没有开启 Session 时，可以先向设备发送 Transaction ID 为 0 的 GetDeviceInfo（0x1001）来探测设备能力，确认无误后再调用 OpenSession（0x1002）正式建立通信管道。

Switch 2 表现出了奇特的“状态记忆”特性：

当主机开机后第一次插入并进入传输页面时，这个标准流程完美通过；
但如果用户中途在掌机上退出“USB 复制”页面，随后再次进入并重新连接，Switch 2 会对未开 Session 的 Transaction 0 报文直接回复 InvalidTransactionID（0x2004）！

破解方案：双轨握手自适应容灾
Tethersnap 在传输层保留了双轨握手逻辑：先尝试合规的标准无会话握手；一旦捕获到无效事务错误，立即平滑降级为先调用 OpenSession 打开会话，然后在合法的会话计数器内调取 GetDeviceInfo。

暗坑 4：陈旧会话死锁与任天堂 STALL 控制复位

这是所有暗坑中最致命、也是日常使用中最容易引发“变砖假死”的问题。

如果用户在 Mac 上曾经运行过 Google 遗留的 Android File Transfer Agent（它会在检测到 USB 插入瞬间在后台抢先打开一个 PTP 会话并弃置），或者前一次传输因异常拔线中断，当 Tethersnap 发起 OpenSession 时，Switch 2 会返回 SessionAlreadyOpen（0x201E）。

很多开发者可能会想：“既然会话已经开了，那我直接复用不就行了？”
绝不可行。因为 PTP 响应器在服务端严格校验事务计数器（Transaction Counter），而没有任何 PTP 指令可以查询远端当前的计数器到底递增到了几。任何后续请求都会因计数器错位全部沦为 InvalidTransactionID。

那么尝试调用 CloseSession 关闭僵尸会话呢？由于 CloseSession 本身也需要携带正确的事务计数器，同样会被无情驳回！

标准 USB 静态图像类规范专门为此设计了一个应急通道：在控制管道（Control Pipe 0）上下发类特有复位请求（bRequest = 0x66，Device Reset），强制设备清除会话并回归空闲状态。然而，实测 Switch 2 固件版本 22.5.0 对这个标准复位请求的处理是：直接 STALL（挂起停顿）！

面对无路可退的死锁，Tethersnap 拿出了底层的“终极核武器”：

flowchart TD
    A["OpenSession 发起连接"] --> B{"响应结果"}
    B -- "OK (0x2001)" --> Normal["连接建立成功，开始同步"]
    B -- "SessionAlreadyOpen (0x201E)" --> C["尝试 CloseSession 强退僵尸会话"]
    
    C -- "OK" --> A
    C -- "失败 (事务计数器未知)" --> D["尝试 USB 静态图像类标准复位<br/>(Control Pipe bRequest 0x66)"]
    
    D -- "接收成功" --> A
    D -- "STALL 挂起拒绝 (固件 22.5.0 特性)" --> E["调用 IOUSBHostDevice.reset()<br/>触发 macOS 内核级 USB 总线硬件物理复位"]
    
    E --> F["切断 USB 拓扑，等待系统重新枚举 (Software Re-plug)"]
    F --> G["捕获 IOKit 重新上线事件，重新发起 OpenSession"]

通过直接向 macOS 内核的 IOUSBHostDevice 对象发送 reset()，强制在主板根集线器层面切断该端口的 D+/D- 信号并重新拉高，实现软件层面的“拔出再插入”。设备在几秒后重新枚举，一切陈旧状态被物理归零，应用重新接管，彻底解决了无需手动拔插线缆的死锁难题。

4. Swift 6 并发艺术：单线程半双工协议的工程解法

在完成了协议逆向后，如何用现代 Swift 构建一个稳定、高性能的 Mac 应用，同样展现了极高的工程水准。

4.1 警惕 Swift 并发协同线程池饥饿（Cooperative Pool Starvation）

在 Swift 6 的并发世界中，很多开发者倾向于把所有的 I/O 操作都包装为 async/await。但 PTP over USB 本质上是一个绝对单向、严格单序的半双工对话：发送一条命令，接收可选的数据包，接收状态确认包。在同一个 Session 下并发发包只会造成硬件协议解析错乱。

更严重的问题在于：从 Switch 2 读取一段 35MB 的实机录屏视频（调用 GetObject），底层的 Bulk-In 管道即便跑满也需要持续阻塞数秒。如果将这种耗时极长的底层阻塞调用直接放在 Swift 默认的并发协作线程池（Cooperative Pool）中运行：

[!WARNING]
Swift 协作线程池的大小通常与 CPU 核心数严格绑定（例如 8 核 Mac 仅有 8 个工作线程）。一旦几个大型文件下载任务同时占满线程，就会导致全局调度器彻底无空闲线程可用，造成 UI 动画掉帧、计时器停摆甚至整机应用假死。

Tethersnap 的做法极其严谨：将设备通信完全限制在一个专用的 actor DeviceService 内部，并 为该 Actor 配备了独立的专用串行调度队列（Custom Serial Executor）：

actor DeviceService {
    private var connection: TethersnapConnection?
    // 创建完全脱离 Swift 协同线程池的专用底层串行队列
    private nonisolated let executorQueue = DispatchSerialQueue(label: "dev.luminoid.Tethersnap.DeviceService")

    nonisolated var unownedExecutor: UnownedSerialExecutor {
        executorQueue.asUnownedSerialExecutor()
    }

    // 所有 MTP/PTP 硬件交互均作为此类 Actor 方法执行：
    // 严格串行执行、支持安全阻塞调用、彻底隔绝全局线程池污染。
}

4.2 绕过 Apple SDK 的 `NS_REFINED_FOR_SWIFT` 迷局

在调用 Apple 的 IOUSBHost 框架时，Swift 开发者会遭遇苹果生态特有的“官方烂尾楼”：在 Objective-C 头文件里，苹果为很多核心方法标记了 NS_REFINED_FOR_SWIFT，意在由系统内置的 Swift Overlay 提供更现代的封装。

然而，十多年过去了，苹果官方从未真正交付过这层 Overlay，导致现代 Swift 编译器将这些原生 API 全部隐藏在带有双下划线（__）的前缀之后。为了获得底层控制权，代码必须直接调用这些底层符号：

// 创建硬件设备匹配字典并检索 IOKit
let matching = IOUSBHostDevice.__createMatchingDictionary(
    withVendorID: NSNumber(value: 0x057E), // Nintendo VID
    productID: NSNumber(value: 0x2061),    // Switch 2 PID
    bcdDevice: nil, deviceClass: nil, deviceSubclass: nil,
    deviceProtocol: nil, speed: nil, productIDArray: nil
)
let service = IOServiceGetMatchingService(kIOMainPortDefault, matching.takeUnretainedValue())
let device = try IOUSBHostDevice(__ioService: service, options: [], queue: nil, interestHandler: nil)

// 配置设备并下发 Bulk 传输
try device.__configure(withValue: 1, matchInterfaces: false)

4.3 描述符遍历迭代器的死循环防线

在通过 IOUSBGetNextInterfaceDescriptor 遍历设备配置以挑选具备 Bulk-In 与 Bulk-Out 端点的静态图像接口时，很容易写出如下看似优雅的闭包代码：

// ❌ 灾难代码：迭代器耗尽返回 nil 时，?? 运算符会重新从头取第一个接口，导致死循环
current = current.flatMap { IOUSBGetNextInterfaceDescriptor(configuration, $0) }
    ?? IOUSBGetNextInterfaceDescriptor(configuration, nil)

当上述代码在实际连接硬件运行时，由于条件分支永远无法终止，会导致线程跑满 100% CPU，应用卡死在“正在连接…”。Tethersnap 严格将其修正为传统的循环推进结构：

// ✅ 正确做法：显式前置种子指针，严格单向推进，遇空即停
var interfacePointer = IOUSBGetNextInterfaceDescriptor(configuration, nil)
while let interfaceDescriptor = interfacePointer {
    // 解析端点并匹配 Still-Image 接口...
    interfacePointer = interfaceDescriptor.withMemoryRebound(to: IOUSBDescriptorHeader.self, capacity: 1) {
        IOUSBGetNextInterfaceDescriptor(configuration, $0)
    }
}

5. 产品形态与实操上手

基于上述严密的协议栈与底层实现，Tethersnap 提供了 CLI 命令行工具 与 SwiftUI 桌面客户端 双重形态。

Tethersnap 运行于 macOS 界面，显示 Switch 2 截图视频网格与导出面板

5.1 CLI 极速诊断与批量导出

对于开发者或自动化工作流爱好者，可以直接通过 Swift Package Manager 编译运行 CLI：

# 1. 深度探测硬件能力与协议诊断（实时打印线路上每个数据帧的 Hex Dump）
swift run tethersnap probe --verbose

# 2. 列举掌机相册中所有截图与视频（自动按游戏分组展示）
swift run tethersnap list

# 3. 极速将全量媒体文件导出至本机指定目录（自动保留原始修改时间戳）
swift run tethersnap pull --all --out ~/Pictures/Switch2

5.2 优雅克制的 SwiftUI 桌面端

桌面版 App 展现了原生 Mac 软件应有的克制与高效：

即插即用：集成 IOKit 热插拔通知，无论何时插上 Switch 2 并打开复制界面，App 毫秒级自动就绪；
硬件级缩略图直出：虽然 Switch 2 砍掉了局部切片，但其内部为每张截图和视频都预生成了 20 ~ 30 KB 的紧凑 JPEG 缩略图。Tethersnap 逐个调用 GetThumb，在几十毫秒内就能铺满整个网格视口；
访达无缝交互：支持 Command 多选、区间多选，甚至支持直接将选中的截图从 App 窗口拖拽到访达文件夹或桌面；
防休眠与容错保护：在导出数 GB 视频期间，自动调用 IOKit 声明系统防休眠断言；中途如果用户误触取消导出，App 自动废弃受损会话并毫秒级重连，绝不让硬件卡在未知悬挂态。

6. 横向对比与架构启示

评估维度	传统 MTP 方案 (OpenMTP / MacDroid)	Linux libmtp 方案	Tethersnap (纯血原生方案)
Switch 2 兼容性	彻底失效（缺失 GetObjectPropList 抛错）	兼容（具备 DEVICE_FLAG_NONE 降级）	完美支持（端到端原生基线 PTP 实现）
macOS 运行时依赖	Electron / Node / 专有后台服务	依赖 Homebrew + libusb + LGPL 动态库	零第三方依赖，纯 Swift + 系统框架
系统侵入性	频繁申请各类高危权限	用户需自建编译工具链	免驱动、免内核扩展、免提权
僵尸会话自愈	无法自愈，必须手动拔插线缆	依赖应用层重试	IOUSBHostDevice.reset() 物理总线自愈
系统并发亲和度	依赖 V8 事件循环或黑盒线程	C 语言 pthread 粗粒度锁	Swift 6 Actor + 专用串行执行器

结语

Tethersnap 的诞生与开源，为当今的软件工程界提供了一个极具深意的切片：

在长达二十年的时间里，平台巨头（苹果）未曾内置 MTP 支持，主机大厂（任天堂）在次世代设备上选择了最原始简朴的 2000 年 PTP 基线标准，而行业现存的跨平台工具却集体沉溺在对 MTP 扩展的理所当然中——三方预期的错位，最终酿成了一整片生态的失效。

而破局者往往不需要成千上万行的宏大工程。通过对底层协议的敬畏、对硬件描述符的敏锐洞察、以及对操作系统原生驱动框架的极致驾驭，仅用数百行纯粹、健壮的 Swift 代码，便能以最优雅的姿态填平系统之间的断层。这正是开源与极客精神最迷人的魅力所在。

🔗 官方资源与延伸阅读

GitHub 官方源码仓库: Luminoid/Tethersnap
作者深度原版解密博文: Tethersnap: Switch 2 captures on a Mac over plain PTP
Apple Developer 官方文档: IOUSBHost Framework Reference
ISO 官方标准: ISO 15740:2013 - Picture Transfer Protocol (PTP)

lijianfei.com