gzip/deflate 압축 지원 (순수 한선씨 구현)
개요
크라우니 커버리지 감사에서 "gzip/deflate 전무" 갭으로 지목된 항목 보완. 기존에는
libs/압축.한선(RLE)과 독자포맷 ccp 압축기만 있었고, 표준 gzip(RFC1952)/DEFLATE
(RFC1951) 호환 압축은 없었음.
무엇을 했는지
- 경로 결정: 임무서는 "순수 한선씨 DEFLATE가 현실적이면 (A), 과도하면 (B)
crownycode-learn.sh search로 사전 조회 중
/Users/ef/crowny-flex/libs/인플레이트.한선(258줄, 순수 한선씨 DEFLATE
압축해제기, stored/fixed/dynamic 허프만 블록 + LZ77 완비)이 이미 존재함을
발견 — 이를 근거로 (A) 순수 구현을 채택, (B) 외부위임은 불필요해짐.libs/gzip.한선신규 작성 (약 480줄):
비트배타(opcode92)는 트릿(균형3진) 연산이지
이진 XOR가 아님(libs/해시.한선의 이진배타 선례로 이미 검증된 함정) →
CRC32/비트I/O를 절단나눗셈·나머지 산술로 직접 구현해 회피- HTTP gzip 예제:
examples/gzip_HTTP압축응답.한선— 최소 TCP 서버가
Content-Encoding: gzip 응답을 보내고 curl --compressed로 왕복 검증.
부수적으로 소켓생성 opcode의 arity 선언(1) vs 실제 opcode 소비량(2)
불일치 버그를 발견·우회(소켓생성(도메인,타입) 2-인자 호출).- 검증:
gzip압축() 결과 → 표준 gunzip -c 디코드 → 원본과 BYTE-EXACT
- 표준 gzip -c(동적 허프만) 결과 → 우리 gzip해제_파일() 디코드 →
74,452바이트 BYTE-EXACT (CRC32/ISIZE 자체검증 OK)
- 대용량(74KB) 텍스트: 우리 인코더 72.1% 절감(20,768B) vs 표준 gzip -6
85.8% 절감(10,576B, 동적허프만+해시체인이라 유리) — 정직 비교
- HTTP: curl --compressed 완전 왕복, 60회 반복 문단 무손상 확인관련 파일
/Users/ef/CrownyOS/crownyc/libs/gzip.한선(pkg/libs/gzip.한선과 하드링크 동기)/Users/ef/CrownyOS/crownyc/examples/gzip_HTTP압축응답.한선/Users/ef/CrownyOS/crownyc/examples/gzip_왕복검증.한선/Users/ef/CrownyOS/crownyc/docs/한선씨-P2보완-20260710/gzip검증.md(상세 검증 로그)- (참고, 원본 발견처)
/Users/ef/crowny-flex/libs/인플레이트.한선
잔여 이슈 / 로드맵
- 동적 허프만 인코더 미구현 → 압축률이 zlib 기본(-6) 대비 낮음(정직 고지, 로드맵)
- LZ77 해시 체인(현재 슬롯당 1후보) 도입 시 압축률 개선 여지
- CRC32를 산술 XOR 루프로 구현해 느림(74KB 압축+해제 약 25초) — 인터프리터 VM
tools/high2rpn.sh가 배열 인덱싱 낀 혹시/아니면 체인에서 가드클로즈 라벨을
gzip.rpn.한선 미동반(로드맵에 남김)
소켓생성arity 선언(hanseonc_high.c, 1) vs 실제 opcode 소비(2) 불일치 발견 —
libs/웹소켓v2.한선 등 다른 소켓 기반 라이브러리도 같은 함정 노출 가능성,
전수 점검 필요(C 소스 미수정 원칙상 콜사이트 우회만 이번에 적용)