我最近在准备一场关于“编辑工具”的技术分享整理资料时在搜索引擎里敲了editor这个词结果跳出来的搜索结果让我愣了一下010 Editor、PDF-XChange Editor绿色版、Mermaid Live Editor、Plist Editor Pro、Corner Editor圆角插件、WS2812 Editor Qt、DRG Save Editor、Header Editor插件……这些东西除了都叫 editor其他地方几乎毫无关联。但仔细想想这个结果其实非常合理。editor不是一个软件的名字而是一类软件的统称。你搜这个关键词真正想找的并不是“某个叫 editor 的软件”而是“能帮我修改这种文件/这种数据的东西”。每个人的“这种东西”都不一样所以搜索词相同需求却天差地别。这篇文章我不打算做一份单纯的工具清单而是想把“编辑器”这件事拆开聊清楚为什么同样叫 editor有的改二进制、有的改 PDF、有的改灯带颜色、有的改游戏存档它们到底在解决什么问题我在实际动手时踩过哪些坑、有哪些可以直接照搬的经验如果你和我一样经常和各种各样的文件格式打交道这篇文章应该能帮你省下不少瞎折腾的时间。1. 一个“editor”关键词背后的不同数据世界1.1 你搜索的不是软件而是“能改这种文件的东西”先看一个很常见的场景拿到一个扩展名是.bin的文件用记事本打开全是乱码拿到一个.plist文件用文本编辑器打开能看到 XML 标签但不知道该改哪个节点拿到一张扫描版的 PDF想提取里面的文字却复制不出来拿到一个游戏的存档文件想改金币数量却发现根本没有明文数值。这些场景背后有一个共同点文件本身不是给人类直接阅读的纯文本而是被某种规则组织起来的二进制数据。有的格式规则公开比如 PNG、ZIP、plist有的格式规则未知比如很多私有存档格式还有的格式虽然公开但结构太复杂比如 PDF。普通文本编辑器默认把人家的字节流按字符编码解释遇到非文本字节就只能显示出乱码这时候就需要专门的 editor 上场。所以“editor”这个词在热搜里出现时背后对应的其实是完全不同的编辑对象010 Editor对应二进制字节PDF-XChange Editor对应 PDF 文档Plist Editor Pro对应苹果的配置属性文件WS2812 Editor Qt对应 LED 灯带的颜色数据DRG Save Editor对应游戏存档。它们唯一的共同点是“都能修改某种特定格式的数据”。1.2 所有编辑器都遵循同一条流水线不管界面长什么样几乎所有编辑器内部都遵循同一条工作流水线读入文件按格式解析展示成用户能理解的结构让用户修改再编码写回。区别主要在三个环节。第一是解析器有多强。文本编辑器只会把字节按字符集解码010 Editor 会把字节按十六进制展示还能用模板脚本把字节流映射成结构体PDF 编辑器则要把 PDF 的对象树解析出来否则改一个数字就会让整个文件崩掉。第二是展示层有多友好。同样是改配置文件命令行里用 vim 改 XML 是一种体验在 Plist Editor Pro 里用表格改键值是另一种体验。展示层越接近人类可读的结构操作越不容易出错。第三是写回时能否保留原始数据。这一点最容易忽略。很多编辑器只识别它认识的字段保存时会把不认识的字节覆盖掉。如果文件里有校验和、签名、偏移量表写回时必须一并处理否则文件就坏了。这也是为什么很多编辑器被用户评价为“一保存就损坏文件”——不是软件不行而是它压根没打算保留它不理解的数据。1.3 选编辑器前先问三个问题经过这几年折腾我总结出一个选型方法看到任何一个新 editor先别急着下载问自己三个问题。第一它编辑的对象是什么格式格式公开还是私有第二它保存时会不会破坏未知数据这决定了文件坏了之后你能不能找回原样。第三它能不能自动化比如命令行调用、脚本接口、批量处理。第一个问题决定工具选型方向第二个问题决定要不要在关键文件上使用第三个问题决定你用一次就扔还是能融进日常工作流。这三个问题想清楚了再去看编辑器的界面和功能基本不会选错。2. 010 Editor把二进制文件当结构化数据读2.1 文本编辑器看到的是字符010 Editor 看到的是字节我第一次用 010 Editor 是在分析一个设备固件包的时候。当时手里的工具只有记事本和 VS Code打开固件文件全是乱码根本无从下手。后来才知道问题出在“字符解码”上——文本编辑器默认把字节流解释成字符串遇到不可见字符就显示为乱码这不是文件损坏而是查看方式不对。010 Editor 的核心思路是不做这种“善意假设”。它把每个字节都以十六进制形式显示出来同时右边栏显示对应的 ASCII 字符用户可以自己决定这些字节到底是什么含义。这种视角在分析 PE 文件、固件、通信协议抓包、文件头、脚本加密数据时特别有用。它比一般十六进制编辑器强的地方在于模板脚本系统。你可以用类似 C 语言的模板语法定义一个结构体然后让 010 Editor 自动按照结构体解析二进制数据在结构树视图里直观地看到每个字段的值。这个功能相当于把一个无结构的字节流变成一张有字段、有类型、有注释的表。2.2 用模板脚本解析私有二进制格式以 ZIP 文件头为例模板脚本是 010 Editor 的精髓。拿 ZIP 文件举例一个 ZIP 文件由多个本地文件头和数据块组成每个本地文件头都有固定的签名 0x04034b50。用 010 Editor 打开任意 ZIP 文件可以看到开头四个字节是 50 4B 03 04这就是签名。如果手动看字节要对着十六进制数去猜哪个字节是压缩方式、哪个是文件名长度非常痛苦。这时候可以写一个简单的模板脚本struct LocalFileHeader { uint32 signature; // 0x04034b50 ushort versionNeeded; ushort flags; ushort compressionMethod; ushort modTime; ushort modDate; uint32 crc32; uint32 compressedSize; uint32 uncompressedSize; ushort nameLength; ushort extraLength; }; LocalFileHeader header;在 010 Editor 里运行这个模板它会把文件开头的 30 个字节自动解析成结构化字段文件名长度、压缩方式、CRC 值一清二楚。再配合循环可以把整个 ZIP 里的所有文件条目都列出来。这就是模板系统的价值它把“对着十六进制数瞎猜”变成“用结构体描述格式”。遇到私有格式时你可以先花一点时间逆向出结构然后写成模板之后每次分析同类型文件都能复用。2.3 “010 Editor 能写 Python 吗”的准确答案热搜词里有一条是“010 Editor 能写 Python 吗”这个问题其实问得很有代表性。准确回答是010 Editor 自带的脚本语言是 010 Script语法风格类似 C 语言不是 Python。但两者可以配合使用常见做法有两种。一种是在 010 Editor 里用模板把二进制解析成结构树然后把感兴趣的字段导出成文本或 CSV再交给 Python 做批量统计和可视化。另一种是反过来在 Python 里解析 010 Editor 的导出结果或者直接用 Python 的struct模块自己写解析脚本。我的经验是如果只是偶尔看几个字节用 010 Editor 的模板和界面就够如果要做大量文件的批量分析比如几千个固件包里提取版本号那更适合写 Python 脚本。010 Editor 适合“看清楚”Python 适合“批量化”两者不是替代关系。2.4 实测用同长度替换原则修改二进制中的版本号最后分享一个很实用的改二进制文件的例子。假设某个程序的可执行文件里用明文字符串存了版本号1.2.3你想改成1.2.4操作流程很简单用 010 Editor 打开文件按CtrlF打开搜索面板搜索类型选择“String search”输入1.2.3找到后切到 Hex 视图把对应的十六进制字节31 2E 32 2E 33改成31 2E 32 2E 34保存。这里有一个必须遵守的原则等长替换。1.2.3是 5 个字节1.2.4也是 5 个字节替换后文件长度不变后面的字节偏移不会变。如果改成1.10.0字符串变成 6 个字节后面的数据全部后移文件里如果有偏移表、长度字段或者校验和整个文件可能直接损坏。我在很多新手教程里看到过“直接改字符串”的说法往往会忽略等长替换这个前提。实际操作时凡是涉及二进制文件的修改第一反应都应该是这个改动会不会改变文件总长度如果会必须重新计算所有受影响的偏移量否则保存即报废。3. Mermaid Live Editor 和 PDF-XChange Editor文档生产线的两种工具3.1 为什么越来越多的人用代码而不是鼠标画图文档领域也有 editor最典型的是 Mermaid Live Editor 和 PDF-XChange Editor。这两个工具看起来很不一样一个是用文本描述图表一个是图形化编辑 PDF但它们的核心目标是一致的把人类能看懂的内容保存成计算机能稳定处理的格式。我第一次接触 Mermaid 是因为团队里需要维护一份架构图。用 Visio 画图的问题在于图是二进制文件改了一个节点同事环境里打开位置就变了而且代码评审的时候根本看不出这张图改了什么。后来我把架构图改成 Mermaid 语法图直接写在 Markdown 里每次修改都有了 git diff评审的人一眼就能看出“新增了一个模块、改了一条连线”。Mermaid 的本质是一个把文本描述渲染成图表的引擎。流程图、时序图、状态图、甘特图都能画。它的特点是图是代码写的所以可以进版本库、可以自动化生成、可以批量修改。代价是拖拽的自由度不如 Visio适合“逻辑清晰但不追求像素级排版”的场景。Mermaid Live Editor 是学习和调试 Mermaid 语法最顺手的入口。左边写语法右边实时渲染免去了安装本地环境的时间。对新手来说先在这个网页里把语法跑通再回到自己的文档工具里使用是最低成本的路径。3.2 在 Live Editor 里写出第一张可复用的流程图很多人第一次写 Mermaid 会觉得无从下手其实只需要掌握几个基本元素。下面这张图描述一个简单的用户请求处理流程graph TD A[用户请求] -- B{权限校验} B -- 通过 -- C[业务处理] B -- 拒绝 -- D[返回错误码] C -- E[记录日志]graph TD表示从上到下画图A、B这些都是节点 ID方括号[]表示矩形节点花括号{}表示判断节点--表示箭头连线-- 文字 --表示带标签的连线。在 Mermaid Live Editor 里输入这段文本右侧会立刻渲染出对应的流程图。确认没问题后可以通过菜单导出 PNG 或 SVG也可以保存分享链接发给同事。需要提醒的是节点 ID 不要用纯数字开头中文标签如果遇到渲染问题可以给标签加引号比如A[用户请求]。这些细节看起来很基础但实操中大部分渲染报错都是这类小问题引起的。3.3 Mermaid 渲染中的几个常见坑Mermaid 虽然入门简单但有几个坑值得提前知道。第一个坑是布局方向。graph TD是从上到下LR是从左到右。图节点一多不管哪种方向都可能出现交叉线这时候不要硬调样式而是把图拆成多个子图subgraph让相关节点聚在一起整体会清爽很多。第二个坑是中文和特殊字符。某些渲染环境对中文的字体支持不好导出的图片可能会出现方块字。解决方法是尽量在本地渲染出图后再导出而不是依赖在线转图服务。第三个坑是高分辨率导出。Mermaid Live Editor 在线导出 PNG 的分辨率有限如果要用来印刷或者做 PPT建议使用命令行工具mmdc渲染可以指定宽度和缩放比例。不然你会发现导出的图在屏幕上看还行放大就发虚。3.4 “绿色版”不是 PDF 编辑器的正解官方免费版才是再聊 PDF 编辑。热搜词里有“PDF-XChange Editor绿色版”这个关键词背后其实是一类常见的需求我只是想偶尔批注一下 PDF、填个表单、把扫描件转成可搜索文本不想为了一个小需求花几百块买专业版。PDF-XChange Editor 有一个经常被忽略的事实它本身就有官方免费版。免费版覆盖了日常批注、高亮、表单填写、基础 OCR 等常用功能绝大多数人根本不需要 Pro 版。很多人一搜“PDF 编辑器”就直接找绿色版下载站反而绕了一个大弯路还承担了捆绑软件、恶意插件的风险。我的建议是先从官网下载免费版按实际需求验证功能是否够用。如果确实需要高级功能比如批量导出、OCR 识别精度提升再考虑购买授权。把“找绿色版”的时间拿去试官方免费版体感会好很多也更安全。3.5 扫描 PDF 转可搜索文档的完整流程PDF 编辑里我用的最多的功能是 OCR。具体场景是我手上有一堆扫描的纸质资料扫出来是图片型 PDF文字没法搜索、没法复制。PDF-XChange Editor 的 OCR 功能可以给这种 PDF 增加一层文字层之后就能正常搜索和复制。操作流程不复杂打开扫描 PDF点击菜单里的 OCR 相关按钮选择识别语言中文或英文设置输出选项等待识别完成另存为一个新文件。关键点有三个一是在处理前先备份原文件避免识别过程改变原始图像二是语言选择要准确选错语言识别率会非常低三是识别完成后检查几页关键内容确认文字层和图像对齐因为某些扫描件倾斜角度大时文字层会有偏移。另一个很实际的建议是如果需要修改 PDF 里的原始文字别直接编辑正文。PDF 的排版依赖字体和坐标信息直接改文字容易出现字体缺失、重排错乱。更稳妥的做法是用批注或高亮来表达修改意见或者用“添加文本”的方式补充内容。这个思路同样适用于其他文档编辑器——能补充说明的地方尽量不要破坏原有排版结构。4. Plist Editor Pro 与游戏存档编辑器序列化数据的可视化修改4.1 plist 文件看起来是文本实际上是类型化树结构苹果生态里的 plist 文件是另一个非常适合用专用 editor 处理的格式。它的常见形态是 XML看起来可以直接用文本编辑器改但实际上是一个类型化的树形结构每个键有自己的数据类型String、Number、Boolean、Array、Dictionary 等。直接用文本编辑器改 plist 的痛点在于一个布尔值在 XML 里是true/一个字符串是stringxxx/string标签一旦写错或者类型配对不上程序读取时可能直接崩溃。此外还有一个隐藏得很深的问题plist 并不只有 XML 这一种形态它还有二进制格式bplist。二进制 plist 用文本编辑器打开就是一堆乱码根本没法直接改。Plist Editor Pro 这类工具解决的就是这个问题。它把 plist 文件解析成一个键值表格用户不需要关心底层是 XML 还是二进制只需要选中某个键修改它的值如果想把一个 String 改成 Boolean右键切换类型就能做到编辑器保存时会自动处理编码格式。4.2 Plist Editor Pro 的常规操作与 plutil 命令联动我日常用 Plist Editor Pro 做的比较多的事情有两种一是给 iOS 项目的 Info.plist 添加权限描述键比如相册权限NSPhotoLibraryUsageDescription、相机权限NSCameraUsageDescription。手动在 XML 里插入这些键值也可以但容易出错用编辑器操作就能直接看到键值类型。二是处理二进制 plist。当你遇到一个无法用文本编辑器读取的 plist 文件时除了用 Plist Editor Pro 打开还可以用 macOS 自带的命令行工具转换格式plutil -convert xml1 Info.plist plutil -convert binary1 Info.plist-convert xml1把二进制 plist 转成 XML-convert binary1把 XML 转回二进制。我经常先用这个命令把文件转成 XML再用文本工具对比差异最后用 Plist Editor Pro 做精细修改。命令行和图形界面配合效率比只用一种工具高很多。4.3 游戏存档编辑器的原理反序列化与重算校验游戏存档编辑器是收藏夹里比较特殊的一类典型的有 DRG Save Editor深岩银河的存档修改工具和艾尔登法环的 ER Save ID Editor。这类工具在原理上和 010 Editor 解析二进制文件是一致的把游戏存档的序列化数据反序列化成人能读懂的字段——金币数量、等级、道具、角色槽位——让用户在界面上修改。搜索热词里的“Save ID”在艾尔登法环存档中尤其重要。存档文件往往和账号、用户标识绑定Save ID Editor 做的就是把存档中的用户标识修改成当前账号能识别的值这样游戏才能正常加载这个存档。本质上它修改的也是二进制序列化数据中的某个字段只不过这个字段不是游戏数值而是“归属信息”。我个人的建议是这类工具不要把思路局限在“改一下数值”上。真正花时间去理解它背后的序列化结构反而能让你在工具更新跟不上游戏版本时自己动手分析新版存档格式。懂原理的人永远比只会点按钮的人走得远。4.4 修改单机存档的四个安全原则存档修改这件事必须反复强调安全边界。我的经验可以总结成四条原则。第一只改单机存档不要碰联机环境。单机游戏无论你怎么改都只影响自己的游戏体验联机环境里使用修改档会破坏其他玩家的体验也违背了公平竞技的基本规则这是底线。第二改之前必须备份整个存档目录。不要只复制单个文件有些游戏会同时存在多个备份槽位和配置文件复制整个目录最稳妥。备份文件夹加上时间戳比如save_backup_20250101_1200方便回退。第三只改自己能看懂的字段。金币、等级、魂量这类数值一看就明白哈希、签名、未知 ID 这类字段不要碰除非你清楚它是什么。乱改未知字段导致存档损坏是修改存档最常见的翻车方式。第四如果工具提供“重新计算校验”或“修复校验”的功能保存后一定要执行。很多游戏的存档服务端会校验数据的完整性不重新计算校验码游戏可能拒绝加载或者直接提示“存档损坏”。5. Corner Editor 和 WS2812 Editor Qt被数据格式定义的专用小工具5.1 Corner Editor 的价值把“圆角”变成可批量设置的参数设计领域也有 editor而且比代码领域的工具更聚焦。搜索热词里的 “Corner Editor圆角插件” 就是 Photoshop 里的一个专门处理圆角的小插件。为什么给 PS 做圆角还需要一个专用插件因为在实际做 UI 设计时很多页面元素是通过矩形图层、形状图层或者蒙版组合出来的不全是直接画一个“圆角矩形”。如果几个卡片圆角做到一半发现统一要改成 8 像素而不是 6 像素手动一个个调会非常崩溃。Corner Editor 这类插件的核心价值在于两点第一把圆角从“手动拖拽的控制点”变成“可以输入数值的参数”半径是多少直接填数字精确可复现第二支持批量操作选中的多个图层可以一次性套用相同的圆角参数保证视觉一致性。使用的时候有一个注意点普通图层和智能对象的处理逻辑不同。普通图层应用圆角通常需要借助图层蒙版或路径修改后还能再调整智能对象保持非破坏编辑的特性便于后续反复修改参数。建议在需要频繁调整圆角尺寸时优先用智能对象这样每次改动都不会损失原始像素。5.2 WS2812 Editor Qt给一串灯珠编排颜色时间轴硬件领域也有自己的 editor。WS2812 是一种可寻址 RGB LED 灯珠每个灯珠内置 IC只需要一根数据线就能串联几十上百颗灯珠每颗灯珠用 24bit 颜色数据控制。WS2812 Editor 这类基于 Qt 编写的图形工具面向的就是“怎么给这一串灯珠编排颜色动画”的需求。我在做桌面氛围灯的时候用过这类编辑器它的核心抽象是“时间轴 灯珠矩阵”。用户可以在界面上选择某几颗灯珠设置颜色然后生成随时间变化的动画序列。编辑器最终会把动画序列导出成控制器能识别的数据格式比如 C 数组、串口字节流或者设备协议包。这里我想强调一个容易被忽略的点理解底层的颜色协议比会用编辑器更重要。WS2812 的颜色顺序通常是 GRB不是 RGB亮度还涉及 gamma 校正直接用原始 RGB 值会导致颜色看起来偏暗或偏色。好的 WS2812 Editor 会在导出时做校正但你自己写代码时就需要特别注意。举个例子如果你自己做 60 颗灯珠的流水灯C 语言的逻辑大概是uint32_t frame[60]; for (int i 0; i 60; i) { frame[i] ws2812_color(i * 4, 255 - i * 4, 0); }这个数组就代表某一帧中 60 颗灯珠的颜色。编辑器做的事情本质上就是帮你生成和排列这些数组。5.3 小工具型编辑器的通用考察点Corner Editor 和 WS2812 Editor 都不是大而全的软件但它们都能在具体场景里大幅提升效率。这也引出一个通用问题遇到这类“专用小编辑器”怎么判断值不值得用我的考察点有三个。第一数据入口出口是否开放。数据入口开放意味着它可以接受你自己的素材数据出口开放意味着它导出的结果可以被其他工具继续处理比如导出 JSON、CSV、C 数组。第二是否具有可重复性。所有参数都能保存成预设或配置下次直接套用而不是每次重新输入。第三失败成本高低。如果工具出错会不会覆盖你的原始源文件会不会在没有备份的情况下格式化数据。选编辑器不是选最大最全的而是选“对特定数据的理解最深”的。这类小工具的价值恰恰在于专注它只做一件事但做得足够好。6. Header Editor 与请求级调试浏览器里的最后一类 editor6.1 什么时候需要修改 HTTP 请求头最后这类 editor 比较特殊它编辑的不是本地文件而是 HTTP 请求。Header Editor 是浏览器里的一个扩展用来拦截并修改网页发出的 HTTP 请求头。我最早用它的场景很典型本地开发一个移动端 H5 页面需要在电脑浏览器里模拟手机的 User-Agent。手动改 DevTools 里的 User-Agent 只能生效一次页面刷新后又要重新设置非常烦。后来我用 Header Editor 添加了一条规则只要请求的 URL 满足某个条件就自动把 User-Agent 替换成指定的手机 UA。这类扩展解决的痛点是“持续性的请求头改写”。除了切换 User-Agent常见的用途还包括给本地测试接口自动加 Authorization 认证头、修改 Referer 测试某个资源是否被防盗链限制、临时改 Accept-Language 验证多语言页面。它适合开发调试、接口联调、测试验证这类需要反复发请求的场景。6.2 Header Editor 规则配置实例Header Editor 的规则配置逻辑并不复杂关键是理解“匹配条件”和“操作类型”。拿“给本地接口自动加认证头”举例做法是新建一条规则匹配 URL 设置为*api.example.com*操作类型选择“追加请求头”或“修改请求头”字段名填Authorization值填Bearer 你的token保存后所有命中该 URL 的请求都会自动带上这个头。实际使用时有几个细节规则是自上而下匹配的多条规则同时命中时要注意执行顺序匹配条件里的通配符*能匹配任意字符但要注意不要写得太宽否则会影响无关请求有些 Header Editor 的实现还支持正则表达式适合更复杂的匹配场景。更稳妥的做法是只对特定环境生效。我的习惯是用一个固定的测试域名或本地端口作为匹配条件而不是对所有浏览器流量都生效。这样既能保证调试环境稳定又不会干扰日常工作时的正常访问。6.3 与 DevTools、抓包工具的配合以及 mixed content 的坑Header Editor 适合处理“持续生效”的规则但有些场景它并不合适。比如你想测试某个请求改完头之后返回什么用浏览器开 DevTools 的 Network 面板找到那个请求右键选择“Copy as fetch”或者直接编辑重放速度反而更快。如果要做更深入的分析比如看完整请求链路、修改响应头、断点拦截响应就需要用到抓包代理工具。Header Editor 可以跟这些工具组合使用用 Header Editor 负责持续性的请求头改写用抓包代理负责整体链路的排查。这里有个坑必须提醒你mixed content。当一个 HTTPS 页面尝试加载 HTTP 协议的接口或资源时浏览器会在控制台报错显示的大致内容类似 “Mixed Content: The page at ... was loaded over HTTPS, but requested an insecure resource ...”。这个报错经常出现在一些自带后台编辑器页面的 IoT 平台里因为平台域名是 HTTPS但设备上报的接口地址可能是 HTTP。很多人第一反应是想用浏览器插件绕过拦截但这条路走不通。浏览器的 mixed content 策略是安全底线插件级别的改写很难绕过也不应该绕过。正确的处理方式是在服务端或网关注册有效证书或者用 HTTPS 协议重新暴露接口让页面和接口协议一致。遇到这种报错先从协议层面解决不要试图在前端硬改。6.4 使用浏览器扩展改写请求头的边界最后说一下使用这类扩展的边界。Header Editor 本质上是修改你本机浏览器的请求行为这本身没有问题开发调试每天都在用。但要注意只对你自己的请求负责不要用修改请求头的方式去伪造身份、绕过网站的访问限制、或者做任何损害他人权益的操作。跨域场景也要留意。当你修改请求头时如果触发了跨域请求浏览器会先发送一个 OPTIONS 预检请求。服务端如果对预检请求没有返回正确的 CORS 头真正的请求会被浏览器拦截。这时候问题不在 Header Editor而在服务端的 CORS 配置单纯改请求头解决不了。还有一个安全习惯不要在公共电脑的浏览器扩展里保存敏感 token尤其是带有账号权限的认证信息。扩展数据存在本机浏览器配置里别人打开同一个浏览器就能拿到。个人开发机倒是无所谓共享设备一定要谨慎。我自己用过的编辑器二三十款有一个越来越深的体会编辑器本身不是目的那份需要被编辑的数据才是。遇到一个陌生的 editor先看它解析什么格式、是否破坏未知数据、能不能自动化这三点想明白通常十分钟就能上手。如果你也经常在不同文件格式之间来回横跳建议建一个“文件格式-编辑器”对照表把.bin对应到 010 Editor、.mmd对应到 Mermaid Live Editor、.plist对应到 Plist Editor Pro下次找工具就不用再从“editor”这个词开始大海捞针了。