Ein benutzerdefinierter Kopf speichert eine URL, die in Base64-JSON verpackt ist, kein Bild
Die Profilkomponente enthält Base64 von {textures:{SKIN:{url:…}}}. Deshalb ist das Aussehen eines Kopfes zum Zeitpunkt seiner Erstellung fixiert, und deshalb kann die Datenbank Zehntausende von Einträgen umfassen.
Ein benutzerdefinierter Spielerkopf enthält kein Bild. Er enthält einen Textur-Hash, verpackt in JSON, verpackt in Base64, der sich in der Profilkomponente des Gegenstands befindet.
Die Schichten
Ausgehend von einem Hash wird der Befehl wie folgt aufgebaut:
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 Schichten, um zu sagen: „Dieser Kopf sieht aus wie dieses Bild“. Die Eigenschaft heißt immer textures, und der Wert ist immer das Base64 dieser JSON-Struktur.
Zwei Dinge ergeben sich direkt daraus:
Ein Kopf ist eine Momentaufnahme, keine Verknüpfung zu einer Person. Die URL verweist auf eine unveränderliche Texturdatei, nicht auf ein Konto. Was auch immer dieser Hash zum Zeitpunkt der Erstellung des Kopfes aufgelöst hat, das wird er immer zeigen.
Die Daten sind winzig. Ein Kopfeintrag besteht aus einem Namen, einem Hash und einigen Tags – überhaupt keine Bildbytes. Deshalb kann ein Katalog Zehntausende von Köpfen als einfaches statisches JSON speichern und trotzdem schnell geladen werden.
Warum der Katalog nach Kategorie geladen wird
Die hier verwendete Datenbank ist die CC0-Kopfsammlung von TheSilentPro, und sie wird eine Kategorie nach der anderen und nicht auf einmal abgerufen. Ein Index listet die Kategorien und ihre Anzahlen auf; die Auswahl einer Kategorie ruft nur diese Datei ab.
Das ist keine faule Ingenieurskunst, sondern die einzige Form, die bei dieser Größe funktioniert. Die gesamte Sammlung als einzelnes JSON wäre ein großer Download für jemanden, der drei Köpfe aus einer Kategorie wollte.
Die 300-Elemente-Renderbegrenzung ist eine DOM-Grenze, keine Suchgrenze
Ergebnisse werden höchstens 300 auf einmal gezeichnet. Die Suche läuft immer noch über alles in der geladenen Kategorie – die Begrenzung gilt dafür, wie viele in DOM-Knoten umgewandelt werden, nicht dafür, wie viele berücksichtigt werden.
Diese Unterscheidung ist wichtig, wenn eine Suche angibt, die ersten 300 anzuzeigen: Die fehlenden Einträge wurden gefunden und werden von der Seite zurückgehalten, nicht von der Abfrage ausgeschlossen. Eine Verfeinerung der Suche bringt sie in Reichweite, anstatt härter zu suchen.
Das gleichzeitige Zeichnen von Zehntausenden von Elementen soll durch die Begrenzung verhindert werden, und es ist eine echte Grenze und keine defensive runde Zahl – ein so großes Raster ist lange bevor es nicht mehr renderbar ist, nicht mehr scrollbar.
Hier wird nichts hochgeladen
Die Kopfdaten sind Same-Origin-statisches JSON. Die einzige Drittanbieteranfrage ist die <img>-Vorschau von mc-heads.net, die einen Hash in ein Bild zur Anzeige auflöst. Der /give-Befehl wird lokal aus dem Hash zusammengestellt, sodass der Befehl funktioniert, unabhängig davon, ob die Vorschau geladen wurde.