Full working example available on GitHub:
strip-pdf-metadata-dotnet

소개

PDF 메타데이터 정화는 .NET용 GroupDocs.Metadata 워크플로우로, C# 서비스에서 PDF Info 사전과 XMP 식별 필드를 삭제합니다. 계약서 PDF가 내부 드라이브를 떠날 때 Author, Creator, Producer, Keywords 및 XMP 패킷이 함께 남는 경우가 많습니다. 브라우저 클리너와 빠른 Acrobat 검사는 성공적으로 보일 수 있지만 XMP는 여전히 원본 저자를 표시합니다. 파트너가 다른 뷰어에서 파일을 열었을 때 “정리된” 초안에 여전히 Alice Example이 Author로 표시되는 문제를 겪었습니다.

GroupDocs.Metadata for .NET은 동일한 Metadata 객체에 대해 두 가지 명확한 정화 강도를 제공합니다: 감지된 패키지를 모두 완전히 삭제하는 Sanitize()와 Title 및 Subject는 유지하면서 사람 식별 정보를 삭제하는 RemoveProperties. 이 문서는 결과를 감사 가능하게 만드는 검사 및 검증 단계와 함께 두 접근 방식을 비교합니다.

이 글을 통해 .NET 8 샘플을 실행하고, 외부 전송용과 보관 친화적 정화 사이의 결정 규칙을 이해하며, Save 후 PDF‑engine Creator/Producer 지문에 혼동되지 않도록 Author / Person.Creator를 확인하는 검증 식을 사용할 수 있게 됩니다.

PDF 메타데이터 정화가 중요한 이유

외부 파일 공유, 다중 테넌트 다운로드, 규제된 보관소 모두 데스크톱 클릭이 아닌 반복 가능한 메타데이터 제거 API가 필요합니다. 이 접근 방식이 특히 유용한 경우는 다음과 같습니다:

  • 파트너 포털: PDF가 신뢰 경계를 넘기 전에 완전 삭제
  • 레코드 검색: Title/Subject는 유지하면서 Author 스타일 필드만 삭제
  • 사고 대응: 잘못된 공유 후 Author가 사라졌음을 증명
  • CI 게이트: 검증이 false를 반환하면 빌드 실패

“메타데이터 제거”라는 한 줄 정책만으로는 Sanitize와 선택적 제거 사이의 차이를 감추게 됩니다. 코드 리뷰에서 강도를 명시하면 아카이브에 필요한 Keywords가 조용히 삭제되는 일을 방지할 수 있습니다.

사전 요구 사항

시작하기 전에 다음을 준비하십시오:

  • .NET 8 SDK
  • GroupDocs.Metadata 26.8.0 (임시 라이선스)
  • Info 및/또는 XMP 식별 필드가 남아 있는 PDF
  • Visual Studio 2022 또는 VS Code (선택)

설치

NuGet을 통해 GroupDocs.Metadata를 설치합니다:

dotnet add package GroupDocs.Metadata --version 26.8.0

또는 샘플 프로젝트의 .csproj에서 복원합니다. 제한 없는 Save를 위해서는 LIC_METADATA_VALID 환경 변수를 GroupDocs.Metadata.Product.Family.lic 파일이 들어 있는 폴더로 설정하십시오.

방법 1 - 정화하기 전에 검사하기

읽기 전용 목록을 먼저 생성하여 PDF가 실제로 어떤 필드를 가지고 있는지 확인합니다. 브라우저 도구는 XMP를 놓치는 경우가 많으며, 이 목록이 전후 비교의 기준이 됩니다.

