Metadata PII ในกระบวนการทำงานเอกสารที่ควบคุม: การทำความสะอาดไฟล์ Office ใน Java

💡 ตัวอย่างการทำงานเต็มรูปแบบพร้อมให้ใช้งานบน GitHub:
remove-pii-from-office-metadata-java

ความท้าทายด้านการปฏิบัติตามกฎระเบียบ: ทำไมการตรวจสอบ Metadata ด้วยมือจึงล้มเหลวเมื่อขยายขนาด

ทีมบันทึกข้อมูลส่งเอกสาร 200 ฉบับให้ผู้ตรวจสอบภายนอก คนหนึ่งได้อ่านทุกหน้า แต่ไม่มีใครอ่านคุณสมบัติของไฟล์เลย และคุณสมบัติก็คือที่เก็บข้อมูลส่วนบุคคล: นักวิเคราะห์ใน Author, นักวิเคราะห์คนที่สองใน LastSavedBy, หัวหน้าฝ่ายใน Manager, บริษัทใน Company, เวลา LastPrinted จากคืนก่อนกำหนดส่ง, และบนไฟล์ใดที่ผ่าน SharePoint จะมีรหัสผู้อนุมัติและเส้นทาง workflow

การทำความสะอาด Metadata เป็น workflow ของ GroupDocs.Metadata สำหรับ Java ที่ลบคุณสมบัติที่บรรจุข้อมูลบุคคลออกจากไฟล์ Word, Excel, และ PowerPoint แล้วอ่านผลลัพธ์กลับมาเพื่อรายงานว่ามีอะไรเหลืออยู่ บทความนี้จะอธิบาย workflow ตามที่ทีมปฏิบัติตามกฎระเบียบจะสร้าง: กลุ่มคุณสมบัติใดบ้างที่มี, กฎการลบใดที่เหมาะกับแต่ละกลุ่ม, เมื่อใดที่การลบทั้งหมดแทนที่การลบแบบเจาะจง, และทำไมการตรวจสอบต้องอยู่ในงานเดียวกันแทนที่จะเป็นรายการตรวจสอบ

ปัญหาขนาดใหญ่ไม่ได้อยู่ที่การลบยาก แต่คือการตรวจสอบด้วยมือไม่สร้างบันทึก ผู้ตรวจสอบที่ถามว่า “ฟิลด์ใดบ้างที่ถูกลบจากไฟล์นี้และเมื่อไหร่” ต้องการตัวเลข แต่กล่องโต้ตอบคุณสมบัติไม่ให้ข้อมูลใดเลย

ทำไมเครื่องมือทำความสะอาดทั่วไปถึงใช้ไม่ได้ที่นี่

กล่องโต้ตอบคุณสมบัติของ Windows แก้ไขไฟล์ทีละไฟล์และเข้าถึงฟิลด์เพียงบางส่วน ตัวตรวจสอบเอกสารของ Office ทำงานแบบโต้ตอบ จึงไม่สามารถใช้ในงานประจำคืนได้ ทั้งสองวิธีทิ้งส่วน OOXML ที่กำหนดเองไว้โดยไม่มีการเขียนอะไรที่ pipeline สามารถอ่านกลับได้

ทีมที่ลงลึกระดับหนึ่งโดยแก้ไข docProps/core.xml และ docProps/custom.xml โดยตรง จะต้องรับภาระการบำรุงรักษา: นิพจน์ XPath ต่อฟิลด์ต่อรูปแบบ ซึ่งต้องทำใหม่ทุกครั้งที่แอปพลิเคชันที่สร้างไฟล์เปลี่ยนชื่อ งานนี้ยังทำให้คำถามการจัดประเภทผิดพลาดด้วย ชื่อคุณสมบัติจะแตกต่างกันระหว่างแพคเกจ ดังนั้นรายการชื่อจึงล้าสมัยโดยไม่รู้ตัว และกฎที่ไม่ตรงกับไฟล์ใด ๆ จะดูเหมือนไฟล์ที่สะอาดแล้ว

วิธีแก้: GroupDocs.Metadata ใน Workflow ของบันทึกข้อมูล

GroupDocs.Metadata สำหรับ Java ทำงานทั้งหมดผ่านเครื่องมือค้นหาคุณสมบัติเดียว วัตถุ Specification ตัดสินว่าคุณสมบัติใดตรงกับเงื่อนไข, removeProperties ลบแต่ละรายการที่ตรงและคืนจำนวนที่ได้รับผลกระทบ, ส่วน findProperties ทำการสแกนแบบอ่านอย่างเดียว คุณสมบัติมีแท็ก, ดังนั้น Tags.getPerson().getCreator() จะระบุฟิลด์สไตล์ผู้เขียนโดยไม่คำนึงถึงรูปแบบหรือแพคเกจที่มาจาก

