요약

  • RFC 2083는 PNG 청크 유형의 네 바이트 각 글자에 하나의 속성 비트를 담았습니다: 필수 여부, 공개 여부, 예약 여부, 그리고 복사 가능 여부입니다.
  • 네 번째 비트는 진실 표시가 아니라 편집기 규칙이었습니다. 복사 안전하다고 알려지지 않은 보조 청크는 변경 사항을 거쳐 살아남을 수 있고, 복사 안전하지 않은 미지 청크는 필수 이미지 데이터가 변경된 뒤에는 제거해야 했습니다.
  • 보존된 청크와 일치하는 CRC는 경계가 명확한 바이트 보관을 입증했을 뿐입니다. 이는 사적 이름의 고유성, 의미적 최신성, 저작자, 허가, 프라이버시 또는 이미지 주장의 정확성을 입증하지 않았습니다.

편집기가 PNG를 열어 이미지의 색을 바꾸고 새 IDAT 데이터를 쓴다고 상상해 보십시오. 익숙한 청크들 사이에 편집기가 한 번도 본 적 없는 유형이 놓여 있습니다. 이미지는 그것 없이도 디코딩될 수 있으므로 이 청크는 보조 청크로 보입니다. 그 데이터는 히스토그램, 사내 워크플로 상태, 물리적 캘리브레이션 또는 전혀 다른 무엇이든 설명할 수 있습니다. 편집기는 그 의미를 추론할 수 없습니다. 그런데도 출력에 그 미지의 바이트를 넣을지 말지를 결정해야 합니다.

이것이 RFC 2083이 푼 좁은 엔지니어링 문제였습니다. 이 규격은 오래된 프로그램에게 미래의 모든 확장을 이해하라고 요구하지 않았습니다. 대신 확장 자체가 미지일 때에도 읽힐 수 있는 작은 결정 표면을 프로그램에 주었습니다. ASCII 글자 대소문자로 표현된 네 비트 위치가 디코더가 무시할 수 있는 것, 이름이 속한 네임스페이스, 편집기가 변경을 거쳐 운반할 수 있는 것을 나눴습니다.

네 글자는 네 개의 별개 지시였다

PNG 청크는 길이, 네 바이트 유형 코드, 데이터, 네 바이트 CRC를 담습니다. 유형 바이트는 ASCII 글자 범위로 제한되지만 구현체는 이를 고정된 이진 값으로 취급하라는 지시를 받습니다. 로케일에 민감한 대소문자 변환은 틀린 동작입니다. 관련 있는 사실은 각 바이트의 비트 5, 값 32입니다.

첫 글자는 필수 여부를 표시합니다. 대문자는 필수를 뜻합니다: 미지 유형이 이미지 해석에 필요한 정보를 담고 있을 수 있으므로 디코더는 파일을 이해한다고 가장해서는 안 됩니다. 소문자는 보조를 뜻합니다: 디코더는 미지 청크를 무시하고 이미지 표시를 계속할 수 있습니다. 이는 무지에 대한 폴백 규칙이지 중요도의 순위가 아닙니다. 저작권 텍스트, 캘리브레이션 데이터, 타임스탬프는 사람에게 매우 중요하면서도 표시 가능한 픽셀 추출에는 보조로 남을 수 있습니다.

두 번째 글자는 공개 청크 이름과 사적 청크 이름을 나눕니다. 대문자는 공개 이름, 소문자는 사적 이름을 표시합니다. RFC 2083은 이 비트를 디코더 동작 스위치가 아니라 행정적 편의로 다뤘습니다. 이는 미래의 공개 할당을 사적 네임스페이스 바깥에 두었지만, 고유한 사적 이름을 할당하지는 않았습니다. 두 조직이 같은 사적 유형을 호환되지 않는 의미로 쓸 수도 있었습니다. 그래서 규격은 사적 청크 데이터 안에 추가 식별 정보를 넣을 것을 권했습니다.

세 번째 글자는 예약되어 있었습니다. 규격 부합 Version 1.0 이름은 그 자리에 대문자를 썼고, 디코더는 미래 파일이 소문자 형태를 쓴다고 해서 실패해서는 안 된다고 지시받았습니다. 이 규칙은 오래된 구현체가 그 의미를 발명하게 강요하지 않으면서 이후 확장의 공간을 보존했습니다.

네 번째 글자는 편집을 다룬다는 점에서 달랐습니다. 소문자는 복사 안전, 대문자는 복사 안전하지 않음을 뜻했습니다. 순수 디코더에게 이 답은 필요 없었습니다. 변경된 데이터스트림을 쓰는 프로그램에게는 필요했습니다.

