企业官网建设流程全解析

改一份被保护的工作表，这事我这些年经手过太多次了。最常见的场景是：同事离职、交接文档、几年前自己随手加的保护密码，如今没人记得。手上这个表要改数据、要加公式、要重排列，结果右键菜单里一半是灰的，提示"工作表受保护"。于是有人开始在网上翻各种"Excel工作表密码原理与安全解除指南"，试了十几篇帖子，有的说改扩展名，有的贴一段VBA，有的让去下某个小工具，试完文件直接打不开。这篇文章就把这件事从原理到操作一次讲透：工作表保护密码到底存在文件的哪个位置、它是怎么被校验的、为什么绝大多数"偏方"失效、以及在不破坏文件的前提下怎么把保护干净地去掉。前提先说清楚——所有操作只针对你自己拥有、或者明确获得授权处理的文件，这是底线，不是客套话。不管你是刚被一个打不开的表卡住的职场新人，还是需要批量处理历史归档文件的技术同学，下面的内容都可以直接照着做。

1. Excel里其实并排放着两把完全不同的锁

很多人把"打开文件要输密码"和"工作表不能编辑"当成同一件事，只是程度不同。这个误解是后面所有弯路的总源头。这两件事在文件格式层面属于两个完全独立的机制，处理难度相差好几个数量级，混淆它们会让你在错误的路上浪费大量时间。

1.1 文件级加密：真正动用了密码学的那把锁

打开文件时弹出的密码框，对应的是文件级加密。设置路径在"文件 - 信息 - 保护工作簿 - 用密码进行加密"，或者"另存为"对话框底部的"工具 - 常规选项"里的"打开权限密码"。

一旦设了这个密码，整个文件内容会被真正的加密算法处理。现代版本的Excel用的是AES系列算法，配合随机盐值和多轮密钥派生。这时候你拿十六进制编辑器去看文件，看到的是密文，连工作表名、连有几个sheet都看不到。没有密码，就只剩下暴力枚举和字典攻击这一条路。

这条路走不走得通，完全取决于原密码的强度。六位纯数字、常见英文单词、生日组合，用现成的字典跑一跑，几秒到几分钟就有结果。但如果是十几个字符、大小写数字符号混排的随机串，以目前的算力水平，基本可以认为是不可行的。这里没有"技巧"可言，纯粹是计算量的问题。

所以碰到"打开就要密码"的文件，第一件该做的事不是找工具，而是回想这个文件是谁给你的、什么时候给的、对方有没有可能还在。绝大多数真正让人头疼的加密文件，最后都是通过找到原始创建者解决的，而不是靠技术手段。

1.2 工作表保护：格式层面的一道"约束"，压根不是加密

现在说你真正关心的这个：工作表能打开、能看到所有数据，但单元格改不了，插入行是灰的，删除列也是灰的。这个叫工作表保护，设置路径是"审阅 - 保护工作表"。

它和工作簿结构保护（"审阅 - 保护工作簿 - 保护工作簿结构"，防止增删移动工作表）属于同一类机制。这两者的共同点是：数据完全以明文形式躺在文件里，一个字节都没加密。

这个设计不是偷懒，而是有实际考虑的。工作表保护的目标场景是"防止误操作"和"防止随手改动"，不是"防止有心人窃取"。举个例子：你发一份填写模板给二十个部门，你不希望他们删掉表头、改掉公式列、动到下拉框，但你要让他们能填数据。这时候工作表保护就是一个"软约束"——它拦住的是正常操作路径，不负责对抗刻意绕行。

把这两个机制对比一下就清楚了：

看到这张表，后面所有操作就有方向了。你现在要处理的，几乎确定是右边那一列。

1.3 还有第三种：容易被忽略的"修改权限密码"

除了上面两种，还有一个藏在"常规选项"里的修改权限密码。它和打开密码在同一个对话框里设置，但行为不一样：设了之后，文件可以直接打开查看，只是打开时会问你要不要以只读方式进入，或者输入密码进入可编辑状态。

这个机制在实现上更接近权限声明，而不是内容加密。它经常和"建议只读"一起出现，标志位存在文件里。遇到这类文件，你其实可以直接编辑另存，只是原文件不能原地覆盖。这个细节后面第 5 章会具体讲。

