💡 Contoh lengkap yang berfungsi tersedia di GitHub:
scrub-office-document-pii-dotnet
Cara Lama Sangat Menyakitkan
Rutinitasnya seperti ini. Buka dokumen, File, Info, Check for Issues, Inspect Document, centang kotak-kotak, Remove All, simpan dengan nama baru, tutup, buka yang berikutnya. Empat puluh file kemudian seseorang menyadari bahwa Inspect Document juga menghapus Title yang menjadi kunci indeks rekaman, dan bahwa salinan yang dikirim satu jam sebelumnya masih membawa ID approver SharePoint, karena file tersebut disimpan dari aplikasi berbeda yang menulis kembali field tersebut.
Penghapusan PII metadata adalah kemampuan GroupDocs.Metadata untuk .NET yang menghapus properti yang berisi identitas dari dokumen Office secara programatis dan melaporkan apa yang tersisa setelahnya. Rutinitas manual gagal dalam tiga hal: tidak dapat diskalakan lebih dari beberapa file, bersifat all-or-nothing mengenai field yang dihapus, dan tidak menghasilkan catatan apa yang dihapus. Artikel ini menunjukkan versi .NET dari pekerjaan yang sama, satu grup properti pada satu waktu.
Membantu untuk mengetahui apa yang sebenarnya ada di dalamnya. File Word yang telah melewati satu putaran review biasanya membawa Author dan LastSavedBy dari akun Windows orang yang menyimpannya, Manager dan Company dari template korporat, penghitung revisi, TotalEditingTime, timestamp LastPrinted, dan penghitung untuk thread komentar. Tambahkan SharePoint ke rantai dan Anda juga mendapatkan identifier approver, jalur workflow, URI content‑type, dan template yang digunakan untuk membuat dokumen. Semua itu tidak terlihat di halaman, dan semuanya berada dalam file yang sama.
Ada Cara yang Lebih Baik
Semua yang ada di GroupDocs.Metadata untuk .NET dijalankan melalui satu mesin pencari properti. RemoveProperties mengambil lambda atas MetadataProperty, menghapus setiap properti yang diterima lambda, dan mengembalikan jumlahnya. FindProperties menjalankan lambda yang sama tanpa menulis. Properti juga membawa tag, sehingga Tags.Person.Creator mengidentifikasi field bergaya penulis di seluruh format dan paket alih‑alih mencocokkan nama literal yang berbeda per aplikasi pembuat.
Itu memberikan tiga bentuk pembersihan alih‑alih satu tombol: satu pass tag untuk field identitas, pass nama untuk keluarga seperti komentar dan revisi, dan Sanitize() ketika tidak ada yang boleh bertahan. Ketiganya mengembalikan angka, dan angka‑angka itulah yang membuat proses dapat diaudit.
Cara Baru: Satu Predikat per Grup Properti
Langkah 1 - Bersihkan nama‑nama
Empat pemeriksaan tag mencakup grup identitas. Field deskriptif tidak tersentuh, yang merupakan perbedaan dari Remove All pada Document Inspector:
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;
}
Pemeriksaan FileFormat.Unknown adalah penjaga yang memastikan nilai nol tetap jujur: tanpa itu, file yang tidak dapat dibaca dan file bersih terlihat sama bagi pemanggil.
Langkah 2 - Bersihkan keluarga di sekitarnya
Komentar, revisi, dan field server tidak memiliki tag, sehingga predikat mencocokkan nama sebagai gantinya. Garis waktu penyuntingan adalah grup yang paling sering terlupakan, dan merupakan yang menjelaskan bagaimana dokumen diproduksi:
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;
}
Pencocokan substring bersifat sengaja: ia menangkap CommentsCount bersamaan dengan Comment, dan TotalEditingTime bersamaan dengan EditTime, tanpa harus memelihara daftar nama tepat per format. Pass SharePoint adalah pemanggilan yang sama dengan Server, Workflow, Approver, ContentType, dan Template.
Langkah 3 - Hapus semuanya, lalu periksa hasilnya
Di batas kepercayaan, satu pemanggilan menggantikan empat pass:
using (var metadata = new Metadata(inputPath))
{
if (metadata.FileFormat == FileFormat.Unknown) return 0;
var affected = metadata.Sanitize();
metadata.Save(outputPath);
return affected;
}
Kemudian bagian yang tidak memiliki padanan dalam rutinitas manual. Pemindaian verifikasi menggunakan kembali predikat penghapusan melalui FindProperties dan mengelompokkan yang tersisa ke dalam dua daftar:
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 harus kosong sebelum sebuah file dihitung sebagai disanitasi. ContentLevelLeaks bersifat informasional: komentar Word dan penulis tracked‑change berada di word/document.xml, yang merupakan konten tubuh, dan menghapusnya memerlukan perpustakaan penyunting konten seperti Aspose.Words alih‑alih API metadata.
Mengapa Tidak Langsung Memanggil Sanitize untuk Semua?
Karena sebagian besar dokumen masih digunakan. Sanitize() menghapus setiap paket yang terdeteksi, termasuk Title, Subject, dan Keywords, yaitu field yang menjadi andalan sistem rekaman dan indeks pencarian. Gunakan pass yang ditargetkan saat file beredar secara internal, pertahankan metadata deskriptif tetap berfungsi, dan sisihkan penghapusan total untuk salinan yang benar‑benar keluar dari organisasi.
Sisi‑Sisi: Sebelum vs. Sesudah
| Inspeksi manual | GroupDocs.Metadata untuk .NET | |
|---|---|---|
| Selektivitas | Remove All, termasuk bidang deskriptif | satu predikat per grup properti |
| Cakupan | bidang yang ditampilkan dialog | setiap paket yang terdeteksi perpustakaan, termasuk bagian OOXML khusus |
| Catatan | tidak ada | jumlah yang terpengaruh dikembalikan per operasi |
| Verifikasi | buka kembali dan lihat | FindProperties scan dengan daftar metadata dan konten‑level |
| Batch 200 file | 200 kali klik | satu loop, lima operasi, satu baris log per file |
Baris yang mengubah perilaku adalah catatan. Begitu setiap pass mengembalikan jumlah, sanitasi tidak lagi menjadi langkah yang diingat seseorang untuk dilakukan dan menjadi data yang dapat dipastikan oleh pipeline: ambang batas dalam tes, field dalam tabel audit, kondisi yang menyebabkan pekerjaan malam gagal. Itulah juga baris yang tidak dapat dihasilkan oleh rutinitas manual pada tingkat disiplin apa pun.
Contoh Dunia Nyata: Hook Pra‑Kirim
Portal dukungan memungkinkan staf melampirkan dokumen ke tiket pelanggan. Penangani lampiran kini menjalankan pass identitas dan pass server sebelum file disimpan, mencatat kedua jumlah tersebut pada tiket, dan menjalankan pemeriksaan kebocoran pada salinan yang disimpan. Daftar metadata‑leak yang tidak kosong menolak unggahan dengan pesan yang menyebut properti yang melanggar, sehingga orang yang melampirkan file langsung mengetahui masalahnya alih‑alih setelah sampai ke pelanggan.
Dua detail membuat hook tersebut praktis. Pass menulis ke jalur baru, sehingga file asli tetap di penyimpanan staf masing‑masing dan tidak ada yang dihancurkan oleh langkah otomatis. Dan jumlahnya masuk ke catatan tiket di samping lampiran, yang berarti jawaban atas “apa yang dihapus dari dokumen ini” adalah angka yang disimpan, bukan asumsi tentang apa yang biasanya dilakukan pipeline.
Saat pertama kali saya mengarahkan pemeriksaan itu pada template nyata, ia mengembalikan nilai Manager yang telah dihapus oleh pass identitas beberapa detik sebelumnya dan kemudian ditulis kembali oleh template korporat saat disimpan. Pemanggilan penghapusan bekerja persis seperti yang didokumentasikan; pipeline di sekitarnya yang menjadi masalah, dan hanya pembacaan kembali yang memperlihatkannya.
Apa Lagi yang Bisa Anda Lakukan dengan GroupDocs.Metadata?
Mesin predikat yang sama dapat membaca. Membandingkan properti antara dua versi dokumen menampilkan perubahan kepemilikan dan penulisan ulang di luar proses review, dan metadata scrubbing overview menjelaskan di mana alat interaktif masih cocok berdampingan dengan pass berbasis API. Karena sistem tag melintasi format, predikat identitas yang ditulis di sini juga dapat dijalankan pada PDF, gambar, dan file audio tanpa modifikasi.
Portabilitas itu layak direncanakan. Aturan pembersihan yang ditulis sebagai lambda atas MetadataProperty adalah C# biasa, sehingga dapat berada di pustaka bersama, diuji unit dengan dokumen fixture, dan diterapkan oleh layanan mana pun yang membutuhkannya: endpoint ekspor, pekerjaan rekaman terjadwal, atau langkah build yang men-sanitasi lampiran dokumentasi sebelum rilis. Aturannya tetap di satu tempat; hanya lokasi pemanggilan yang berubah.
Kesimpulan
Empat pass terarah, satu sanitize penuh, satu pemindaian verifikasi. Set tersebut mencakup rentang praktis untuk dokumen Office: pertahankan metadata deskriptif saat file beredar, hapus semuanya saat keluar, dan buktikan hasilnya dalam kedua kasus. Kloning contoh, jalankan pada dokumen yang telah melewati putaran review nyata, dan baca jumlah yang terpengaruh. Biasanya jumlahnya lebih tinggi dari yang diperkirakan, itulah intinya.