RFC 2083은 가상 이름bLOb으로 이 전체 코드를 설명했습니다: 보조, 공개, 예약 비트 클리어, 복사 안전. 글자들은 장식이 아니었습니다.TEXT와Text는 하나의 이름을 두 가지 스타일로 쓴 것이 아니라 서로 다른 이진 유형 코드입니다.

복사 안전은 정의된 편집 하에서의 안전이지 영원한 진실이 아니었다

복사 안전으로 알려지지 않은 보조 청크는 편집기가 조금 바꾸든 많이 바꾸든 복사될 수 있었습니다. 복사 안전하지 않다고 알려지지 않은 보조 청크는 의존성 경고를 담았습니다. 필수 청크가 추가, 삭제, 수정 또는 재정렬되었다면 편집기는 그 미지 청크를 출력에서 생략해야 했습니다. 보조 청크만 바뀌었다면 보존할 수 있었습니다.

이 구분은 보편적 지식을 요구하지 않으면서 보관 책임을 배정했습니다. 확장 저작자는 미지의 소프트웨어가 이미지의 필수 표현이 바뀐 뒤 바이트를 안전하게 보관할 수 있는지를 선언했습니다. 편집기는 자신의 수정 클래스를 관찰하고 결정적 분기를 만들었습니다. 둘 다 편집 시점에 중앙 기관에 물을 필요가 없었습니다.

이 거래는 확장 설계에 한계를 부과했습니다. 보조 청크는 필수 청크에 의존할 수 있었지만 다른 보조 청크에 의존해서는 안 됐습니다. 전체 데이터스트림에 대한 의존성은 하나의 복사 안전 비트로 표현될 수 없었습니다. RFC 2083은 그런 설계를 만류했습니다; 필수로 만드는 것도 가능했지만, 모르는 디코더와 편집기가 멈추어야 하므로 이식성이 떨어질 것이었습니다.

현재의W3C PNG 제3판은 같은 구분을 유지하면서 정렬 규칙을 더 정밀하게 다듬습니다. 미지의 복사 안전하지 않은 보조 청크를 복사하는 편집기는 그것을 필수 청크에 상대적으로 이동해서는 안 됩니다. 미지의 복사 안전 청크조차 IDAT 이전에서 IDAT 이후로 또는 그 반대로 옮길 수 없습니다. 그러므로 복사 안전은 결코 제약 없는 재배치의 안전을 뜻하지 않았습니다.

CRC는 하나의 바이트 질문을 닫고 의미 질문을 열어 두었다

모든 PNG 청크는 유형과 데이터 필드에 걸친 CRC를 담습니다. CRC는 그 커버된 바이트의 우발적 손상을 드러낼 수 있습니다. 별개의 CRC들은 크기 같은 필수 정보를 일찍 검증하게 해줍니다. RFC 2083은 또한 하나의 사적 청크가 자신이 의존하는 청크(예: PLTE)의 CRC를 저장해 그 의존성이 바뀌었는지 감지할 수 있다고 제안했습니다.

그것은 유용한 증거지만 해석 엔진은 아닙니다. 일치하는 CRC는 누가 청크를 썼는지, 유형 이름이 다른 사적 사용과 충돌했는지, 그 주장이 승인되었는지, 그 의미가 새로 편집된 픽셀과 여전히 맞는지 말해 주지 않습니다. 바이트를 다시 쓴 뒤 CRC를 재계산하는 것은 그 재작성의 정당성에 대해 더 적은 것을 보여줍니다: 그것은 새 기록이 체크섬 규칙 하에서 내부적으로 일관됨을 보여줄 뿐입니다.

이는 시각적 변화를 거쳐 살아남는 메타데이터에서 중요합니다. 이미지 데이터의 잘라내기, 색 변경 또는 교체는 보조 설명을 구문적으로 온전히 남기면서 실질적으로 낡게 만들 수 있습니다. 반대로 모든 미지 청크를 버리면 유효하게 남도록 설계된 정보를 파괴할 수도 있습니다. 네 번째 비트는 진실을 해결하지 않습니다. 무지한 편집기가 확장 저작자가 필수 이미지 데이터에 선언한 의존성을 추측해야 하는 상황을 막을 뿐입니다.

