💡 Plně funkční příklad je k dispozici na GitHubu:
sanitize-office-document-pii-python
Data, která nikdo nezkoumá před odesláním
Čtvrtletní zpráva představenstvu je zaslána externímu auditorovi. Text je bez chyby; tři kola revizí to potvrdila. Soubor samotný je jiný příběh. Jeho vlastnosti stále uvádějí analytika, který jej vytvořil, manažera, který jej přepracoval, dceřinou společnost, která vlastní šablonu, časové razítko LastPrinted z noci před termínem a ID schvalovatele SharePointu z interního workflow. Žádná z těchto informací se neobjevuje na žádné stránce. Vše cestuje se souborem.
Odstranění PII je workflow GroupDocs.Metadata pro Python přes .NET, které programově odstraňuje tyto identifikační vlastnosti ze souborů Word, Excel a PowerPoint. Tento článek porovnává tři přístupy, které API nabízí: odstraňování řízené značkami pro pole identity, odstraňování podle vzoru názvu pro rodiny vlastností jako komentáře a revize a jednorázové volání sanitize(), které vymaže vše. Také uvidíte krok, který většina skriptů pro sanitaci přeskočí – ověřovací sken, který dokazuje, že úklid skutečně proběhl.
Proč metadata PII zasluhují vlastní pipeline
Nástroje pro kontrolu obsahu kontrolují, co lidé čtou. Nekontrolují, co souborové systémy ukládají, a právě tato mezera je zdrojem incidentů souvisejících s dodržováním předpisů. Požadavek GDPR zahrnuje osobní údaje v polích Author a Manager stejně jako data v textu. Právní discovery čte počítadla revizí a celkové časy úprav, aby rekonstruovalo, jak dlouho byl pozicový dokument vyjednáván. Recenzenti výběrových řízení mohou z mapovat vaši organizační strukturu z vlastností workflow SharePointu a pole komentářů tiskové zprávy uchovávají jména recenzentů spolu s poznámkami ve fázi návrhu. Každý z těchto údajů je nález. Žádný z nich není viditelný v těle dokumentu.
Požadavky
Před zahájením se ujistěte, že máte:
- Python 3 s pip
- GroupDocs.Metadata pro Python přes .NET, pevně nastavený ve vzorovém repozitáři na verzi 26.5
- Office soubor s reálnými vlastnostmi, na kterém můžete cvičit
Instalace
pip install groupdocs-metadata-net==26.5
Companion repository poskytuje ukázkový DOCX a spouští každý úryvek níže jako ověřený pipeline.
Metoda 1: Odstranění identity na základě značek
Nejcitlivější čtyři pole – Author, LastSavedBy, Manager a Company – mají v různých formátech Office různé interní názvy. Systém značek to řeší: místo pojmenování vlastností se predikát ptá na vše, co je označeno jako osoba nebo společnost.
# Match identity properties by meaning, not by format-specific name
with Metadata("board-report.docx") as metadata:
removed = metadata.remove_properties(lambda p:
Tags.person.creator in list(p.tags) # Author, LastSavedBy
or Tags.person.editor in list(p.tags)
or Tags.person.manager in list(p.tags)
or Tags.corporate.company in list(p.tags))
metadata.save("board-report-clean.docx")
print(f"{removed} identity properties removed")
Klíčové body:
- Formátová nezávislost: stejná lambda čistí DOCX, XLSX i PPTX, protože značky klasifikují podle role.
- Počitatelný výsledek:
remove_propertiesvrací počet shodujících se vlastností, což patří do vašeho auditního logu. - Kopírovací semantika: uložení do nové cesty zachovává originál pro vaše záznamy.
💡 Tip: tento průchod zachovává Title, Subject a další popisná pole, takže soubor zůstává přátelský pro vyhledávání a indexaci DMS.
Metoda 2: Odstraňování podle vzoru názvu pro rodiny vlastností
Značky pokrývají klasifikované koncepty. Celé rodiny únikových polí leží mimo tuto klasifikaci: vlastnosti komentářů, počítadla revizí, razítka workflow SharePointu. Pro tyto případy se porovnává samotný název vlastnosti.
# Comment fields often live in custom properties the tag system
# does not classify, so match them by name substring
with Metadata("board-report.docx") as metadata:
removed = metadata.remove_properties(lambda p:
p.name is not None and (
"Comment" in p.name
or "Reviewer" in p.name
or "Reviewed" in p.name))
metadata.save("board-report-no-comments.docx")
Stejný tvar řeší i další dvě rodiny; mění se jen seznam podřetězců:
| Rodina | Podřetězce k porovnání |
|---|---|
| Revision trail | Revision, TrackedChange, LastPrinted, TotalEditingTime, EditTime |
| Server / workflow | Server, Workflow, Approver, ContentType, Template |
Tento přístup vyměňuje přesnost za dosah: "Comment" zachytí také Comments a CommentCount, což je obvykle to, co sanitizační průchod požaduje. Široké podřetězce mohou zachytit i neškodná pole šablony, proto porovnejte vrácený počet s očekáváním.
💡 Tip: spusťte každou rodinu jako samostatný průchod, pokud váš auditní log potřebuje počty podle kategorií; sloučte podřetězce do jednoho predikátu, pokud to není nutné.
Metoda 3: Jednorázové úplné sanitování
Když soubor opouští organizaci a nic v metadata vrstvě by nemělo přetrvat, přestaňte psát predikáty.
# One call, every detected metadata package
with Metadata("board-report.docx") as metadata:
removed = metadata.sanitize()
metadata.save("board-report-final.docx")
print(f"sanitize() removed {removed} properties")
sanitize() vymaže každý balíček, který knihovna detekuje: identifikační pole dokumentu, komentáře, historii revizí, autory sledovaných změn a vlastní OOXML části. Chování je zdokumentováno na stránce Clean metadata. Jeho síla je zároveň jeho cena. Title a Subject zmizí spolu s PII, což je důvod, proč by se mělo používat na exportní bráně, nikoli uprostřed kolaborativního workflow.
Potřebuji všechny čtyři cílené průchody?
Ne. Každý průchod existuje, protože jiný tým vlastní dané riziko. Pole identity znepokojují úředníky pro ochranu soukromí, stopy komentářů znepokojují právní oddělení, počítadla revizí znepokojují vyjednavače a serverová pole znepokojují bezpečnost. Spusťte průchody, které odpovídají vašim recenzentům, v libovolném pořadí, protože každý zapisuje vlastní výstupní kopii. Když nikdo nepotřebuje zachovat žádná pole, přejděte rovnou na sanitize() a ověřte výsledek.
Porovnání tří přístupů
| Přístup | Nejlepší pro | Klíčové výhody | Omezení |
|---|---|---|---|
| Odstranění řízené značkami | Pracovní kopie, multi‑formátové pipeline | Formátová nezávislost, zachovává popisná pole | Pokrývá jen koncepty klasifikované značkami |
| Odstraňování podle vzoru názvu | Komentáře, revize, serverová pole | Dosahuje vlastností, které značky minou | Podřetězce je třeba ladit podle prostředí |
Plné sanitize() |
Konečný export mimo organizaci | Nemůže minout žádnou zapomenutou vlastnost | Vymaže i neškodná pole |
Přístupy se přirozeně doplňují: cílené průchody během životnosti dokumentu, sanitize() při odeslání.
Ověřte, než mu budete věřit
Vrácení počtu při odstraňování není důkazem, že je soubor čistý. Repo ukončuje každý běh opětovným otevřením sanitovaného výstupu a skenováním pomocí find_properties, s predikátem, který kombinuje pravidla značek i názvů ze všech výše uvedených průchodů.
def is_pii(p):
if p.name is None:
return False
return (
Tags.person.creator in list(p.tags)
or Tags.person.editor in list(p.tags)
or Tags.person.manager in list(p.tags)
or Tags.corporate.company in list(p.tags)
or any(n in p.name for n in (
"Comment", "Reviewer", "Revision", "TrackedChange",
"Classification", "Department", "Server", "Workflow")))
with Metadata("board-report-final.docx") as metadata:
for p in metadata.find_properties(is_pii):
value = (str(p.interpreted_value) if p.interpreted_value is not None
else (str(p.value) if p.value is not None else ""))
if value and value not in ("0", "0.0"):
print(f"LEAK {p.name}={value}")
Plná verze v repozitáři rozděluje přeživší položky do dvou košů a ten rozdíl je podstatný. Úniky metadat musí být nulové. Zbytky na úrovni obsahu – bubliny komentářů Wordu a sledované změny uvnitř word/document.xml – jsou tělesný obsah, který metadata API nedosáhne; jejich odstranění vyžaduje knihovnu pro úpravu obsahu, např. Aspose.Words. Poctivá zpráva uvádí oba koše místo toho, aby vyhlásila vítězství po prvním. Poprvé, když jsem spustil tento sken na „čistém“ souboru, zachytil pole Department, které firemní šablona tiše přidávala měsíce.
Nejlepší postupy a tipy
- Sanitizujte kopie, nikdy originály: každý úryvek zde zapisuje do nové cesty, čímž zachovává zdroj pro vaše záznamy a pravidla archivace.
- Logujte počty: návratové hodnoty
remove_propertiesasanitize()jsou vaším auditním trailem. Ukládejte je per soubor, per průchod. - Zapojte ověření do CI: kontrola úniku, která selže build, zachytí regresi šablon v den, kdy nastane, ne v den, kdy si to všimne klient.
- Myslete na hranici metadata/obsah: nikdy nehlaste soubor jako čistý, pokud v těle zůstávají komentáře; prezentujte je jako samostatný nález.
- Licencování: evaluační režim reprodukuje vše v tomto článku; v produkci použijte licenci, aby žádné evaluační značky nezasahovaly do odchozích souborů.
Závěr
Tři přístupy, jedno rozhodovací pravidlo. Používejte značky, když je koncept klasifikován a soubor musí zůstat užitečný. Používejte názvy, když rodina žije v vlastnostech uživatele. Zavolejte sanitize(), když soubor překračuje hranici důvěry, a ověřte pomocí zpětného skenu, jakou cestou jste šli.
Chcete jít dál? Zde jsou další kroky:
- Prostudujte povrch predikátu na stránce Remove metadata properties
- Sledujte step-by-step use case guide postavený na stejném kódu
- Naklonujte sample repository a spusťte ověřený pipeline na vlastních souborech
Další zdroje
- GroupDocs.Metadata Documentation
- API Reference
- Sample Projects on GitHub
- GroupDocs.Metadata Blog Category
Máte otázky nebo chcete sdílet svou implementaci? Kontaktujte nás na support forum.