2. 把一个 xlsx 拆开看，工作表密码究竟写在哪一行

想干净利落地解决一个问题，最省时间的办法是先搞清楚它的物理位置。工作表保护这个机制，只要你亲手拆开一个文件看过一次，以后再遇到就是五分钟的事，不会再被各种帖子带着乱跑。

2.1 xlsx 本质就是个 zip，改个后缀就能进

从 2007 版开始，xlsx 使用的是基于 XML 的开放打包格式。说人话：它就是一个 zip 压缩包，里面装着一堆 XML 文件和资源文件。

你不用装任何解压工具，把报表.xlsx复制一份，把副本改名成报表.zip，双击就能打开，看到的目录结构大致是这样：

报表.zip ├── [Content_Types].xml ├── _rels/ │ └── .rels ├── docProps/ │ ├── app.xml │ └── core.xml └── xl/ ├── workbook.xml ├── styles.xml ├── sharedStrings.xml ├── worksheets/ │ ├── sheet1.xml │ ├── sheet2.xml │ └── sheet3.xml └── _rels/ └── workbook.xml.rels

这里有个关键信息要先记住：xl/worksheets/下面每个 sheetN.xml 对应一个工作表，顺序不一定等于你在 Excel 里看到的标签顺序，真正的对应关系写在xl/workbook.xml和xl/_rels/workbook.xml.rels里。这个坑后面第 7 章会专门说。

工作簿结构保护的标志位则在xl/workbook.xml里。

2.2 sheetProtection 节点：一行标签决定了一切

用文本编辑器打开xl/worksheets/sheet1.xml，搜索sheetProtection，你会看到类似这样一行：

<sheetProtection algorithmName="SHA-512" hashValue="jXk2...省略..." saltValue="9fA1...省略..." spinCount="100000" sheet="1" objects="1" scenarios="1" formatCells="0" formatColumns="0" formatRows="0" insertColumns="0" insertRows="0" insertHyperlinks="0" deleteColumns="0" deleteRows="0" sort="0" autoFilter="0" pivotTables="0"/>

在老版本保存的文件里，可能长得更简单，没有算法相关的属性，只有一个password="83AF"。

这些属性分两类，理解它们的分工非常重要：

第一类是"锁"本身的标识。sheet="1"表示这个工作表处于受保护状态。这一位是 1，Excel 就把这个表当成受保护的，右键菜单里相关的项就变灰。objects、scenarios分别控制图形对象和方案是否被锁。

第二类是"密码校验数据"。也就是password，或者algorithmName/hashValue/saltValue/spinCount这一组。它们的作用只有一个：当用户点"撤销工作表保护"时，Excel 拿用户输入的字符串重新算一遍，和你设密码时存下来的值比对，一致才放行。

第三类是"例外许可"。formatCells="0"这种为 0 的属性，表示在保护状态下不允许对应操作。如果写成 1，表示允许。这就是为什么有些表你能筛选能排序，但改不了单元格内容。

看清楚这三类的分工，破局点就浮出来了：Excel 判断"是否受保护"只看sheet这个属性，而不是看密码是否正确。密码只在你要"主动撤销"时才会被拿来比对。换句话说，如果你直接把整个sheetProtection节点删掉，Excel 打开文件时会认为这个表从头到尾就没被保护过，压根不会去校验任何密码。

这就是整件事的核心原理——不是"破解密码"，而是"移除保护标记"。

2.3 那个四位十六进制串是怎么算出来的

顺便把password="83AF"这个值讲清楚，因为理解它能让你避开很多错误做法。

这是 Excel 沿用多年的一个传统哈希算法，输出固定 16 位（4 个十六进制字符）的值。算法本身在文件格式规范里是公开描述的，逻辑大致如下：

def excel_legacy_hash(password: str) -> str: h = 0 # 从后往前遍历每个字符 for ch in reversed(password): # 先做一次循环左移（15 位有效） h = ((h >> 14) & 0x01) | ((h << 1) & 0x7FFF) # 再和当前字符的码位异或 h ^= ord(ch) # 最后再移一次，混入密码长度和一个固定常量 h = ((h >> 14) & 0x01) | ((h << 1) & 0x7FFF) h ^= len(password) h ^= 0xCE4B return format(h, "04X")

