Čištění metadat Office v .NET: Od ruční kontroly po ověřený průchod

💡 Kompletní funkční příklad je k dispozici na GitHubu:
scrub-office-document-pii-dotnet

Starý způsob byl bolestivý

Rutina vypadá takto. Otevřete dokument, File, Info, Check for Issues, Inspect Document, zaškrtnete políčka, Remove All, uložíte pod novým názvem, zavřete, otevřete další. Po čtyřiceti souborech si někdo všimne, že Inspect Document také odstranil Title, na který se index klíčů záznamů odkazuje, a že kopie odeslaná hodinu dříve stále obsahovala SharePoint ID schvalujícího, protože soubor byl uložen z jiné aplikace, která pole znovu zapsala.

Odstranění PII z metadat je schopnost GroupDocs.Metadata pro .NET, která programově maže vlastnosti nesoucí identitu z Office dokumentů a hlásí, co po tom zůstane. Manuální rutina selhává ve třech ohledech: neškáluje se na více souborů, je všemocná (vše nebo nic) ohledně toho, které pole odebrat, a nevytváří žádný záznam o tom, co bylo odstraněno. Tento článek ukazuje .NET verzi stejné práce, po jedné skupině vlastností najednou.

Pomáhá vědět, co se v souboru skutečně nachází. Word soubor, který prošel revizním kolečkem, typicky nese Author a LastSavedBy z Windows účtu toho, kdo jej uložil, Manager a Company z firemní šablony, čítač revizí, TotalEditingTime, časové razítko LastPrinted a čítače pro vlákna komentářů. Přidáte-li do řetězce SharePoint, získáte také identifikátory schvalujících, cesty workflow, URI typů obsahu a šablonu, ze které byl dokument vytvořen. Nic z toho není viditelné na stránce a vše to cestuje ve stejném souboru.

Existuje lepší způsob

Vše v GroupDocs.Metadata pro .NET běží přes jeden vyhledávač vlastností. RemoveProperties přijímá lambda výraz nad MetadataProperty, smaže každou vlastnost, kterou lambda akceptuje, a vrátí počet smazaných položek. FindProperties spustí stejnou lambda funkci bez zápisu. Vlastnosti také nesou značky, takže Tags.Person.Creator identifikuje pole typu autor napříč formáty a balíčky místo porovnávání doslovných názvů, které se liší podle aplikace.

To poskytuje tři tvary úklidu místo jednoho tlačítka: průchod značkami pro identifikační pole, průchody názvy pro skupiny jako komentáře a revize a Sanitize(), když by nic nemělo přežít. Všechny tři vrací čísla a právě tato čísla činí průchod auditovatelným.

Nový způsob: Predikát pro každou skupinu vlastností

Krok 1 – Vymazat názvy

Čtyři kontroly značek pokrývají skupinu identity. Popisná pole zůstávají nedotčena, což je rozdíl oproti Document Inspector „Remove All“:

using (var metadata = new Metadata(inputPath))
{
    if (metadata.FileFormat == FileFormat.Unknown) return 0;
    var affected = metadata.RemoveProperties(p =>
        p.Tags.Contains(Tags.Person.Creator) ||
        p.Tags.Contains(Tags.Person.Editor) ||
        p.Tags.Contains(Tags.Person.Manager) ||
        p.Tags.Contains(Tags.Corporate.Company));
    metadata.Save(outputPath);
    return affected;
}

Kontrola FileFormat.Unknown je strážce, který udržuje nulu poctivou: bez ní by nečitelné i čisté soubory vypadaly pro volajícího stejně.

Krok 2 – Vymazat rodiny kolem nich

Komentáře, revize a serverová pole nemají značku, takže predikát porovnává názvy. Časová osa úprav je skupina, která se nejčastěji zapomíná, a je to právě ona, která říká, jak byl dokument vytvořen:

using (var metadata = new Metadata(inputPath))
{
    if (metadata.FileFormat == FileFormat.Unknown) return 0;
    var affected = metadata.RemoveProperties(p =>
        p.Name != null && (
            p.Name.Contains("Revision") ||
            p.Name.Contains("TrackedChange") ||
            p.Name.Contains("LastPrinted") ||
            p.Name.Contains("TotalEditingTime") ||
            p.Name.Contains("EditTime")));
    metadata.Save(outputPath);
    return affected;
}

Porovnávání podřetězců je úmyslné: zachytí CommentsCount spolu s Comment a TotalEditingTime spolu s EditTime, aniž by bylo nutné udržovat přesný seznam názvů pro každý formát. SharePoint průchod je stejný volání s Server, Workflow, Approver, ContentType a Template.

Krok 3 – Vymazat vše a pak zkontrolovat výsledek

Na hranici důvěry nahrazuje jeden volání čtyři předchozí průchody:

using (var metadata = new Metadata(inputPath))
{
    if (metadata.FileFormat == FileFormat.Unknown) return 0;
    var affected = metadata.Sanitize();
    metadata.Save(outputPath);
    return affected;
}