Java ไม่มี lambda overload บน removeProperties ซึ่งกลับเป็นข้อได้เปรียบ: แต่ละกฎเป็นอ็อบเจ็กต์และอ็อบเจ็กต์เหล่านี้สามารถนำกลับมาใช้ใหม่ได้ ตัวอย่าง Specification เดียวที่ลบกลุ่มหนึ่งสามารถส่งต่อไปยังการสแกนตรวจสอบได้ ดังนั้นการตรวจสอบจะไม่หลุดจากการทำความสะอาดที่ต้องการทดสอบ

การสร้าง Pipeline ทำความสะอาดขั้นตอนต่อขั้นตอน

ขั้นตอนที่ 1 – ลบกลุ่มข้อมูลบุคคลตามแท็ก

สเปคแท็กสี่ตัวที่เชื่อมด้วย .or(...) ครอบคลุม creator, editor, manager, และ company. ไม่มีอะไรอื่นถูกย้าย ดังนั้น Title, Subject, และ Keywords จะยังคงใช้ได้สำหรับดัชนีบันทึก

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.removeProperties(
            new ContainsTagSpecification(Tags.getPerson().getCreator())
                .or(new ContainsTagSpecification(Tags.getPerson().getEditor()))
                .or(new ContainsTagSpecification(Tags.getPerson().getManager()))
                .or(new ContainsTagSpecification(Tags.getCorporate().getCompany())));
    metadata.save(outputPath);
    return affected;
}

การตรวจสอบ FileFormat.Unknown มีความสำคัญมากกว่าที่ดู. หากไม่มีการตรวจสอบนี้ ไฟล์ที่อ่านไม่ได้จะคืนค่าเป็นศูนย์การลบ ซึ่งผู้เรียกใช้ไม่สามารถแยกแยะได้ว่าเป็นไฟล์ที่สะอาดตั้งแต่ต้นหรือไม่

ขั้นตอนที่ 2 – ลบกลุ่มฟิลด์ตามชื่อ

เธรดคอมเมนต์, ตัวนับ revision, และฟิลด์เซิร์ฟเวอร์ไม่มีแท็ก จึงต้องจับคู่ตามชื่อ Specification ย่อยที่รับรายการส่วนย่อย (substring) หลายค่า ทำให้คลาสเดียวใช้ได้สามครั้ง:

public class NameContainsSpec extends Specification {
    private final String[] needles;

    public NameContainsSpec(String... needles) {
        this.needles = needles;
    }

    @Override
    public boolean isSatisfiedBy(MetadataProperty candidate) {
        String name = candidate.getName();
        if (name == null) return false;
        for (String n : needles) {
            if (name.contains(n)) return true;
        }
        return false;
    }
}

ไทม์ไลน์การแก้ไขเป็นสิ่งที่ทีมปฏิบัติตามกฎระเบียบให้ความสำคัญที่สุด เพราะจำนวน revision และวันที่พิมพ์ครั้งสุดท้ายบ่งบอกว่าเอกสารถูกสร้างอย่างไร:

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.removeProperties(new NameContainsSpec(
            "Revision", "TrackedChange", "LastPrinted", "TotalEditingTime", "EditTime"));
    metadata.save(outputPath);
    return affected;
}

การลบคอมเมนต์และการลบ SharePoint ใช้การเรียกเดียวกันแต่เปลี่ยนรายการส่วนย่อย: Comment, Reviewer, Reviewed สำหรับร่องรอยการตรวจสอบ, และ Server, Workflow, Approver, ContentType, Template สำหรับฟิลด์เซิร์ฟเวอร์เอกสาร

ขั้นตอนที่ 3 – ลบทั้งหมดที่ขอบเขต

เมื่อไฟล์ออกจากองค์กร การเลือกทำงานหยุดลง การเรียกครั้งเดียวนี้จะลบทุกแพคเกจ Metadata ที่ไลบรารีตรวจพบ รวมถึงส่วน OOXML ที่กำหนดเองที่ไม่มี predicate ใดมองหา:

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.sanitize();
    metadata.save(outputPath);
    return affected;
}

ขั้นตอนที่ 4 – ตรวจสอบและจัดประเภทสิ่งที่เหลืออยู่

การสแกนทำการรวมทุกกฎผ่าน findProperties แล้วจัดผลลัพธ์เป็นสองรายการ ค่าเปล่าและตัวนับศูนย์จะถูกข้าม, และรายการที่ชื่อเริ่มต้นด้วย Comment, Revision, หรือ Inspection เป็นการห่อหุ้มเนื้อหาตัวข้อความแทน Metadata:

String value = "";
if (p.getValue() != null && p.getValue().getRawValue() != null) {
    value = String.valueOf(p.getValue().getRawValue());
}
if (value.isEmpty() || value.equals("0") || value.equals("0.0")) continue;
String entry = p.getName() + "=" + value;
String name = p.getName() == null ? "" : p.getName();
if (name.startsWith("Comment") || name.startsWith("Revision")
        || name.startsWith("Inspection")) {
    report.contentLevelLeaks.add(entry);
} else {
    report.metadataLeaks.add(entry);
}

