ICO / CUR 아이콘 분석기

디렉터리 항목의 너비와 높이가 각각 1바이트인데 256은 1바이트에 들어가지 않기 때문입니다. 형식은 0을 256으로 정의해 이 문제를 풀었고, 그래서 256 × 256 이미지는 두 크기 바이트가 모두 0으로 기록됩니다. 바이트를 곧이곧대로 읽는 판독기는 0 × 0으로 보고하거나 아예 빈 항목으로 여겨 건너뜁니다. 이 페이지는 그 규칙을 적용하므로 선언 크기가 256 × 256인 줄의 항목 바이트 칸에는 0, 0이 그대로 표시됩니다. 아이콘이 256픽셀보다 큰 이미지를 담을 수 없는 이유도 같습니다. 항목에 그것을 적을 자리가 없습니다.

구조는 거의 같습니다. 같은 헤더, 같은 디렉터리, 같은 페이로드입니다. 다른 것은 두 가지입니다. 헤더의 타입 값이 아이콘은 1, 커서는 2이고, 아이콘이 색 평면과 픽셀당 비트 수로 쓰는 16비트 두 칸이 커서에서는 핫스팟 x와 y가 됩니다. 실제로 클릭이 일어나는 그림 안의 지점이지요. 그래서 커서를 아이콘으로 읽으면 색 깊이가 3 같은 무의미한 값으로 나옵니다. 확장자는 양쪽 모두 믿을 수 없으므로 이 페이지는 타입 값을 읽어 깊이와 핫스팟 칸을 바꿔 보여 주고, 이름과 헤더가 어긋나면 그 사실을 알려 줍니다.

BMP 이미지는 사실 두 비트맵이 하나로 쌓인 것이기 때문입니다. XOR 비트맵이라 부르는 컬러 이미지와, 그 아래에 어느 픽셀로 화면이 비쳐 보일지 정하는 1비트 AND 마스크입니다. BITMAPINFOHEADER가 둘을 한꺼번에 설명하므로 높이 칸도 둘을 합쳐 셉니다. 실제 높이는 그 절반입니다. 마스크는 두 가지로 틀리기 쉽습니다. 행 여백이 컬러 행과 별개로 4바이트에 맞춰지므로 너비 24픽셀짜리 마스크의 한 행은 3바이트가 아니라 4바이트이고, 픽셀당 1비트로 채워지며 켜진 비트가 투명을 뜻합니다. 이 페이지는 마스크 위치와 행 간격을 보여 주므로 직접 만든 판독기의 계산을 대조해 볼 수 있습니다.

둘 다 적법하고 한 파일에 섞을 수도 있으며 비스타 시절 아이콘은 실제로 그렇게 만듭니다. 경험칙은 256 × 256은 PNG로 넣으라는 것입니다. 마스크까지 붙은 256 비트맵은 이미지 하나에 약 256KB가 들지만 PNG는 그 일부로 줄여 줍니다. 작은 크기는 호환을 위해 보통 BMP로 두는데, 윈도우 XP 셸에서는 PNG 이미지 자리에 아무것도 나오지 않기 때문입니다. 요즘 브라우저는 둘 다 문제없이 읽습니다. 디렉터리에는 어느 쪽인지 적히지 않으므로 판독기는 각 페이로드의 앞 8바이트에서 PNG 서명을 찾아야 하고, 여기 페이로드 칸이 보여 주는 것이 바로 그 결과입니다.

알파를 존중하는 환경에서는 그 이미지가 보이지 않고, AND 마스크를 쓰는 환경에서는 멀쩡합니다. 두 방식은 함께 존재합니다. 32비트 BMP 이미지는 픽셀마다 알파 바이트를 갖는 동시에 1비트 마스크도 싣습니다. 필요 여부와 상관없이 형식이 마스크를 요구하기 때문입니다. 마스크는 제대로 쓰면서 알파를 0으로 남기는 내보내기 도구는 윈도우 셸에서는 멀쩡해 보이고 브라우저 탭에서는 사라지는 아이콘을 만듭니다. 반대로 진짜 알파가 있고 마스크가 전부 0인 것이 요즘의 정상적인 모양이며, 그때는 마스크가 불필요하다고 표시합니다.

둘 중 하나가 거짓말을 하고 있고, 결과는 누가 읽느냐에 달렸다는 뜻입니다. 윈도우는 디렉터리 항목에서 크기를 가져오므로 48 × 48이라고 적힌 항목 아래 32 × 32 PNG가 들어 있으면 그림이 흐릿하게 늘어난 채로 고정됩니다. 어떤 판독기는 반대로 페이로드를 믿고 약속한 것과 다른 크기를 조용히 그립니다. 이런 불일치는 대개 그림 크기를 바꾸고 페이로드만 새로 쓴 편집기에서 생기며, 양쪽을 함께 읽지 않으면 드러나지 않습니다. 이 페이지가 IHDR과 BITMAPINFOHEADER를 각각을 가리키는 항목과 비교하는 이유입니다.