这段代码有几个地方值得注意，都是新手容易想歪的：

它是单向的，没法反推。输出只有 16 位，而输入的可能有几十位字符，这在数学上就是多对一的映射。网上那些号称"输入哈希值直接算出原密码"的在线工具，原理其实是预先算了一张巨大的彩虹表——把所有常见短密码的哈希值都算一遍存起来，然后拿你给的值去查表。所以它能"算出"的只是常见短密码。你随手设一个十几位的随机串，这类工具就无能为力了。

它是有碰撞的。因为只有 16 位空间，不同的密码完全可能算出同一个值。这意味着：即使你不知道原密码，只要构造出另一个能算出相同哈希值的字符串，在"撤销保护"对话框里输入它，Excel 也会放行。老版本 Excel 里那些"随便输点什么就解开了"的玄学传说，就是碰撞导致的。

但这条路我不推荐你用。既然直接删节点就能解决，何必去凑一个碰撞串。多此一举，还容易出错。

现代版本为什么不用这个四位数了。你注意到上面那个 XML 例子里，属性变成了algorithmName="SHA-512"加hashValue加saltValue加spinCount这一组。这是因为老的四位哈希空间太小，保护强度实在太弱，微软在后来的版本里改用了标准哈希算法加盐和多轮迭代。spinCount="100000"意味着要迭代十万次，这是为了抬高暴力枚举的成本。

但这改变不了结论。无论密码校验数据用的是什么算法，它依然只是"撤销保护时需要比对的东西"。你把整个节点删掉，校验环节根本不会发生。这就是为什么这套"格式层面"处理的思路对 2007 到最新版本全部适用——因为保护的设计范式没变，变的只是校验数据的强度。

3. 不出任何工具，改一个 XML 就能把保护摘掉

原理清楚了，操作其实非常简单。但"简单"和"稳"是两件事，这一章的重点不是告诉你要改什么，而是告诉你怎么改不会把文件弄坏。我见过太多人在这里翻车：XML 改对了，重新打包的时候做错一步，Excel 直接弹"文件已损坏，无法打开"。

3.1 手工流程：六步，每一步都有讲究

先说手工版，适合只处理一两个文件的情况。

第一步，先备份。这不是废话。原文件复制一份到另一个目录，命名加上_原始备份。后面任何一步出问题，你都有退路，不用重头再来。我处理任何文件的第一动作永远是这个。

第二步，复制一份工作副本。不要直接动原文件。把副本改名成工作副本.zip。

第三步，解压到独立目录。注意选"解压到当前文件夹"或者新建一个同名文件夹，不要让压缩包里的文件散落在你当前目录的一堆文件中间。这一点看起来无关紧要，但它是第 7 章那个"文件损坏"坑的来源之一。

第四步，定位并编辑。打开xl/worksheets/下对应的 sheet XML，搜sheetProtection，把从<sheetProtection到/>的整段删掉。注意是整段，不是把sheet="1"改成sheet="0"——虽然改 0 有时候也能生效，但不同版本对sheet="0"的处理不一致，删干净是最保险的。

如果文件有多个工作表都被保护了，那就得逐个 sheet XML 检查，有的改有的不改。

如果只是想解除工作簿结构保护（不能增删移动工作表），去xl/workbook.xml里搜workbookProtection，同样处理。

第五步，保存时保持编码不变。这一步特别关键。文件必须保存为UTF-8 无 BOM。很多编辑器默认会加 BOM，加了之后 Excel 打开就报错。用支持查看编码的编辑器，保存前确认一下。

第六步，重新打包成 zip，再把后缀改回 xlsx。

这里有三条硬性要求，少了任何一条都可能打不开：

• [Content_Types].xml必须位于压缩包最外层，不能嵌套在任何文件夹里。
• 不要多出一层顶层目录。也就是说，如果你选中文件夹再右键压缩，包里会变成文件夹名/xl/...，这就错了。正确做法是进入文件夹，全选里面的内容，再压缩。
• 压缩方式选标准 deflate 即可，不要用某些工具特有的高压缩率格式。