Pak následuje část, pro kterou manuální rutina nemá ekvivalent. Ověřovací sken znovu použije predikáty pro odstraňování přes FindProperties a roztřídí přeživší do dvou seznamů:

foreach (var p in props)
{
    var value = p.InterpretedValue?.ToString() ?? p.Value?.ToString() ?? string.Empty;
    if (string.IsNullOrWhiteSpace(value)) continue;
    if (value == "0" || value == "0.0") continue;

    var entry = $"{p.Name}={value}";
    var name = p.Name ?? string.Empty;
    if (name.StartsWith("Comment") || name.StartsWith("Revision"))
        report.ContentLevelLeaks.Add(entry);
    else
        report.MetadataLeaks.Add(entry);
}

MetadataLeaks musí být prázdný, aby byl soubor považován za sanitovaný. ContentLevelLeaks je informativní: Word komentáře a autoři sledovaných změn sídlí v word/document.xml, což je obsah těla, a jejich vymazání vyžaduje knihovnu pro úpravu obsahu, jako je Aspose.Words, spíše než API pro metadata.

Proč nevolat Sanitize na všechno?

Protože většina dokumentů je stále v používání. Sanitize() vymaže každý detekovaný balíček, včetně Title, Subject a Keywords, což jsou pole, na která se spoléhá systém záznamů a vyhledávací index. Používejte cílené průchody, dokud soubor cirkuluje interně, nechte popisná metadata fungovat a plné vymazání rezervujte pro kopii, která skutečně opustí organizaci.

Vedle sebe: Před vs. Po

Řádek, který mění chování, je Záznam. Jakmile každý průchod vrátí počet, sanitizace přestane být krok, na který si někdo pamatuje, a stane se datem, na které může pipeline tvrdit: práh v testu, pole v auditní tabulce, podmínka, která selže v nočním jobu. To je také řádek, který manuální rutina nedokáže vytvořit při žádné úrovni disciplíny.

Praktický příklad: Hook před odesláním

Portál podpory umožňuje zaměstnancům přikládat dokumenty k tiketům zákazníků. Manipulátor příloh nyní spustí identifikační průchod a serverový průchod před uložením souboru, zaznamená oba počty k ticketu a provede kontrolu úniku na uložené kopii. Seznam ne‑prázdných úniků metadat odmítne nahrání s hláškou, která uvádí porušující vlastnost, takže osoba přikládající soubor zjistí problém okamžitě, místo aby se objevil až po doručení zákazníkovi.

Dva detaily dělají tento hook praktickým. Průchody zapisují do nové cesty, takže originál zůstane v úložišti samotného zaměstnance a nic není zničeno automatickým krokem. A počty jsou uloženy v záznamu tiketu vedle přílohy, což znamená, že odpověď na otázku „co bylo z tohoto dokumentu odstraněno“ je uložené číslo, nikoli předpoklad o tom, co pipeline obvykle dělá.

Poprvé, když jsem tuto kontrolu nasadil na reálnou šablonu, vrátila hodnotu Manager, kterou identifikační průchod odstranil jen pár sekund předtím a firemní šablona ji při uložení okamžitě zapsala zpět. Volání odstranění fungovalo přesně podle dokumentace; problém byl v obklopující pipeline a jen zpětné načtení to odhalilo.

Co dalšího můžete dělat s GroupDocs.Metadata?

Stejný predikátový engine čte. Porovnání vlastností mezi dvěma verzemi dokumentu odhalí změny vlastnictví a přeautorizování mimo revizní proces a metadata scrubbing overview popisuje, kde interaktivní nástroj stále zapadá vedle API‑řízeného průchodu. Protože systém značek pokrývá formáty, identifikační predikát zde napsaný funguje také na PDF, obrázcích a audio souborech bez úprav.

Tato přenositelnost stojí za plánování. Pravidlo úklidu napsané jako lambda nad MetadataProperty je obyčejný C#, takže může žít ve sdílené knihovně, být jednotkově testováno na testovacích dokumentech a použito libovolnou službou, která to potřebuje: exportní endpoint, naplánovaný job pro záznamy nebo build krok, který sanitizuje přílohy dokumentace před vydáním. Pravidla zůstávají na jednom místě; mění se jen místa volání.

Závěr

Čtyři cílené průchody, jeden kompletní Sanitize, jeden ověřovací sken. Tento soubor pokrývá praktický rozsah pro Office dokumenty: zachovejte popisná metadata, dokud je soubor v oběhu, vymažte vše, když opustí organizaci, a výsledek vždy prokažte. Naklonujte ukázku, spusťte ji na dokument, který prošel reálným revizním kolečkem, a přečtěte si počty ovlivněných položek. Obvykle jsou vyšší, než se očekává, což je celý smysl.

Další zdroje

• Kompletní C# ukázkový projekt na GitHubu
• Průvodce krok za krokem
• Vyhledávání vlastností metadat
• Dokumentace GroupDocs.Metadata pro .NET
• Reference API
• Free support forum