Een aangepast hoofd slaat een URL op die is verpakt in base64-JSON, geen afbeelding
De profile-component bevat base64 van {textures:{SKIN:{url:…}}}. Daarom ligt het uiterlijk van een hoofd vast op het moment dat het gemaakt is, en daarom kan de database tienduizenden vermeldingen bevatten.
Een aangepast spelershoofd bevat geen afbeelding. Het bevat een textuurhash, verpakt in JSON, verpakt in base64, binnenin de profile-component van het voorwerp.
De lagen
Beginnend bij een hash wordt de opdracht als volgt opgebouwd:
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>"}]}]Vier lagen om te zeggen "dit hoofd ziet eruit als die afbeelding". De eigenschap heet altijd textures, and the value is always the base64 of that JSON shape.
Twee dingen volgen hier direct uit:
Een hoofd is een momentopname, geen link naar een persoon. De URL verwijst naar een onveranderlijk textuurbestand, niet naar een account. Wat die hash ook opleverde toen het hoofd werd gemaakt, is wat het altijd zal tonen.
De gegevens zijn piepklein. Een hoofdvermelding bestaat uit een naam, een hash en enkele tags — helemaal geen afbeeldingsbytes. Daarom kan een catalogus tienduizenden hoofden bevatten als gewone statische JSON en toch snel laden.
Waarom de catalogus per categorie laadt
De database hier is TheSilentPro's CC0-hoofdencollectie, en deze wordt opgehaald één categorie tegelijk in plaats van alles tegelijk. Een index toont de categorieën en hun aantallen; het kiezen van één haalt alleen dat bestand op.
Dat is geen lui programmeerwerk, het is de enige vorm die werkt op deze schaal. De hele collectie als een enkel JSON-bestand zou een grote download zijn voor iemand die drie hoofden uit één categorie wil.
De renderlimiet van 300 items is een DOM-limiet, geen zoeklimiet
Resultaten worden met maximaal 300 tegelijk weergegeven. De zoekopdracht doorzoekt nog steeds alles in de geladen categorie — de limiet geldt voor hoeveel er worden omgezet in DOM-nodes, niet hoeveel er worden meegenomen.
Dit onderscheid is belangrijk wanneer een zoekopdracht aangeeft dat de eerste 300 worden getoond: de ontbrekende vermeldingen zijn wel gevonden maar worden niet op de pagina weergegeven, niet uitgesloten van de zoekopdracht. Het verfijnen van de zoekopdracht brengt ze binnen bereik in plaats van harder te zoeken.
Tienduizenden elementen tegelijk weergeven is precies wat de limiet voorkomt, en het is een reële grens in plaats van een defensief rond getal — een raster van die omvang stopt lang voordat het stopt met renderen al met soepel scrollen.
Niets hier uploadt iets
De hoofdgegevens zijn same-origin statische JSON. Het enige verzoek aan derden is de <img> preview from mc-heads.net, which resolves a hash into a picture for display. The /give command is assembled locally from the hash, so the command works whether or not that preview loaded.