做完这六步，双击打开，保护应该就没了。整个过程熟练之后不到三分钟。

3.2 为什么直接改 password 属性基本没用

这里要专门讲一个流传极广的错误做法，因为试过的人太多了。

网上有很多说法："把password="83AF"改成password=""就解开了"、"把 password 改成一个随便的值"、"把 password 属性删掉但保留节点"。这些做法在绝大多数版本里都不生效。

原因回到第 2 章的第三类属性：Excel 判断一个表是否受保护，看的是sheet="1"这一位。只要你保留sheetProtection节点并且sheet还是 1，表就是锁着的。至于password是什么值，Excel 根本不关心——它只在你想撤销保护的时候才去比对。

把password改成空串，结果就是：你点"撤销工作表保护"，Excel 弹框让你输密码，你输了，它拿去算哈希，和空串比对，不匹配，还是不放行。

同理，把password改成一个你以为能算出来的值也不行——除非你真的用 2.3 节那段代码算出对应关系，而且运气好没撞上算法版本差异。

正确的做法只有两条路：删掉整个节点，或者用代码算出正确的哈希值填进去再走正规撤销流程。前者简单得多，后者只在你不方便重新打包时才有意义。

3.3 脚本版：面对几十个文件时的手工流程替代方案

如果你手上是十几个、几十个历史归档文件，手工六步走一遍会崩溃。这时候写个脚本，用 Python 的zipfile直接原地重写，最省事。

下面这段代码的思路是：读原包 → 逐个成员复制到新包 → 遇到需要处理的 sheet XML 时先做文本替换 → 全部写完后替换原文件。这样做的好处是完整的流式复制，不会破坏压缩包里其他成员的结构。

import re import shutil import zipfile from pathlib import Path # 匹配整个 sheetProtection 节点（自闭合写法） SHEET_PROT_RE = re.compile(r"<sheetProtection\b[^>]*/>", re.IGNORECASE) # 兼容非自闭合写法：<sheetProtection ...></sheetProtection> SHEET_PROT_PAIR_RE = re.compile( r"<sheetProtection\b[^>]*>.*?</sheetProtection>", re.IGNORECASE | re.DOTALL, ) WORKBOOK_PROT_RE = re.compile(r"<workbookProtection\b[^>]*/>", re.IGNORECASE) def strip_protection(src: Path, dst: Path) -> tuple[bool, str]: changed = False with zipfile.ZipFile(src, "r") as zin, \ zipfile.ZipFile(dst, "w", zipfile.ZIP_DEFLATED) as zout: for item in zin.infolist(): data = zin.read(item.filename) # 只处理文本类的 XML，其他资源原样搬运 if item.filename.lower().endswith((".xml", ".rels")): try: text = data.decode("utf-8") except UnicodeDecodeError: zout.writestr(item, data) continue new_text = text if item.filename.lower().startswith("xl/worksheets/sheet"): new_text = SHEET_PROT_PAIR_RE.sub("", new_text) new_text = SHEET_PROT_RE.sub("", new_text) if item.filename.lower() == "xl/workbook.xml": new_text = WORKBOOK_PROT_RE.sub("", new_text) if new_text != text: changed = True # 关键：保持 UTF-8 无 BOM data = new_text.encode("utf-8") # 保留原成员的压缩类型与时间戳，减少“文件损坏”风险 info = zipfile.ZipInfo(item.filename, date_time=item.date_time) info.compress_type = zipfile.ZIP_DEFLATED info.external_attr = item.external_attr zout.writestr(info, data) return changed, "" def process_folder(folder: str) -> None: root = Path(folder) backup = root / "_原始备份" backup.mkdir(exist_ok=True) for f in root.glob("*.xlsx"): if f.name.startswith("~$"): continue # 跳过 Excel 打开时的临时文件 tmp = f.with_suffix(".tmp.xlsx") try: changed, _ = strip_protection(f, tmp) if changed: shutil.copy2(f, backup / f.name) # 先备份再覆盖 tmp.replace(f) print(f"[已处理] {f.name}") else: tmp.unlink() print(f"[无保护] {f.name}") except Exception as e: tmp.unlink(missing_ok=True) print(f"[失败] {f.name} -> {e}") if __name__ == "__main__": process_folder("./待处理")

