5개의 문서가 포함된 PDF 포트폴리오을 만듭니다. Windows 컴퓨터에서 포트폴리오 파일 속성의 크기는 12MB로 표시됩니다. 동일한 파일을 Mac으로 전송하면 Finder에서는 15MB로 보고됩니다. Linux 시스템에서 열면 파일 관리자에 10MB가 표시됩니다. 파일은 동일합니다. 운영 체제마다 파일 크기를 다르게 계산하기 때문에 보고된 크기가 다릅니다.
운영 체제 간의 파일 크기 보고 차이는 일반적인 혼란의 원인입니다. 파일의 실제 바이트 수는 모든 곳에서 동일합니다. 차이점은 운영 체제가 표시를 위해 바이트를 킬로바이트, 메가바이트 또는 기가바이트로 변환하는 방법입니다.
운영 체제가 서로 다른 파일 크기를 보고하는 이유
근본 원인은 이진수와 십진수 단위의 혼동입니다. 컴퓨터는 파일을 바이트 단위로 저장하며, 이는 2의 거듭제곱으로 계산됩니다. 바이너리의 1킬로바이트는 1024바이트입니다. 1메가바이트는 1024킬로바이트, 즉 1,048,576바이트입니다. Apple macOS 및 Linux는 이러한 바이너리 단위를 사용하여 파일 크기를 보고합니다.
Microsoft Windows는 십진수 단위를 사용하여 파일 크기를 보고합니다. 여기서 킬로바이트는 1000바이트이고 메가바이트는 1,000,000바이트입니다. 동일한 파일은 10진수 단위가 더 작기 때문에 2진수 킬로바이트보다 더 많은 10진수 킬로바이트를 표시합니다. 1,048,576바이트인 파일은 Windows 십진수 표시에서는 1,024KB로 표시되지만 macOS 이진수 표시에서는 1,024KB 또는 1MB로 표시됩니다.
근본 원인은 대부분의 사람들이 예상하는 것보다 간단합니다.
PDF 파일 크기 불일치는 파일이 클수록 가장 두드러집니다. Windows 십진 단위의 100MB 파일은 macOS 이진 단위의 약 95MB입니다. 플랫폼 간 파일 크기를 비교할 때 5%의 차이는 혼란을 야기하기에 충분합니다.
보고된 파일 크기에 영향을 미치는 기타 요소
클라우드 스토리지 서비스는 스토리지의 파일을 압축하거나 중복 제거하기 때문에 로컬 파일 시스템과 다른 파일 크기를 보고할 수 있습니다. 클라우드 인터페이스에 표시되는 크기는 원본 파일 크기가 아닌 최적화 후 저장 크기입니다.
Windows의 NTFS 압축 또는 macOS의 APFS 압축과 같이 파일 시스템에 의해 적용되는 파일 압축은 사용되는 디스크 공간을 줄이지만 보고된 파일 크기를 변경하지는 않습니다. 보고된 크기는 압축되지 않은 파일 크기입니다.
PDF 보기 소프트웨어는 문서 속성 패널에서 다른 크기를 보고할 수도 있습니다. 일부 PDF 리더에서는 압축된 파일 크기가 아닌 압축 해제된 콘텐츠의 크기를 계산합니다. 문서 속성 크기와 파일 시스템 크기는 크게 다를 수 있습니다.
실제 파일 크기 확인
모든 운영 체제에서 동일한 파일의 정확한 바이트 수를 확인하십시오. Windows에서는 파일을 마우스 오른쪽 버튼으로 클릭하고 속성을 선택한 다음 크기 값(바이트)을 읽습니다. macOS에서는 파일을 선택하고 정보 가져오기를 선택합니다. Linux에서는 ls -l 명령을 사용합니다. 바이트 수는 실제입니다.
다른 운영 체제를 사용하는 동료와 파일 크기 사양을 공유할 때 단위와 계산 방법을 지정합니다. Windows의 10MB 파일은 macOS의 9.5MB 파일일 수 있습니다. 명확히 하면 혼란이 방지됩니다.
파일 크기 불일치의 실제적 의미
클라이언트가 보낸 파일의 크기가 예상과 다르다고 보고합니다. 단위 차이가 가장 그럴듯한 설명입니다. 파일 손상이나 전송 오류를 가정하기 전에 양측이 동일한 단위 정의를 사용하고 있는지 확인하십시오. 빠른 바이트 수 비교로 혼란이 해결됩니다.
이메일 첨부 파일 크기 제한은 일반적으로 이메일 서비스 제공업체에서 십진수 메가바이트로 지정합니다. Gmail의 25MB 제한은 2,500만 바이트를 의미합니다. Windows 10진수 단위로 25MB로 보고되는 파일은 한계에 도달했습니다. macOS에서 23.8MB로 보고되는 동일한 파일은 제한 내에서 안전하게 표시됩니다.
업로드 진행 상황을 표시하는 파일 전송 서비스는 프로토콜 오버헤드를 포함한 전송 크기를 계산하기 때문에 로컬 파일 시스템과 다른 파일 크기를 표시할 수 있습니다. 전송 인코딩을 위한 추가 바이트는 업로드 중에 보이는 파일 크기에 몇 퍼센트를 더할 수 있습니다.
플랫폼 전반에 걸쳐 파일 크기 보고 정규화
팀 또는 클라이언트 프로젝트의 파일 크기 사양을 문서화할 때 파일 크기를 바이트 단위로 지정하고 표시에 사용되는 단위를 지정합니다. 10,485,760바이트(10MB Windows, 10MiB macOS)를 읽는 사양은 모호성을 제거하고 일치하지 않는 파일 크기 보고서로 인해 반복되는 혼란을 방지합니다.
WukongPDF는 브라우저를 통해 PDF 포트폴리오와 개별 파일을 처리하여 운영 체제에 관계없이 일관된 파일 크기 정보를 표시합니다. 이러한 일관성은 다양한 플랫폼에서 작업하는 팀이 여기에 설명된 파일 크기 혼란을 방지하는 데 도움이 됩니다.
웹 인터페이스에 파일 크기를 표시하는 클라우드 스토리지 서비스는 일반적으로 서버 운영 체제와 동일한 단위 시스템을 사용합니다. 이는 일반적으로 Linux이므로 바이너리 단위입니다. Windows에서 업로드한 파일은 표시 단위가 변경되었기 때문에 클라우드 인터페이스에서 보면 축소된 것처럼 보일 수 있습니다.
문서 관리 및 보관 목적을 위해 문서 메타데이터 또는 보관 인덱스에 각 파일의 바이트 수를 기록합니다. 바이트 수는 명확하고 플랫폼 독립적입니다. 아카이브를 참조하는 미래의 사용자는 크기가 기록될 때 어떤 단위 시스템이 사용되었는지 추측할 필요가 없습니다.
PDF 포트폴리오 컨테이너 자체는 전체 파일 크기에 오버헤드를 추가합니다. 컨테이너 구조, 탐색 인터페이스 및 메타데이터는 포트폴리오의 파일 수에 관계없이 고정된 양으로 기여합니다. 작은 파일이 거의 없는 포트폴리오의 경우 컨테이너 오버헤드가 전체 크기의 상당 부분을 차지할 수 있습니다.
Windows의 NTFS 압축과 같이 파일 시스템에 의해 적용되는 압축은 사용되는 디스크 공간을 줄이지만 보고된 파일 크기를 변경하지는 않습니다. 파일 속성에 표시된 크기는 포트폴리오의 압축되지 않은 크기입니다.
PDF 포트폴리오가 네트워크 드라이브 또는 클라우드 동기화 폴더에 저장된 경우 로컬 파일 시스템에서 보고된 파일 크기는 원격 저장소에서 보고된 크기와 다를 수 있습니다. 로컬 시스템에 캐시된 복사본 크기가 표시됩니다.
포함된 파일 내에 포함된 파일이 포함된 포트폴리오 파일은 중첩된 압축 시나리오를 만듭니다. 보고된 크기는 압축이 풀린 내부 콘텐츠 크기의 합이 아니라 외부 컨테이너를 반영합니다.
일부 PDF 포트폴리오 뷰어는 포트폴리오가 열릴 때 포함된 파일을 추출하고 캐시하므로 포트폴리오 파일 자체를 넘어서는 추가 로컬 저장소 소비가 발생합니다. 캐시 크기는 보고된 포트폴리오 크기에 영향을 주지 않습니다.
시스템 간에 포트폴리오를 전송할 때 체크섬을 사용하여 파일 무결성을 확인하는 것이 보고된 파일 크기를 비교하는 것보다 더 안정적입니다. 체크섬이 일치하면 각 시스템이 크기를 보고하는 방식에 관계없이 파일이 동일한지 확인됩니다.
PDF 포트폴리오를 외부 수신자에게 배포하는 조직에서는 예상 파일 크기와 이를 결정하는 데 사용되는 플랫폼에 대한 메모를 포함할 수 있습니다. 이 메모는 일치하지 않는 파일 크기에 대한 지원 문의를 방지합니다.
PDF 포트폴리오에 대한 ISO 표준은 포함된 파일이 저장되고 참조되는 방법을 지정하지만 파일 관리자가 포트폴리오 크기를 계산하고 표시하는 방법을 표준화하지 않습니다. 디스플레이 표준이 없으면 플랫폼 변형이 발생합니다.
보관 저장소 계획의 경우 원본 시스템의 바이트 수를 신뢰할 수 있는 크기로 사용합니다. 파일 수와 평균 크기를 기반으로 한 아카이브 스토리지 용량 계산에는 플랫폼별 표시 값이 아닌 바이트 수를 사용해야 합니다.
파일 크기 표시가 플랫폼에 따라 다르다는 점을 이해하면 다른 운영 체제를 사용하는 동료가 동일한 포트폴리오 파일에 대해 다른 크기를 보고할 때 불필요한 문제 해결이 필요하지 않습니다.
| 플랫폼 | 단위계 | 1KB = | 1,048,576바이트에 대한 보고된 크기 |
|---|---|---|---|
| 윈도우 | 십진수(KB/MB) | 1000바이트 | 1,024KB(1.02MB) |
| macOS | 바이너리(KiB/MiB) | 1024바이트 | 1,024KiB(1.00MiB) |
| 리눅스 | 바이너리(KiB/MiB) | 1024바이트 | 1,024KiB(1.00MiB) |
| 클라우드(웹 UI) | 제공업체에 따라 다름 | 다양함 | 다양함 |
이진 단위와 십진 단위 사이의 혼동은 컴퓨팅 분야에서 오랜 역사를 가지고 있습니다. 500GB 드라이브가 465GiB 드라이브보다 더 크게 들리기 때문에 하드 드라이브 제조업체는 마케팅을 위해 소수점 단위를 채택했습니다. 운영 체제 개발자는 일반적으로 컴퓨터가 2의 거듭제곱으로 작동하기 때문에 이진 단위를 사용합니다. PDF는 수십 년 동안 지속된 단위 갈등의 한가운데에 있습니다.
PDF 포트폴리오를 이메일로 보낼 때 이메일 시스템은 또 다른 단위 규칙을 사용하여 첨부 파일 크기를 보고할 수 있습니다. Microsoft Outlook은 소수 단위를 사용합니다. Apple Mail은 바이너리 단위를 사용합니다. 동일한 첨부 파일이 두 이메일 클라이언트에서 서로 다른 크기로 나타납니다.
Dropbox, Google Drive, OneDrive와 같은 클라우드 저장소 서비스에는 각각 고유한 파일 크기 표시 규칙이 있습니다. Dropbox는 바이너리 단위를 사용합니다. Google 드라이브는 십진수 단위를 사용합니다. 두 서비스에 저장된 PDF 포트폴리오는 각 웹 인터페이스에서 크기가 다른 것으로 보입니다.
파일 크기가 제출 요구 사항에 지정된 법률 및 규정 제출의 경우 요구 사항에는 단위 시스템이 명시되어야 합니다. 파일 크기가 10MB 미만이어야 한다는 요구 사항은 모호합니다. 파일이 10,000,000바이트 미만이어야 한다는 요구 사항은 분명합니다.
파일 크기 보고 혼란에 대한 해결책은 간단합니다. 정확성을 위해 항상 파일 크기를 바이트 단위로 전달하고, 가독성을 위해 더 큰 단위를 사용할 때는 단위 시스템을 지정합니다. 12,582,912바이트의 파일 크기는 십진수로 약 12MB, 이진수로 12MiB입니다.
운영 체제 간의 파일 크기 보고 차이는 일반적인 혼란의 원인이며 크기를 바이트 단위로 전달하면 쉽게 해결됩니다.