Une Tête de joueur personnalisée stocke une URL encodée en base64 JSON, pas une image
Le composant de profil contient le base64 de {textures:{SKIN:{url:…}}}. C'est pourquoi l'apparence d'une Tête de joueur est figée au moment de sa création, et pourquoi la base de données peut contenir des dizaines de milliers d'entrées.
Une Tête de joueur personnalisée ne contient pas d'image. Elle contient un hachage de texture, encapsulé dans du JSON, lui-même encodé en base64, et stocké dans le composant de profil de l'objet.
Les couches
À partir d'un hachage, la commande est construite comme suit :
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>"}]}]Quatre couches pour dire "cette Tête de joueur ressemble à cette image". La propriété est toujours nommée textures, et la valeur est toujours le base64 de cette structure JSON.
Deux choses en découlent directement :
Une Tête de joueur est un instantané, pas un lien vers une personne. L'URL pointe vers un fichier de texture immuable, et non vers un compte. Quelle que soit la résolution de ce hachage au moment de la création de la Tête de joueur, c'est ce qu'elle affichera toujours.
Les données sont minuscules. Une entrée de Tête de joueur est un nom, un hachage et quelques balises — aucun octet d'image. C'est pourquoi un catalogue peut contenir des dizaines de milliers de Têtes de joueur sous forme de JSON statique simple et se charger rapidement.
Pourquoi le catalogue se charge par catégorie
La base de données ici est la collection de Têtes de joueur CC0 de TheSilentPro, et elle est récupérée une catégorie à la fois plutôt que d'un seul coup. Un index liste les catégories et leurs nombres ; en choisir une ne récupère que ce fichier.
Ce n'est pas de l'ingénierie paresseuse, c'est la seule forme qui fonctionne à cette taille. La collection entière sous forme de JSON unique serait un téléchargement volumineux pour quelqu'un qui ne voudrait que trois Têtes de joueur d'une seule catégorie.
La limite de rendu de 300 éléments est une limite DOM, pas une limite de recherche
Les résultats sont affichés au maximum 300 à la fois. La recherche s'exécute toujours sur tout ce qui se trouve dans la catégorie chargée — la limite s'applique au nombre d'éléments transformés en nœuds DOM, et non au nombre d'éléments considérés.
Cette distinction est importante lorsqu'une recherche indique qu'elle affiche les 300 premiers : les entrées manquantes ont été trouvées et sont retenues de la page, et non exclues de la requête. Affiner la recherche les ramène dans la plage plutôt que de chercher plus intensément.
L'affichage de dizaines de milliers d'éléments à la fois est ce que la limite vise à empêcher, et c'est une limite réelle plutôt qu'un chiffre rond défensif — une grille aussi grande cesse d'être défilable bien avant de cesser d'être rendable.
Rien ici ne télécharge quoi que ce soit
Les données des Têtes de joueur sont du JSON statique de même origine. La seule requête tierce est l'aperçu <img> de mc-heads.net, qui résout un hachage en une image pour l'affichage. La commande /give est assemblée localement à partir du hachage, de sorte que la commande fonctionne que cet aperçu soit chargé ou non.