同事把一个 3MF 文件甩到群里说“帮忙看一眼这个模型是不是缺件”你双击它系统弹出一个“选择打开方式”的窗口翻了半天列表也没找到能认领它的程序换成 GLB好不容易找了个在线网站结果模型加载到一半卡住贴图全是黑的再换成 FBX打开是打开了可里面只剩一副骨架在飘。这类事我碰得太多了。3D 文件的麻烦从来不在“有没有软件”而在于格式太多、每种格式的设计目的又完全不同——GLB、OBJ、STL、FBX、3MF、PLY、DAE 这七个扩展名背后其实是四套完全不同的思路指望一个系统自带的查看组件全部认下来本身就不现实。所以这篇东西想聊的是一个能同时打开这七种格式的通用查看器到底要满足哪些条件以及我在实际用它的过程中怎么从“能打开”一步步走到“看得对、用得上”。不管你是刚接触 3D 打印的新手还是天天在建模软件和引擎之间倒腾文件的老手下面这些内容应该都能省你几个小时的折腾。1. 七种扩展名背后的四种设计目标很多人把 3D 文件格式理解成“同一份数据的不同存法”就像图片的 jpg 和 png互转一下几乎无损。这个认知在 3D 领域是要吃亏的。这七个格式诞生于完全不同的年代和用途有的只为把一堆三角面片传给下一台机器有的想连材质、灯光、摄像机、骨骼动画一起打包带走。搞不清这一点你会在“为什么转完格式颜色没了”“为什么模型变小了一百倍”这类问题上反复撞墙。1.1 STL、OBJ、PLY从“面片”出发的三种思路STL 是最朴素的一种它几乎只回答一个问题这个物体的表面在哪里。文件里存的是一堆三角面片的顶点坐标和法向量没有颜色、没有材质、没有单位、没有对象层级甚至连“这是一个杯子”这种信息都没有只有一堆三角形。它有 ASCII 和二进制两种编码实际流通的绝大多数是二进制版本因为 ASCII 版体积能膨胀五六倍。STL 的另一个特点是它不共享顶点相邻两个三角形各自存一份自己的顶点所以文件里存在大量重复坐标。这直接导致了后面会讲到的一个经典问题把 STL 读进来之后模型看起来是一个整体实际上内部是几万个互不相连的碎片。OBJ 的思路进了一步它把顶点、法线、纹理坐标分开存面片通过索引去引用这三组数据。好处是顶点可以共享文件更紧凑而且它支持多边形面不只是三角形支持一个文件里放多个对象还能通过配套的 .mtl 文件描述简单的漫反射颜色、高光、透明度和贴图。代价是 OBJ 的索引写法沿用了一套很老的约定索引从 1 开始而不是 0负索引表示相对位置很多自己写解析器的人第一次都会在这里翻车。OBJ 没有动画没有骨骼没有灯光和摄像机它就是一个纯粹的静态几何 基础材质格式。PLY 的定位更偏“扫描数据”。它最初是为了存放三维扫描仪输出而设计的所以对点云和顶点属性特别友好除了坐标和法线还能挂任意自定义属性比如每个点的颜色、置信度、强度。PLY 同样有 ASCII 和二进制两种形态二进制又分大小端这也是它在跨平台传递时偶尔出问题的地方。做逆向工程、文物扫描、人脸建模的人对 PLY 最熟而做产品结构设计的人可能一辈子都用不上它。1.2 GLB 与 DAE把整个场景装进一个文件GLB 是 glTF 规范的二进制封装形式。glTF 这套规范一开始就是冲着“三维界的 JPEG”去的目标很明确让三维内容能在网页和移动端快速加载。所以它的设计处处考虑传输效率——紧凑的二进制缓冲、明确的 PBR 材质定义金属度、粗糙度、基础色、法线、遮蔽、自发光一整套贴图通道、支持动画和骨骼、支持多场景和节点层级。GLB 把 JSON 描述和二进制数据打包进同一个文件贴图可以直接内嵌不用再担心“模型发过去了图没发过去”这种事。这也是为什么现在网页上的三维展示、电商产品旋转预览、AR 试摆基本都是 GLB 打天下。DAE 是另一条路。它基于 XML是一套开放的场景交换规范想把几何、材质、动画、物理、摄像机全塞进去野心很大。好处是纯文本、结构清晰、可读性强任何编辑器打开都能看懂里面写了什么。坏处也很明显XML 冗长同样一个模型DAE 的体积经常是 GLB 的好几倍解析速度也慢。现在新项目基本不怎么用 DAE 了但早年间的三维素材库、教学资源、老设备导出的文件里DAE 的存量非常大你只要在这个圈子里待得够久总会遇到几个非开不可的 DAE。1.3 FBX 与 3MF一个偏动画资产一个偏制造交付FBX 是这七个里结构最复杂的。它天生为动画和影视流程服务一个 FBX 文件里可能包含几十个物体、一套完整的骨骼绑定、蒙皮权重、关键帧动画、混合变形、摄像机、灯光甚至嵌套的引用关系。它有 ASCII 和二进制两种存法但真正流通的基本都是二进制。FBX 最大的坑在于版本兼容高版本软件存出的文件低版本打不开而且报错信息往往含糊不清只说“文件损坏”或者“不支持的格式”让人误以为是文件传坏了。我在实际项目里养成的习惯是凡是给外部协作者的文件一律另存为向下兼容的版本宁可丢一点新特性也别让对方在第一步就卡住。3MF 则是完全另一套逻辑。它基于 XML 和 OPC 打包规范本质上是把一个模型拆成若干个 XML 部件再压缩成一个包。它最被低估的能力是保留单位与制造语义文件里明确写了这个模型是用毫米还是英寸建模支持多材料、多颜色分区、表面纹理、甚至切片相关的元数据。STL 因为不带单位经常出现“导进去发现是 1 毫米的蚊子”这种事而 3MF 从设计上就堵住了这个漏洞。这几年三维打印的整条链路都在往 3MF 上迁很多切片软件已经把它当成首选输入格式。1.4 一张对照表把选择说清下面这张表是我自己整理的口径判断“这个文件该用什么心态去打开”时经常翻它格式核心承载内容是否带材质贴图是否带动画/骨骼是否记录单位典型来源STL三角面片 面法线否否否三维打印、CAD 导出OBJ多边形几何 基础材质是外部 mtl 与贴图否否建模软件通用导出PLY网格或点云 顶点属性顶点色无 PBR否否三维扫描、科研数据FBX完整场景资产是是隐含动画、影视、游戏流程DAE完整场景资产是是有声明字段老素材库、教学资源GLB场景 PBR 材质 动画是可内嵌是是米网页三维、AR、电商3MF制造模型 材料分区颜色与纹理否是显式声明三维打印交付看懂这张表你就明白为什么“一个应用全搞定”这件事有难度这七个格式的解析器几乎是七套独立工程还要把读出来的东西统一到同一套渲染管线里。能做到这一点的查看器通常背后是一整套成熟的解析库而不是简单调用系统接口。2. 通用查看器要通吃必须啃下哪几块硬骨头市面上号称“支持几十种格式”的工具不少但实际用起来差距巨大。有的打开 FBX 只剩几何动画和材质全丢有的打开 3MF 颜色全白因为它只读了网格没读材质分区。要判断一个查看器是真的能吃下这七种格式还是只做到“能显示出形状”得从它内部要解决的几个硬问题看起。2.1 解析层格式再多也逃不出两类封装第一类是单文件裸数据STL、PLY 属于这一类文件里就是纯粹的顶点和面片数组读起来相对直接难点在于编码分支多。STL 要判断是 ASCII 还是二进制常见做法是先看文件头长度和面片数是否对得上PLY 要识别头部声明的属性列表和二进制端序。这类格式的解析器写起来不难但边界情况多比如某些老软件导出的 STL 文件头里塞了非标准字符或者 PLY 的属性顺序和声明不一致。第二类是结构化容器OBJMTL、FBX、DAE、GLB、3MF 都属于这一类。它们要么有外部依赖OBJ 要去找 mtlmtl 又要去找贴图要么内部有复杂的引用关系FBX 的节点树、GLB 的 accessor 与 bufferView 索引、3MF 的 OPC 关系文件。这一类的解析难度不在读取而在关系重建你得把所有引用都解开把分散的数据拼回一棵完整的场景树还要在处理失败时给出定位信息否则用户只看到一片空白根本不知道是哪一步断了。我见过不少人自己写小工具读模型卡住的地方几乎都在第二类上。GLB 里的 accessor 有个 byteOffset 和 componentType只要有一个字段解释错了整个模型的索引就会错位表现出来就是模型变成一团乱麻或者直接崩溃。这种时候最有效的排查方式是拿一个已知正确的最小样本比如只有一个立方体的文件反复比对而不是拿复杂模型硬试。2.2 渲染层PBR 材质与坐标系的统一模型读进来只是第一步画出来才是关键。这里有两件事必须在查看器内部统一处理。第一件是材质模型的归一化。GLB 用的是标准的 PBR 金属度工作流参数齐全OBJ 只有基础的漫反射和高光FBX 的材质定义在版本之间差异很大同一个“高光强度”在不同版本里的含义都可能不同STL 和 PLY 干脆没有材质。查看器要做的是把这些参差不齐的描述映射到同一套着色模型上缺的参数给合理默认值。这里最容易翻车的就是金属度默认值有些转换器把 OBJ 转成 GLB 时把金属度默认设成了 1结果在没有任何环境光照的查看器里模型就是一坨纯黑的剪影新手会以为是文件坏了。第二件是坐标系的统一。glTF 约定 Y 轴向上而大多数建模和工程软件习惯 Z 轴向上STL 和 3MF 这类来自 CAD 和打印领域的格式基本都是 Z 向上。一个模型从 Z-up 系统导出、按 Y-up 系统导入表现出来的就是“模型躺倒了”。好的查看器会在导入时根据格式做一次轴向转换或者在界面上给你一个手动旋转的开关做得糙的就直接原样渲染让你自己去转视角。2.3 单位与尺度的归一化处理这是最容易被忽略、又最影响体验的一环。GLB 的单位约定是米3MF 里显式写了单位OBJ、STL、PLY、FBX、DAE 里要么没有单位要么只有一个不起作用的声明字段。于是同一个 100 毫米见方的零件从不同软件导出后在查看器里的视觉大小可能相差一千倍。查看器的通用做法是读进来之后先算一次包围盒如果发现尺寸落在明显不合理的区间比如小于 0.001 或者大于 10000就按启发式规则自动缩放并给出提示。这个提示很重要我见过太多人把“模型太大看不见”误判成“文件损坏”。如果查看器没有这个提示你在视口里看到的永远是空无一物然后就开始怀疑人生。2.4 判断“真支持”还是“能打开就算”的三条标准我自己验收一个查看器时会拿同一套测试文件跑这三条用带内嵌贴图的 GLB 打开看贴图是否正确显示——这条验的是它有没有把内嵌资源和外部引用都处理对。用带骨骼动画的 FBX 打开看能不能播放动画、能不能看到骨骼层级——这条验的是它是否真的解析了场景结构而不只是抽了几何。用带多材料分区的 3MF 打开看不同分区是否显示不同颜色——这条验的是它有没有读材质语义而不只是网格。三条全过才算真的能通吃。只过第一条的基本只能算个“网格预览器”遇到复杂点的资产照样得换工具。3. 打开方式的选择临时看一眼、日常用、批量处理同样是“打开一个 3D 文件”场景不同最合适的打开方式完全不同。临时看一眼别人发来的模型、每天反复打开自己项目的资产、一次处理几十个待检查的文件这三种需求对应的方案差别很大混着用会浪费大量时间。3.1 桌面端拖拽打开与文件关联设置桌面客户端的核心优势是文件关联——把七种扩展名都注册到同一个程序上之后双击就能直接看不用每次去找“打开方式”。这个设置看着简单实际有几个细节值得注意。一是不要抢走已经有人在用的关联。比如 .obj 这个扩展名有些开发工具也会注册它你一刀切地把 .obj 绑到查看器上可能导致别的工具出问题。稳妥做法是只关联那些你确定没有其他程序在用的扩展名或者在系统设置里逐个确认。二是拖拽比双击更灵活。把文件从资源管理器直接拖进已经打开的窗口可以避免每次都重新启动程序加载速度也更快。对于需要连续对比多个版本模型的场景这个差别很明显。三是记住最近的打开记录。检查模型的时候经常要在几个文件之间来回切如果每次都要重新从文件夹里找效率会很低。支持最近文件列表的查看器值得优先考虑。3.2 网页端预览的适用边界网页端预览的价值在于零安装和跨设备。手机上收到一个 GLB想快速确认一下是不是想要的那个模型打开一个网页拖进去就行不用装任何东西。给别人演示的时候也方便发个链接就行不用担心对方装没装软件。但它的边界也很清楚。第一本地文件不会真的上传这件事需要确认清楚有些在线工具会把文件传到服务器处理涉及保密模型时这是不能接受的用之前一定看清楚它是纯前端渲染还是服务端解析。第二大文件吃不消浏览器内存有限几百兆的 FBX 很容易把标签页拖崩。第三格式支持往往不全网页工具对 GLB 的支持普遍很好对 FBX、DAE、3MF 的支持就要看具体实现很多只做了几何解析。我的实际用法是GLB 和 OBJ 这种轻量格式网页端够用FBX、3MF 这种带复杂结构或者体积大的一律走桌面端。3.3 命令行无头模式处理成批文件这是最容易被忽略、但价值最高的一种方式。当你有几十上百个文件需要检查时——比如从素材库批量下载的一批模型或者外包团队分批交付的资产——一个个拖进窗口看是不现实的。这时候需要的是无头模式不打开界面直接跑一遍解析输出每个文件的基本信息。思路大致是这样各家工具的命令行参数名称不同但结构大同小异# 批量扫描目录下所有 3D 文件输出格式、面数、包围盒尺寸 for f in ./assets/*.{glb,obj,stl,fbx,3mf,ply,dae}; do [ -e $f ] || continue echo $f viewer-cli inspect $f \ --print format,triangle_count,bbox,has_texture,has_animation done这套东西跑一遍你能立刻发现哪些文件是空壳面数为 0、哪些文件尺寸离谱包围盒某一维是 0.001 或者 9000、哪些文件号称带贴图实际贴图丢了。比起一个个点开看效率差着量级。更进一步可以把这批结果导成 CSV用表格排序一眼就能挑出问题文件。3.4 三种方式的能力与限制对照使用方式上手成本大文件表现格式完整度适合场景桌面客户端需安装一次配置好可吃满内存最全日常查看、精细检查网页端零安装差易崩中等视实现而定临时确认、跨设备演示命令行需看文档好通常与桌面端一致批量筛查、自动化流水线4. 文件打开了却不对劲按显示症状倒推原因文件能打开只是开始真正耗时间的是“打开了但显示不对”。这一节我按症状来组织因为在实际场景里你手上掌握的信息往往只有一个现象——“黑的”“空的”“花的”需要从现象倒推原因。这个倒推链路我走过很多遍下面是最常见的几条。4.1 通体发黑或反光异常PBR 金属度与法线朝向模型整个是黑的是最高频的问题而且原因往往不是文件坏了。第一个嫌疑是金属度被错误地设成了 1。在 PBR 工作流里纯金属材质没有漫反射它的外观几乎完全来自环境反射。如果查看器没有提供环境光照很多简易查看器只有一个方向光金属材质就会呈现出接近纯黑的效果。判断方法很简单在查看器里切换一下材质模式如果能切到“无光照/纯色”模式模型立刻显示出正常颜色那基本可以确定是材质参数问题不是几何问题。解决办法要么换一个带环境光照的查看器要么在查看器里手动把金属度调到 0。第二个嫌疑是法线朝向反了。模型看起来发黑但不完全黑表面还有奇怪的高光转动视角时明暗关系不符合直觉这通常是面法线朝内了。STL 文件尤其容易出现这个问题因为它的法线是每个三角面单独存的某些导出流程会把绕序搞反。判断方法是开启“双面渲染”如果开启后立刻正常就是法线问题。修正的办法是重新计算法线或者直接依赖查看器的双面渲染开关应急。第三个嫌疑是顶点法线缺失或未归一化。STL 只存面法线不存顶点法线如果查看器直接用面法线做平滑着色模型表面会出现明显的棱角感看起来脏兮兮的。好的查看器会按角度阈值自动焊接顶点并重算法线粗糙的就只能忍受。4.2 视口空无一物缩放、原点与相机裁剪面打开之后什么都看不见比发黑更让人抓狂因为连个可判断的对象都没有。这条链路我是这样排查的第一步看包围盒数值。如果查看器能显示模型信息先看包围盒的尺寸。如果某一维是 0说明模型是扁的可能是个平面或者导出时压扁了如果尺寸是 0.0005 这种量级那就是单位问题模型小到看不见。第二步看相机位置。有些查看器的默认相机距离是按固定值设的遇到特别大或者特别小的模型相机要么在模型内部要么在模型外部很远的地方。这时候滚轮缩放几十下可能都没反应因为步长是按默认尺度算的。第三步看近远裁剪面。这是最隐蔽的一个模型在视锥里但因为超出相机的近裁剪面或远裁剪面而被裁掉了。表现出来的现象是“转到某个角度能看到一点转回去又没了”。遇到这种诡异现象优先怀疑裁剪面。第四步才是看原点。如果模型的几何中心离世界原点非常远比如坐标是 500000, 300000, 0相机对着原点就什么也看不到。这种情况在从大型工程装配体里导出的零件上很常见因为零件保留了装配坐标系下的绝对坐标。解决办法是把模型平移到原点。4.3 颜色和贴图消失材质引用路径与内嵌资源模型形状对但颜色没了、贴图是白的原因几乎都出在资源引用链上。OBJ 的情况最典型.obj 文件里写着mtllib model.mtl.mtl 文件里又写着map_Kd textures/diffuse.png。这三个文件之间的路径是相对路径一旦你把 .obj 单独拷出来发给别人后两个文件就找不到了颜色自然全丢。判断方法是看 .obj 同目录下有没有同名的 .mtl 文件以及 .mtl 里引用的贴图路径能不能对上。解决方法是打包时把三者放在一起或者干脆转成一个 GLB把贴图内嵌进去。GLB 虽然设计上支持内嵌但也不是绝对安全。有些工具导出的 GLB 只内嵌了几何的 buffer贴图仍然指向外部 URI这种文件换台机器打开就是白模。判断方法是在十六进制编辑器里搜一下文件里有没有http或者.png这种外部路径字符串。3MF 的颜色问题比较特殊。它的颜色信息存在材质分区里如果查看器只解析了网格部分没解析材质部件模型会全部显示成默认色。这种时候换一个明确支持 3MF 材质的查看器就行不算文件本身的问题。4.4 表面出现暗斑、破面非流形与法线焊接模型表面有一些细碎的黑斑或者某些面看起来“穿”进了内部这类问题的根因通常在几何本身。最常见的是非流形边和重复顶点。STL 因为不共享顶点相邻三角形的顶点在文件里是各自独立的副本如果两个副本的坐标有极小的浮点差异比如 1.0000001 和 0.9999999查看器在做顶点焊接时可能判定它们不是同一个点于是网格在那一处就裂开了渲染时出现细缝或者法线插值异常的黑斑。判断方法是调整查看器的顶点焊接容差merge threshold把它从默认值放大一点再刷新如果黑斑消失就是这个问题。另一个来源是退化三角形也就是三个点共线或者有两个点重合的三角形法线算不出来渲染出来就是一块黑。这类问题在做布尔运算、减面之后特别常见属于上游流程留下的脏数据查看器只能尽量容错没法根治。如果黑斑严重影响判断最直接的办法还是回到建模软件里做一次网格清理。4.5 动画不动骨骼绑定与采样帧率FBX 和 DAE 带动画打开后发现模型停在初始姿势点播放没反应。这条链路通常是查看器根本没解析动画通道或者解析了但找不到对应的骨骼节点。判断方法先看层级树。如果层级树里只有几何节点没有任何骨骼节点那就是解析时把骨骼信息丢了属于查看器能力问题。如果骨骼节点都在但播放没反应那可能是动画时长字段读错了或者帧率不对导致所有关键帧落在同一个时间点上。还有个容易被忽略的点部分 FBX 用的是“动画栈”结构同一个文件里可能有多个动画片段查看器默认只播第一个甚至一个都不播。这种时候要看看界面上有没有动作片段的下拉选择。5. 看完之后要转格式转换目标的判断依据确认模型没问题接下来通常要做一件事——转成下游能用的格式。这一步比“打开”更容易出问题因为转换会实实在在地丢东西。我一般先问自己一个问题这个模型接下来要交给谁5.1 按下游软件倒推目标格式如果下游是网页展示或者移动端答案毫无悬念是 GLB。PBR 材质齐全、贴图内嵌、体积小、加载快几乎是为这个场景定制的。如果下游是三维打印的切片流程优先 3MF。它保留了单位和材料分区能避免尺寸错乱也支持多色打印。只有在切片软件明确不支持 3MF 时才退而求其次用 STL并且一定要手动确认单位。如果下游是动画或影视流程那没什么选择余地得用 FBX。但要注意版本向下存一份更保险。如果下游是逆向工程或者点云处理PLY 是最稳的中间格式能保住顶点属性。如果下游是老旧的教学资源或者某个只认 DAE 的老设备那就只能 DAE转换时注意别把不支持的材质通道塞进去容易导致对方解析失败。5.2 转换中真正会丢的东西新手常以为转换是无损的实际完全不是。下面这几样是最容易悄悄丢掉的材质通道的丰富度。GLB 转 OBJ金属度、粗糙度、遮蔽这些 PBR 参数在 OBJ 里根本没有对应字段只能压成一个近似的漫反射颜色和高光。转完之后模型看起来“塑料感”很重就是因为这些信息丢了。几何精度。如果转换工具顺手做了一次减面有些工具默认就这么干三角形数量会下降形状精度跟着下降。做打印件的时候这一丢可能就导致尺寸超差。转换前务必确认有没有减面相关的勾选项。对象层级和命名。STL 不支持多对象把一个包含十个零件的装配体转成 STL出来就是一个合并的整体零件边界没了后续想单独处理某个零件就得重新拆。顶点属性。PLY 转向量格式时自定义属性强度、置信度、时间戳基本都会被丢掉这些在扫描数据处理里可能很关键。动画与骨骼。除了 FBX 和 GLB其他格式基本都不带完整动画。把带动画的 FBX 转成 OBJ动画信息直接蒸发。5.3 批量转换的脚本化写法单文件转换用界面就行文件多了还是得靠命令行。思路是把“输入目录、输出格式、目标参数”三样显式写清楚避免依赖工具默认值# 把目录内所有 FBX 转成 GLB保留贴图并内嵌 for f in ./input/*.fbx; do [ -e $f ] || continue base$(basename $f .fbx) viewer-cli convert $f \ --to glb \ --embed-textures \ --keep-animation \ --no-decimate \ --out ./output/${base}.glb done这里有两个参数值得强调。--embed-textures一定要开否则转出来的 GLB 仍然引用外部贴图等于没解决“发给别人就变白模”的问题。--no-decimate也要显式关掉减面多数工具默认不减但有的会为了优化体积自动执行批量跑的时候很难逐个发现。6. 几个我反复踩到的细节抛开格式和原理还有些琐碎但极其影响效率的细节属于那种“踩过一次就再也不会忘”的类型。文件名里的中文和空格。有些解析库在处理非 ASCII 路径时会出问题尤其是通过命令行批量处理的时候路径没加引号直接报“文件不存在”排查半天发现是文件名里带了个空格。养成习惯脚本里所有路径变量一律加双引号文件名尽量用英文和下划线。大文件的加载策略。几百兆的 FBX 直接拖进去如果查看器一次性把整个文件读进内存很容易直接卡死或者被系统杀掉。这时候可以先用命令行工具把模型减面或者拆分成多个块分块检查。另一个土办法是先只加载几何不加载材质很多工具提供这个开关看看是文件本身太大还是贴图太大拖累的。向下保存兼容版本的肌肉记忆。不管是导出 FBX 还是导出 GLB我现在都会多存一份向下兼容的版本。原因很简单你永远不知道下游用的是哪个版本的软件。多花十秒钟存一份能省掉后面一整天来回确认“你那边打开了吗”“我这边报错了”“那你传这个版本试试”的沟通成本。别迷信“支持格式数量”这个宣传指标。一个工具说支持五十种格式实际可能其中四十种只是“能读几何不能读材质”。真正该看的是它对你要用的那两三个格式的支持深度。这七个格式只要每个都能正确处理材质、单位、层级和动画就已经比大多数号称通吃的工具强了。遇到实在打不开的文件先分辨是文件问题还是工具问题。方法很简单拿一个肯定没问题的同类文件比如从官方素材包下的一个标准 GLB用同一个工具打开。如果标准文件正常那问题在文件如果标准文件也异常那是工具或者环境的问题。这一步能省掉大量无谓的怀疑。最后分享一个我个人觉得最省事的做法把常用的查看器和转换脚本做成一个固定组合查看器负责“看得对”脚本负责“批量过一遍找问题文件”。真正需要人眼细看的文件其实是少数——大部分异常在批量扫描阶段就暴露出来了。这套流程跑顺之后再遇到群里扔过来的一个奇怪扩展名文件心里就有底了。