几个必须说明的实现细节：

为什么用writestr(info, data)而不是write(filename)。因为write()会从磁盘重新读文件、重新判断压缩方式，容易在时间戳和权限位上产生偏差。用ZipInfo显式指定，可以最大程度保持原包结构一致，不明所以的"文件损坏"报错会少很多。

为什么要跳过~$开头的文件。那是 Excel 打开文档时生成的临时锁文件，本质是个二进制小文件，不是真正的文档。有些批量脚本没排除它，处理完一堆临时文件，还容易误改。这个细节踩过一次就记住了。

为什么对解码失败的文件直接原样搬运。压缩包里可能夹着图片、嵌入字体、OLE 对象，这些不是 UTF-8 文本，强行 decode 会抛异常。加一个except兜底最稳。

.xlsm也能这么处理。宏工作簿用的是同一套 OOXML 结构，VBA 代码存在xl/vbaProject.bin里，是个二进制块，脚本里会被当作"非 XML 文件原样搬运"，宏不会丢。只要把 glob 改成*.xlsm就行。这一点很重要——很多人担心处理完宏没了，其实完全不受影响。

4. 流传很广的几种"偏方"，哪些真能用哪些纯属浪费时间

我在各种场景下见过太多人在这上面折腾，这里集中做个对照。不是为了批判，而是让你遇到时能一眼判断值不值得试。

4.1 VBA 改 Protection 属性：取决于保护层级

流传最广的一段 VBA 是这样的：

Sub UnprotectSheet() Dim ws As Worksheet For Each ws In ActiveWorkbook.Worksheets ws.Unprotect Password:="" Next ws End Sub

它能不能用？分情况，而且大概率不行。

ws.Unprotect这个方法的行为是"用给定密码尝试撤销保护"。如果原密码不是空串，它就会失败，抛出运行时错误 1004。所以这段代码对设了密码的表是无效的。

它能生效的唯一场景是：表被保护了，但设密码时留空了。这种情况下，Unprotect Password:=""正好匹配，一下就开了。这也是为什么很多人说"这方法我用过，真的行"——他遇到的那份文件恰好没设密码，只是勾了保护。

顺带说一个必须提醒的点：分发给别人的文件，只勾保护不留密码，等于完全没保护。稍微懂一点的人两秒钟就开了。如果你的目的是"防误改"，这个强度勉强够；如果是"防有心人"，那就完全不够，需要往上走到文件级加密那一层。

4.2 几种常见做法的效果对照

把市面上流传的说法整理成一个表，比一条条看好得多：

4.3 "复制到新工作表"为什么有时候保护跟着走

这一条单独说，因为它反直觉，很多人试完一头雾水。

情况是这样的：你新建一个工作簿，把受保护表里的数据全选、复制、粘贴到新表。数据过来了，看起来一切正常。但有些时候你会发现，粘贴过去的表依然是受保护的，或者部分单元格还是改不了。

原因有两个层面。第一，如果你粘贴时选的是"保留源格式"或者整表粘贴，Excel 有可能把部分格式约束一起带过来。第二，更常见的是——你其实是在同一个工作簿内操作，新建的是 sheet 而不是 workbook，那么工作簿级的结构保护还在生效。

判断方法很简单：看"审阅"选项卡里"撤销工作表保护"这一项是不是可点。可点就是被保护了，点一下看有没有密码框弹出来，弹了就是设了密码。

这个方法的真正价值不在"解除保护"，而在于应急抢救数据。当你时间紧张、只想先把数据拿出来的时候，复制粘贴是最快的。但格式、条件格式、数据验证、图表、公式引用关系，多少都会有损失。所以只能作为临时方案，别当正解。

4.4 那些"绕过去"的思路，什么时候比"解掉"更划算

还有一种情况值得单独提：你其实不需要解除保护，只需要改数据。

