커스텀 머리는 이미지가 아닌 base64 JSON으로 래핑된 URL을 저장합니다
프로필 컴포넌트는 {textures:{SKIN:{url:…}}}의 base64를 담고 있습니다. 이것이 머리의 모습이 생성 시점에 고정되는 이유이자, 데이터베이스에 수만 개의 항목이 있을 수 있는 이유입니다.
커스텀 플레이어 머리에는 그림이 포함되어 있지 않습니다. 대신 아이템의 프로필 컴포넌트 안에 JSON으로 래핑되고 다시 base64로 래핑된 텍스처 해시가 들어 있습니다.
계층 구조
해시부터 시작하여 명령어는 다음과 같이 구성됩니다.
1. hash e3b0c44298fc1c149afbf4c8996fb924…
2. JSON {"textures":{"SKIN":{"url":"http://textures.minecraft.net/texture/<hash>"}}}
3. base64 eyJ0ZXh0dXJlcyI6eyJTS0lOIjp7InVybCI6…
4. component /give @p player_head[profile={properties:[{name:"textures",value:"<base64>"}]}]"이 머리는 저 이미지처럼 보인다"고 말하기 위한 네 개의 계층입니다. 속성은 항상 textures으로 명명되며, 값은 항상 해당 JSON 형태의 base64입니다.
여기서 두 가지 사실을 직접적으로 알 수 있습니다.
머리는 사람에게 연결된 링크가 아니라 스냅샷입니다. URL은 계정이 아닌 불변의 텍스처 파일을 가리킵니다. 머리가 생성될 때 해당 해시가 무엇으로 확인되었든, 그것이 항상 표시될 것입니다.
데이터는 매우 작습니다. 머리 항목은 이름, 해시 및 일부 태그로 구성되며 이미지 바이트는 전혀 없습니다. 이것이 카탈로그가 수만 개의 머리를 일반 정적 JSON으로 저장하고도 빠르게 로드될 수 있는 이유입니다.
카탈로그가 카테고리별로 로드되는 이유
여기서 데이터베이스는 TheSilentPro의 CC0 머리 컬렉션이며, 한 번에 모두 가져오는 대신 한 번에 한 카테고리씩 가져옵니다. 인덱스는 카테고리와 그 수를 나열하며, 하나를 선택하면 해당 파일만 가져옵니다.
이것은 게으른 엔지니어링이 아니라, 이 규모에서 작동하는 유일한 형태입니다. 전체 컬렉션을 단일 JSON으로 만들면 한 카테고리에서 세 개의 머리를 원하는 사람에게는 큰 다운로드가 될 것입니다.
300개 항목 렌더링 제한은 DOM 제한이지 검색 제한이 아닙니다
결과는 한 번에 최대 300개까지 그려집니다. 검색은 로드된 카테고리의 모든 항목에 대해 계속 실행됩니다. 이 제한은 DOM 노드로 변환되는 개수에 적용되며, 고려되는 개수에는 적용되지 않습니다.
이러한 구분은 검색이 처음 300개를 표시한다고 말할 때 중요합니다. 누락된 항목은 발견되었지만 페이지에서 보류되고 있으며, 쿼리에서 제외된 것이 아닙니다. 검색 범위를 좁히면 더 열심히 검색하는 것이 아니라 해당 항목들이 범위 내로 들어옵니다.
수만 개의 요소를 한 번에 그리는 것을 방지하기 위해 이 제한이 존재하며, 이는 방어적인 반올림 숫자가 아닌 실제 제한입니다. 그렇게 큰 그리드는 렌더링이 불가능해지기 훨씬 전에 스크롤이 불가능해집니다.
여기서는 아무것도 업로드하지 않습니다
머리 데이터는 동일 출처의 정적 JSON입니다. 유일한 타사 요청은 mc-heads.net에서 해시를 그림으로 변환하여 표시하는 <img> 미리보기입니다. /give 명령어는 해시로부터 로컬에서 조립되므로, 미리보기가 로드되었는지 여부와 관계없이 명령어가 작동합니다.