제3판의 프라이버시 논의는 더 넓은 경계를 보여줍니다. 일부 도구는 역사적으로 복구 가능한 이미지 데이터를 제거하지 않은 채 알파나 크기 변경으로 픽셀을 숨겨 왔고, eXIf도 위치 정보를 담을 수 있습니다. 이들은 완전한 데이터스트림과 편집의 효과를 검사해야 할 이유입니다. 그렇다고 복사 안전이 프라이버시 분류로 바뀌지는 않습니다.

포맷은 하나의 전역 번호를 바꾸는 대신 기능별로 성장했다

RFC 2083은 PNG 서명이나 파일의 어디에도 버전 번호를 넣지 않기로 했습니다. 그 근거는 실용적이었습니다. 전역 버전 번호는 파일이 디코더가 이해할 필요가 없는 기능을 전혀 쓰지 않았는데도 번호가 높다는 이유만으로 오래된 디코더가 파일을 거부하게 만들 수 있었습니다. 또한 사적 확장에 대해서는 거의 아무것도 말해 주지 않았습니다.

청크 속성들은 호환성을 세분화했습니다. 미지의 보조 기능만 도입한 새 파일은 오래된 디코더에서 계속 사용 가능했습니다. 미지의 필수 기능은 거부를 강제했습니다. 사적 확장은 합리적인 이미지를 얻는 데 필수적인지 여부에 따라 두 동작 중 하나를 선택할 수 있었습니다. 호환성은 문서 전체 배지가 아니라 실제로 존재하는 기능에 의해 결정되었습니다.

현대의 확장 기록도 같은 패턴을 보여줍니다. W3C의PNG 확장 문서는 코어 규격과 별도로 추가 공개 청크를 나열하며 실제 파일에서 만날 수 있는 미등록 유형을 언급합니다. 등록, 인식, 의미 지원은 별개의 사실입니다. 공개는 정의를 사용 가능하게 만들 뿐이며, 디코더를 설치하거나 편집기가 올바른 의미를 보존했음을 증명하지 않습니다.

Lu Heng의 이후 글인최소 초기 규격과 지역화된 미래 결정은 유용한 회고적 렌즈를 제공합니다. PNG는 얇은 공통 문법—청크 프레이밍, 속성 비트, 지역 검증 규칙—을 고정한 뒤, 소프트웨어가 실제로 실행하는 기능에 따라 확장을 수용, 무시 또는 거부하게 두었습니다. 이는 시간을 넘는 비교일 뿐, 1997년 저자들이 2026년에 쓰인 이론을 따랐다는 주장이 아닙니다.

더 근본적인 교훈은 증거적입니다.현실 층위 구분은 실행 가능한 규칙과 그에 붙은 서사를 분리합니다. PNG 편집기에서 속성 비트, 편집 클래스, 그 결과의 복사/제거 동작은 실행 가능합니다. “공식적”, “안전한”, “정확한”, “승인된” 같은 주장은 더 큰 주장입니다. 이들에는 청크 이름 문법에 담기지 않는 증거가 필요합니다.

영수증은 실제로 내려진 결정을 명명해야 한다

PNG 변환에 대한 감사는 입력 데이터스트림 해시, 정렬된 청크 목록, 유형 바이트, 속성 비트 해석, CRC 결과, 편집기의 알려진 유형 집합, 정확한 필수·보조 변경 사항, 모든 미지 청크의 복사/제거 결정, 출력 정렬 및 출력 해시를 보관해야 합니다. 메타데이터가 공개 주장에 부합한다면 그 스키마, 네임스페이스 소유자, 출처와 이미지 변경 이후에도 적용 가능한 이유를 보존하십시오.

그 기록은 두 가지 반대 오류를 피합니다. 하나는 맹목적 보존: 픽셀이나 팔레트가 바뀐 뒤에도 미지의 복사 안전하지 않은 청크를 유지하고 그 CRC를 메타데이터가 여전히 유효하다는 증명으로 다루는 것입니다. 다른 하나는 맹목적 제거: 안전하고 의도적으로 이식 가능한 확장을 손실을 기록하지 않고 제거하는 것입니다. 둘 다 RFC 2083이 드러내도록 신경 쓴 결정 표면을 지웁니다.

네 번째 글자는 메타데이터를 인증하지 않았습니다. 책임을 배치했습니다. 확장 저작자는 의존성 클래스를 선언했고, 편집기는 자신이 무엇을 바꿨는지 밝혔으며, 디코더는 자신이 모르는 것을 인정했습니다. 견고한 증거 사슬은 그 행위들을 독자가 마지막에 보는 이미지와 분리해 둡니다.

출처