工作表保护在设定时，可以留出"例外区域"。也就是说，某些单元格范围可以被允许编辑，其他区域锁着。做法是在保护之前，选中你要允许编辑的区域，右键"设置单元格格式 - 保护"，把"锁定"取消勾选，然后再去"审阅 - 保护工作表"。

如果你手上这个文件恰好设置了例外区域，你完全可以正常填数据，压根不用碰保护。所以打开文件后的第一件事应该是试着点一下你要改的单元格——如果它能选中、能输入，说明你压根不需要做后面任何操作。

这个提醒听起来像是废话，但我确实见过有人花了半小时处理一个其实本来就能编辑的表。先试，再动手。

5. 打开密码这一层：难度完全不是一个量级

前面四章讲的都是工作表保护。这一章把另一把锁单独讲清楚，因为很多人会拿同一套思路去套，然后彻底卡死。

5.1 加密文件为什么没有"技巧"可用

文件级加密之后，你拿到的是一个不透明的数据块。没有明文表名、没有 XML 结构、没有可以删的节点。你能做的只有一件事：猜一个密码，让算法跑一遍，看结果对不对。

这种攻击只有两种形态：

字典攻击。拿一个词表（常见密码、人名、日期组合、键盘序），逐个试。这种方式对"人类会设的密码"命中率相当高，因为大部分人的密码都在有限几个模式里。跑得快的话，每秒几十万次到上百万次不等，取决于硬件和加密轮数。

纯暴力枚举。按字符集穷举所有组合。用时随长度指数增长。一个八位纯小写字母的密码，组合数是 26 的 8 次方，约 2000 亿；如果换成大小写数字符号混排的十二位，这个数字会大到完全不具备现实意义。

这里有个容易被忽略的点：多轮密钥派生（也就是那个spinCount参数）的作用就是拖慢每一次尝试。十万轮迭代意味着单次验证的计算成本被抬高了好几个数量级，暴力枚举的速度直接掉下来。这是现代办公文档加密的标准做法。

所以结论很直接：这类文件如果不是你自己设的、又找不到设密码的人，基本就是无解。与其在这上面耗，不如去找文件的来源。这不是技术能力问题，是数学问题。

5.2 "修改权限密码"和"建议只读"，处理方式完全不同

这两个容易和工作表保护混淆，但它们有一个共同的好处：不加密内容，文件能正常打开。

遇到这类文件，标准做法是"打开 - 另存为 - 换个文件名"。因为限制的是"原地覆盖原文件"，不是"读取内容"。另存之后你得到一份完全可编辑的新文件，原文件保持不动。

"建议只读"更简单，它只是一个提示标志，打开时问你要不要只读进入，选否就直接进可编辑状态。这个标志位在文件属性里，有的版本可以在"文件 - 信息"里直接关掉。

真正需要留意的是：如果你的文件是从别人那里接收的，另存并修改之前，先确认对方是否希望你这么做。技术可行和业务合适是两件事。

5.3 合规边界：哪些文件不该动

这一段是硬性的，也是我做任何处理前的第一条自检。

能处理的：你自己创建的、你自己单位的、你明确获得授权处理的、以及无主的历史归档（比如接手的公共盘里年代久远的模板，并且你已经确认没有其他人在用）。

不该处理的：别人发给你的、带商业条款的、来源不明的、以及任何明确标注了访问限制的文件。哪怕技术上十秒钟就能打开，也不该动。这不是技术洁癖，这是基本的边界感。

还有一个务实的建议：处理之前先问一句"这文件是谁的、能不能改"。大多数时候，对方会直接告诉你密码，或者干脆重新发一份未保护的版本。省下来的时间比你自己折腾多得多。我经手的案例里，靠问一句话解决的比例，远高于靠技术手段解决的。

6. 换个方向：如果你想保住自己的表不被随手改

讲完了解除，反过来讲怎么设。因为大部分"需要解除"的局面，都是当初设的时候没设明白造成的——要么设得太松毫无作用，要么设得太死连自己都进不去。

6.1 保护工作表时那些勾选项到底在控制什么

点"审阅 - 保护工作表"，弹出来的对话框上半部分是密码框，下半部分是一长串复选框。很多人一路默认点确定，结果发现"连筛选都不让用"，然后又回来解保护。