การแยกนี้ทำให้สัญญาณผลลัพธ์ผ่าน/ไม่ผ่านเป็นธรรม Metadata leaks ต้องว่างเปล่า ส่วน content‑level leaks จะเป็นข้อมูลเชิงข้อมูล เพราะคอมเมนต์ของ Word และผู้เขียนการเปลี่ยนแปลงที่ติดตามอยู่ใน word/document.xml และไลบรารี Metadata จะรายงานโดยไม่แก้ไข; การลบเหล่านั้นต้องใช้ไลบรารีแก้ไขเนื้อหาเช่น Aspose.Words

เมื่อใดที่การลบแบบเจาะจงดีกว่าการทำความสะอาดทั้งหมด?

เมื่อเอกสารถูกใช้ทำงานต่อไป ไฟล์ที่หมุนเวียนระหว่างผู้ตรวจสอบต้องการ Title, Subject, และ Keywords เพื่อการค้นหาและการจัดประเภทบันทึก, และ sanitize() จะลบทั้งสามอย่าง ใช้การลบข้อมูลบุคคลและคอมเมนต์ระหว่างการทำงานร่วมกัน, เก็บฟิลด์อธิบายไว้, แล้วทำการลบทั้งหมดเมื่อไฟล์ข้ามขอบเขตไปยังฝ่ายภายนอก

Workflow จริง: งานส่งออกสำหรับผู้ตรวจสอบภายนอก

ลองนึกภาพงานประจำคืน มันอ่านรายการ ID ของเอกสาร, คัดลอกไฟล์แต่ละไฟล์ไปยังโฟลเดอร์ staging, ใช้การลบข้อมูลบุคคลและการลบเซิร์ฟเวอร์, เรียก sanitize() กับไฟล์ใดที่ถูกระบุว่าออกจากองค์กร, แล้วรันการตรวจสอบการรั่วไหลกับสำเนาที่บันทึกไว้ แต่ละขั้นตอนจะเพิ่มจำนวนที่ได้รับผลกระทบลงในบรรทัดบันทึกหนึ่งบรรทัดต่อไฟล์, และรายการ metadata‑leak ที่ไม่ว่างเปล่าจะทำให้งานล้มเหลวแทนการบันทึกเป็นคำเตือน

ครั้งหนึ่งฉันใช้บ่ายหนึ่งกับเวอร์ชันของงานนี้ที่รายงานการลบศูนย์ไฟล์ 40 ไฟล์และดูเหมือนเป็นชุดที่สะอาด โฟลเดอร์อินพุตมีไฟล์ .doc แบบ legacy, การตรวจสอบรูปแบบคืนค่าเร็วในทุกไฟล์, และไม่มีอะไรในบันทึกที่แยก “ไม่มีอะไรให้ลบ” กับ “ไม่มีอะไรที่อ่านได้” การบันทึกรูปแบบพร้อมจำนวนทำให้แก้ได้

ผลกระทบต่อธุรกิจ: สิ่งที่เปลี่ยนแปลง

สถานการณ์อื่น ๆ ที่ GroupDocs.Metadata เหมาะสม

เครื่องมือค้นหาคุณสมบัติเดียวกันนี้อ่านได้เช่นเดียวกับการลบ การเปรียบเทียบ Metadata ระหว่างสองเวอร์ชันของเอกสารแสดงว่าการแก้ไขรอบใดเปลี่ยนแปลงอะไรบ้าง ซึ่งมีประโยชน์สำหรับข้อพิพาทความเป็นเจ้าของและการตรวจจับไฟล์ที่ถูกเขียนใหม่นอกกระบวนการ การทำงานกับ metadata tags แทนชื่อเป็นสิ่งที่ทำให้กรณีทั้งสองพกพาได้ข้าม DOCX, XLSX, PPTX, PDF, และรูปภาพ

เริ่มต้นใช้งาน GroupDocs.Metadata สำหรับ Java

เพิ่มรีโพซิทอรี GroupDocs Java ไปยัง pom.xml และระบุ dependency com.groupdocs:groupdocs-metadata ไลบรารีทำงานในโหมดประเมินผลโดยไม่มีลิขสิทธิ์ ซึ่งเพียงพอสำหรับรันหกการดำเนินการทั้งหมดกับตัวอย่าง DOCX และดูจำนวนผลลัพธ์ เริ่มด้วยการลบข้อมูลบุคคล, เพิ่มการลบกลุ่มฟิลด์ตามแหล่งเอกสารที่ต้องการ, แล้วเชื่อมการตรวจสอบการรั่วไหลก่อนที่ใด ๆ จะเข้าสู่การผลิต

แหล่งข้อมูล

• โครงการตัวอย่าง Java สมบูรณ์บน GitHub
• คู่มือการใช้งานแบบขั้นตอนต่อขั้นตอน
• การลบคุณสมบัติ Metadata
• เอกสาร GroupDocs.Metadata สำหรับ Java
• อ้างอิง API
• Free support forum