파일을 이 사이트에 드롭해서 읽어 보았습니다. 어느 순간 누군가가 같은 작업을 당신이 작업 중인 애플리케이션 안에서 할 수 있는지 물어봅니다 — 사건 파일, 청구서, 도면 등을 다운로드하지 않고 직접 페이지에서 열 수 있는지 말이죠. 가능합니다, 그리고 결정은 생각보다 간단합니다. 실제로 바뀌는 것은 한 가지뿐이기 때문입니다.

바뀌는 한 가지: 파일이 가는 곳

여기서는 문서를 우리에게 업로드하면 렌더링하고, 닫으면 삭제합니다. 한 번만 전달받아 지금 읽고 싶은 파일에 적합한 방식이죠.

하지만 당신이 옮길 수 없는 문서에는 맞지 않습니다. 의료 기록, 서명된 계약서, NDA가 적용된 도면 등은 인프라를 떠날 수 없으며, 삭제 약속만으로는 해결되지 않습니다. 파일이 이미 이동했기 때문이죠. 렌더러를 임베드하면 상황이 뒤집힙니다: 문서는 서버에서, 당신의 네트워크 안에서 열리고, 브라우저에 전달되는 것은 렌더링 결과뿐입니다. 파일은 절대 이동하지 않습니다.

이것이 임베드해야 하는 이유이며, 그 외는 세부 사항일 뿐입니다.

이것은 위젯이 아니라 컴포넌트입니다

사람들이 처음에 잘못 이해하는 부분: 이것은 파일을 브라우저에서 여는 JavaScript가 아닙니다. 프로젝트에 참조하는 네이티브 .NET 컴포넌트이며, 렌더링은 서버 측에서 이루어집니다. 페이지는 그 결과만 받습니다.

두 가지 결과가 따릅니다. 좋은 점: 브라우저에 플러그인, ActiveX, 리더가 설치될 필요가 없으므로 잠긴 데스크톱이든 휴대폰이든 동일하게 동작합니다. 주의할 점: 서버가 작업을 수행하므로 200페이지 PDF와 40 MB 도면은 같은 요청이 아닙니다. 허용할 최대 파일 크기에 맞게 머신을 구성하고, 그보다 큰 파일은 업로드 단계에서 거부하세요.

시작하기 전에 결정해야 할 사항

세 가지 질문이 있으며, 모두 뷰어와는 직접적인 관련이 없습니다:

문서는 어디서 들어오나요 — 데이터베이스, 파일 공유, Blob 스토리지?
누가 이 문서를 볼 수 있나요, 그리고 뷰어 URL이 이를 강제하나요, 아니면 그냥 가정하나요? 문서 ID만 알면 누구든 접근할 수 있는 렌더링 엔드포인트는 전형적인 보안 구멍입니다.
렌더링이 생성하는 임시 파일은 어떻게 처리하고 언제 삭제하나요.

이 질문에 답하면 통합 작업 자체는 짧아집니다. 나중에 답을 미루면 이미 작동하는 뷰어에 권한 부여를 뒤늦게 적용해야 하므로 더 어려워집니다.

실행 환경

.NET Framework 4.0 이상, .NET Standard 2.0 이상을 지원하므로 WebForms, MVC, ASP.NET Core, Blazor Server, Linux 컨테이너 어디서든 사용할 수 있습니다. 서버에 Office가 설치될 필요도 없으며, 렌더러가 직접 포맷을 읽습니다.

오늘 하루에 한 파일만 읽고 싶다면 PDF 뷰어와 여기 있는 다른 뷰어들을 이용하면 됩니다. 만약 여러분이 생각하고 있는 것이 애플리케이션이라면, 컴포넌트와 패키지, API 문서는 Doconut.com에서 확인하세요.