这串复选框的含义是：勾上的项，表示在保护状态下"允许"执行。注意是"允许"，不是"禁止"。这个反直觉的设计坑了不少人。

几个高频的配置组合：

还有一个前置条件必须说清楚："锁定"这个属性是单元格格式的一部分，默认所有单元格都是锁定的。保护工作表只是把"锁定"这个属性生效化。所以要实现"部分区域可编辑"，正确顺序是：

1. 先选中允许编辑的区域
2. 右键 - 设置单元格格式 - 保护选项卡 -取消勾选"锁定"
3. 再回到"审阅 - 保护工作表"开启保护

顺序反了，什么区域都能改，或者什么区域都改不了，两种极端都出现过。

6.2 真要防篡改，工作表保护根本不够用

得把一个事实说明白：工作表保护防的是误操作，防不了刻意改动。

这不是实现缺陷，是设计定位。一个懂行的人拿到文件，删个节点、换个工具、复制数据，随便哪种都能绕过。所以如果你的需求是"这份数据不能被篡改"，正确的做法要往上走一层：

方案一，文件级加密。设打开密码，把内容真正加密。代价是对方必须知道密码才能看，协作便利性归零，只适合点对点传输。

方案二，加校验位。在表里加一列或一页，用公式算出关键数据的哈希或汇总值，对方改完数据后校验值对不上就能发现。这个方法不阻止修改，但能发现修改。

方案三，控制分发形态。需要给别人看的报表，直接导出成 PDF 或者图片，只发成品。需要别人填的模板，用在线表格的权限控制，比本地文件可靠得多。

方案四，版本留痕。关键数据表在共享盘里保留历史版本，或者定期另存带日期的快照。出了问题能回溯，这个比任何保护措施都实用。

我在实际项目里通常是"方案二 + 方案四"组合：加校验值让对方知道数据被动过，留版本快照让自己能查是哪一版变的。比起指望一个密码框能挡住所有人，这两条靠谱得多。

6.3 密码本身的管理：别让它变成三年后的麻烦

最后一条经验，纯粹是从无数"密码忘了"的案例里总结出来的。

密码要有登记。不管是放在密码管理工具里，还是团队共享的加密文档里，设了就要记。最怕的是"当时随手设了一个，觉得肯定记得住"。

密码要有交接。人员变动时，密码是必须交接的内容之一。很多死局都是这么来的：人走了，文件在，密码没了。

不要给临时文件设密码。一个只用三天的中间稿，加个密码，三个月后自己都想不起来。真正需要保护的文件才设，不是所有文件都要设。

分发文件时密码走不同渠道。文件用邮件发，密码用即时消息发。这个习惯成本几乎为零，但能避免很多"密码和文件一起躺在收件箱里"的尴尬。

7. 我在处理这类文件时踩过的几个坑

前面都是正路，这一章讲讲那些文档里不会写、但实操中一定会遇到的情况。这些内容没有理论价值，纯粹是省时间用的。

7.1 改完 XML 却提示"文件已损坏"，八成是这三件事

第一件，压缩包结构出了问题。这是最高频的。表现是双击打不开，提示"文件格式无效"或"内容有问题"。原因通常是：压缩包里多了一层顶层文件夹，或者[Content_Types].xml没在根目录。判断方法是把生成的 xlsx 再改名成 zip 打开，看第一层是不是直接就是[Content_Types].xml和xl/。如果不是，结构就错了。

第二件，编码带了 BOM。XML 文件被保存成 UTF-8 with BOM，Excel 解析时会在文档最前面遇到一个不可见字符，直接报错。用编辑器的"以 UTF-8 无 BOM 保存"选项，或者在脚本里明确用encode("utf-8")。

第三件，正则匹配把相邻节点吃掉了。这个坑很隐蔽。如果你用的是<sheetProtection.*?/>这种写法，碰上sheetProtection后面紧跟其他带/的节点，正则可能匹配到意想不到的位置，把 XML 结构破坏掉。稳妥写法是明确匹配[^>]*，并且同时处理自闭合和非自闭合两种形态——就是第 3.3 节代码里的写法。