using var metadata = new Metadata(inputPath);
var properties = metadata.FindProperties(p =>
    p.Tags.Contains(Tags.Person.Creator) ||
    p.Tags.Contains(Tags.Tool.Software) ||
    p.Tags.Contains(Tags.Content.Title) ||
    p.Tags.Contains(Tags.Content.Subject) ||
    string.Equals(p.Name, "Author", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Creator", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Producer", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Keywords", StringComparison.OrdinalIgnoreCase));

foreach (var property in properties)
{
    Console.WriteLine($"{property.Name} = {property.Value}");
}

핵심 포인트:

  • 태그와 이름 모두 검사: 필드를 다르게 태깅하는 프로듀서도 Author / Keywords 이름으로 잡아냅니다.
  • 변경 없음: 드라이런 모드와 지원 티켓에 안전합니다.
  • 공유 필터: 나중에 제거 프레디케이트에서도 동일한 아이디어 재사용 가능

방법 2 - 감지된 모든 메타데이터 정화하기

PDF에 저자 흔적이 전혀 남지 않아야 할 경우 Sanitize()를 사용합니다. 이 호출은 Info 사전 필드와 API가 감지한 XMP를 포함한 모든 인식된 패키지를 삭제하고, 새 파일을 저장합니다.

using var metadata = new Metadata(inputPath);
int removed = metadata.Sanitize();
Console.WriteLine(removed);
metadata.Save(outputPath);

핵심 포인트:

  • 한 번 호출: 외부 경로에 적합한 작은 표면
  • 삭제 개수 로그: 운영자는 이미 정리된 입력과 대규모 삭제를 구분할 수 있음
  • 툴 스탬프 예상: Save 후 Creator/Producer에 PDF‑engine Tool.Software 값이 표시될 수 있음

가장 적합한 상황: 파트너 다운로드, 공개 링크, 테넌트 간 교환.

방법 3 - 저자 스타일 속성만 제거하기

Title, Subject, Keywords가 검색에 필요하지만 사람 식별 정보는 제거하고 싶을 때 RemoveProperties를 사용합니다.

using var metadata = new Metadata(inputPath);
int removed = metadata.RemoveProperties(p =>
    p.Tags.Contains(Tags.Person.Creator) ||
    p.Tags.Contains(Tags.Person.Editor) ||
    string.Equals(p.Name, "Author", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Creator", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Producer", StringComparison.OrdinalIgnoreCase));
Console.WriteLine(removed);
metadata.Save(outputPath);

핵심 포인트:

  • 프레디케이트 검토 가능: 코드 리뷰에서 정확히 어떤 식별 필드가 삭제되는지 확인 가능
  • 설명 필드 유지: Title/Subject/Keywords는 이 샘플 필터로 남음
  • 동일 SDK: 선택적 경로에 별도 라이브러리 필요 없음

가장 적합한 상황: 내부 보관소, 초안 순환, Author는 금지하지만 키워드는 허용하는 정책.

Save 후 Author 제거를 어떻게 증명할까?

정리된 PDF를 다시 열고 Author / Person.Creator / Person.Editor만 검색합니다. 남은 것이 없으면 True를 출력합니다. 잔여 Creator/Producer Tool.Software 지문은 Save가 PDF 엔진 이름으로 다시 기록할 수 있으므로 실패로 간주하지 마십시오. 이 구분이 CI에서 컴플라이언스 검사를 정확하게 만들고 엔진 자체 필드 때문에 잘못된 경보가 울리는 것을 방지합니다.

using var metadata = new Metadata(inputPath);
var leftovers = metadata.FindProperties(p =>
    p.Tags.Contains(Tags.Person.Creator) ||
    p.Tags.Contains(Tags.Person.Editor) ||
    string.Equals(p.Name, "Author", StringComparison.OrdinalIgnoreCase));

Console.WriteLine(!leftovers.Any());

핵심 포인트:

  • 올바른 질문: “Author가 사라졌는가?”가 “Creator가 비어 있는가?”보다 중요
  • 두 번째 열기: Save 후에 검증, 메모리 상만이 아니라
  • CI 친화적: 테스트와 로그에 사용할 수 있는 하나의 불리언

Sanitize와 RemoveProperties 중 선택하기

질문 Sanitize 선호 RemoveProperties 선호
파일이 회사를 떠나나요? 예 설명 필드가 유지되어야 할 경우에만
아카이브 검색에 Title이 필요합니까? 아니오 예
정책에 “메타데이터에 사람 정보 금지"라고 적혀 있나요? 둘 다 가능, 이후 검증 예, 사람 중심 프레디케이트 사용
운영자가 한 번의 버튼을 원하나요? 예 명명된 라우트 뒤에 래핑

strip-pdf-metadata-dotnet은 Resources/contract-with-metadata.pdf를 대상으로 네 단계를 모두 연결한 실행 가능한 .NET 데모이며, 검사, 정화, 선택적 제거, 검증을 한 번의 콘솔 실행으로 확인할 수 있습니다.

흔히 하는 실수

  • 브라우저 클리너만 신뢰: XMP는 종종 남아 있습니다.
  • Creator/Producer 이름 검증: Save 후 엔진 지문 때문에 거짓 실패가 발생합니다.
  • 하나의 프레디케이트를 영구 사용: 새로운 프로듀서가 등장하면 식별 필드 이름을 다시 검토해야 합니다.
  • Save를 위한 라이선스 설정 누락: 평가 모드에서는 무제한 쓰기가 차단됩니다. 전체 파이프라인 테스트를 위해 LIC_METADATA_VALID를 설정하십시오.
  • 검사 단계 생략: 사전 목록이 없으면 Sanitize가 7개의 필드를 삭제했는지 0개를 삭제했는지 알 수 없습니다(파일이 이미 깨끗했을 수도 있음).

샘플 contract-with-metadata.pdf를 사용하면, 라이선스가 적용된 실행 시 검사 단계에서 Author와 Keywords가 출력되고, Sanitize 삭제 개수는 약 7, Author‑중심 검증은 True를 반환합니다. 선택적 저자 제거는 약 3개의 작은 개수를 출력하면서 Title과 Subject는 두 번째 검사에서 그대로 보입니다.

추가 자료

결론

.NET에서 PDF 메타데이터 정화는 모호한 이름의 단일 API 호출이 아닙니다. 외부 전송을 위해서는 Sanitize()를, Title과 Subject를 유지해야 할 경우에는 RemoveProperties를 선택하고, 항상 Save 후 Author‑스타일 필드를 검사·검증하십시오. 샘플 저장소를 복제하고 시드된 계약 PDF에 실행한 뒤, 동일한 메서드를 로깅과 함께 업로드 서비스에 적용하면 됩니다.