排查顺序建议：先确认包结构，再确认编码，最后看 XML 是否合法（丢到任意 XML 校验器里跑一遍最快）。

7.2 xlsm、xls、共享工作簿，处理方式各不相同

xlsm 宏工作簿。结构和 xlsx 完全一样，第 3 章的脚本直接能用，宏不会丢。唯一要注意的是：处理完之后，如果原来的宏依赖了工作表保护状态，逻辑可能要跟着调整。

xls 老格式（2003 及更早）。这是另一种打包方式，属于复合文档结构，不是 zip，没法解压改 XML。处理路径有两条：一是用新版 Excel 打开另存为 xlsx，再走第 3 章流程；二是用专门的库去解析复合文档结构。前者简单得多，优先选前者。但要注意另存之后格式可能有细微变化，复杂图表和老式控件容易走样。

共享工作簿。这个坑最深。文件被设置为"共享"之后，里面有一块修订记录区域，用它自己的机制管协同。如果你直接改 XML 移除保护，很可能导致共享状态异常，多个人同时打开会出现冲突提示。遇到这类文件，正确做法是先在 Excel 里"取消共享工作簿"，处理完再重新开启共享。

受保护的工作簿结构 + 工作表保护同时存在。要两处都删——xl/workbook.xml里的workbookProtection，以及各个 sheet 里的sheetProtection。只删一处，表现出来的就是"能改单元格了，但还是不能新增工作表"，容易让人以为没处理干净。

7.3 批量处理时，怎么确认哪个 sheetN.xml 对应哪个标签

这是脚本化处理时最容易搞混的一点。xl/worksheets/下面的文件名是sheet1.xml、sheet2.xml，但它们的顺序和你在 Excel 底部看到的标签顺序不一定一致，尤其是在经历过增删、复制、移动的工作簿里。

正确做法是解析xl/workbook.xml里的<sheets>节点，它长这样：

<sheets> <sheet name="汇总表" sheetId="1" r:id="rId1"/> <sheet name="明细" sheetId="3" r:id="rId2"/> <sheet name="参数" sheetId="2" r:id="rId3"/> </sheets>

这里的r:id才是真正的线索，去xl/_rels/workbook.xml.rels里查这个 id 对应的文件路径：

<Relationships xmlns="..."> <Relationship Id="rId1" Target="worksheets/sheet1.xml" .../> <Relationship Id="rId2" Target="worksheets/sheet3.xml" .../> <Relationship Id="rId3" Target="worksheets/sheet2.xml" .../> </Relationships>

看，rId2对应的是sheet3.xml。如果你按文件名顺序去猜，就会改错表。

好在第 3.3 节的脚本是全量扫描xl/worksheets/下所有 sheet 文件，不依赖映射关系，所以天然避开了这个坑。这也是我倾向于脚本处理而不是手工定位的原因之一——手工定位时，改错表的概率比想象中高，而且改错了还不一定马上发现。

7.4 处理完之后，一定要做一次完整性自检

最后分享一个习惯。每次处理完一批文件，我会做三个检查，缺一不可：

第一个，能不能正常打开。这个不用多说。

第二个，数据量对不对。打开后看一眼最后一行、最后一列、行数统计，和原文件比一比。有些处理方式（比如转 CSV 再转回来）会悄悄丢掉前导零、长数字精度、日期格式，肉眼看不出，但数据已经变了。

第三个，抽查关键公式和格式。随便点几个带公式的单元格，看公式还在不在；看看条件格式、数据验证下拉框有没有失效。这些是最容易在重打包过程中受损的部分。

如果这三步都过了，基本就可以放心了。如果第二步发现问题，别犹豫，直接从备份恢复，换一种方式重来。在已经改动过的文件上做修补，比重做一遍麻烦得多——这也是为什么第一步永远是备份。

顺带说一个我用得比较顺手的扩展思路：如果这类处理是常态性的，可以在第 3.3 节的脚本基础上加一个"处理报告"，把每个文件动了哪几个 sheet、删了几处节点、处理前后的文件大小都记下来，输出成一份表格。批量处理几十个文件的时候，这份报告能让你在出问题时快速定位是哪个环节出的岔子，比事后一个个回查省太多时间。