что такое uuid в майнкрафт
Универсальный уникальный идентификатор
UUID ( Универсальные уникальные идентификаторы ; Java Class) — это 128-битные числа, которые используются Minecraft для различения отдельных экземпляров.
Представление
Случаи
В следующей таблице представлены ситуации, в которых UUID используются в местах, доступных для игрока:
Технические аспекты
Диапазон значений
Названия разделов шестнадцатеричного формата с переносом через дефис
| Имя раздела | Диапазон бит | |||
|---|---|---|---|---|
| От | до | Размер | Символы | |
| мало времени | 96 | 127 | 32 | 8 |
| время-середина | 80 | 95 | 16 | 4 |
| высокая версия и время | 54 | 79 | 16 | 4 |
| часы-сек-и-зарезервированы | 36 | 53 | 8 | 2 |
| clock-seq-low | 48 | 45 | 8 | 2 |
| узел | 0 | 47 | 48 | 12 |
(Имена имеют смысл только для версии 1 и 2 UUID, но он был передан во все формы используемых UUID.)
Версии и варианты
Было пять версий UUID. Версии 1 и 2 основаны на текущем времени и MAC-адресе; версии 3 и 5 основаны на хешировании строки; версия 4 основана на полностью случайной генерации. Значение «версия» занимает четыре бита и находится в строковом формате UUID в позиции, обозначенной буквой «A».
В Minecraft
Minecraft использует UUID версии 4, вариант 1 (RFC), что означает, что все число, за исключением битов, используемых для метаданных (версия и вариант), генерируется случайным образом. Функция Java UUID.randomUUID () выполняет именно эту задачу.
Таблица с расположениями и значениями метаданных:
Как генерируются UUID
Вы наверняка уже использовали в своих проектах UUID и полагали, что они уникальны. Давайте рассмотрим основные аспекты реализации и разберёмся, почему UUID практически уникальны, поскольку существует мизерная возможность возникновения одинаковых значений.
Современную реализацию UUID можно проследить до RFC 4122, в котором описано пять разных подходов к генерированию этих идентификаторов. Мы рассмотрим каждый из них и пройдёмся по реализации версии 1 и версии 4.
Теория
UUID (universally unique IDentifier) — это 128-битное число, которое в разработке ПО используется в качестве уникального идентификатора элементов. Его классическое текстовое представление является серией из 32 шестнадцатеричных символов, разделённых дефисами на пять групп по схеме 8-4-4-4-12.
Информация о реализации UUID встроена в эту, казалось бы, случайную последовательность символов:
Значения на позициях M и N определяют соответственно версию и вариант UUID.
Версия
Номер версии определяется четырьмя старшими битами на позиции М. На сегодняшний день существуют такие версии:
Вариант
Это поле определяет шаблон информации, встроенной в UUID. Интерпретация всех остальных битов в UUID зависит от значения варианта.
Мы определяем его по первым 1-3 старшим битам на позиции N.
1 0 0 0 = 8
1 0 0 1 = 9
1 0 1 0 = A
1 0 1 1 = B
Так что если вы видите UUID с такими значениями на позиции N, то это идентификатор в варианте 1.
Версия 1 (время + уникальный или случайный идентификатор хоста)
В этом случае UUID генерируется так: к текущему времени добавляется какое-то идентифицирующее свойство устройства, которое генерирует UUID, чаще всего это MAC-адрес (также известный как ID узла).
Идентификатор получают с помощью конкатенации 48-битного МАС-адреса, 60-битной временной метки, 14-битной «уникализированной» тактовой последовательности, а также 6 битов, зарезервированных под версию и вариант UUID.
Тактовая последовательность — это просто значение, инкрементируемое при каждом изменении часов.
Временная метка, которая используется в этой версии, представляет собой количество 100-наносекундных интервалов с 15 октября 1582 года — даты возникновения григорианского календаря.
Возможно, вы знакомы с принятым в Unix-системах исчислением времени с начала эпохи. Это просто другая разновидность Нулевого дня. В сети есть сервисы, которые помогут вам преобразовать одно временное представление в другое, так что не будем на этом останавливаться.
Хотя эта реализация выглядит достаточно простой и надёжной, однако использование MAC-адреса машины, на которой генерируется идентификатор, не позволяет считать этот метод универсальным. Особенно, когда главным критерием является безопасность. Поэтому в некоторых реализациях вместо идентификатора узла используется 6 случайных байтов, взятых из криптографически защищённого генератора случайных чисел.
Сборка UUID версии 1 происходит так:
Поскольку эта реализация зависит от часов, нам нужно обрабатывать пограничные ситуации. Во-первых, для минимизации коррелирования между системами по умолчанию тактовая последовательность берётся как случайное число — так делается лишь один раз за весь жизненный цикл системы. Это даёт нам дополнительное преимущество: поддержку идентификаторов узлов, которые можно переносить между системами, поскольку начальное значение тактовой последовательности совершенно не зависит от идентификатора узла.
Помните, что главная цель использования тактовой последовательности — внести долю случайности в наше уравнение. Биты тактовой последовательности помогают расширить временную метку и учитывать ситуации, когда несколько UUID генерируются ещё до того, как изменяются процессорные часы. Так мы избегаем создания одинаковых идентификаторов, когда часы переводятся назад (устройство выключено) или меняется идентификатор узла. Если часы переведены назад, или могли быть переведены назад (например, пока система была отключена), и UUID-генератор не может убедиться, что идентификаторы сгенерированы с более поздними временными метками по сравнению с заданным значением часов, тогда нужно изменить тактовую последовательность. Если нам известно её предыдущее значение, его можно просто увеличить; в противном случае его нужно задать случайным образом или с помощью высококачественного ГПСЧ.
Версия 2 (безопасность распределённой вычислительной среды)
Главное отличие этой версии от предыдущей в том, что вместо «случайности» в виде младших битов тактовой последовательности здесь используется идентификатор, характерный для системы. Часто это просто идентификатор текущего пользователя. Версия 2 используется реже, она очень мало отличается от версии 1, так что идём дальше.
Версия 3 (имя + MD5-хэш)
Если нужны уникальные идентификаторы для информации, связанной с именами или наименованием, то для этого обычно используют UUID версии 3 или версии 5.
Они кодируют любые «именуемые» сущности (сайты, DNS, простой текст и т.д.) в UUID-значение. Самое важное — для одного и того же namespace или текста будет сгенерирован такой же UUID.
Обратите внимание, что namespace сам по себе является UUID.
В этой реализации UUID namespace преобразуется в строку байтов, конкатенированных с входным именем, затем хэшируется с помощью MD5, и получается 128 битов для UUID. Затем мы переписываем некоторые биты, чтобы точно воспроизвести информацию о версии и варианте, а остальное оставляем нетронутым.
Важно понимать, что ни namespace, ни входное имя не могут быть вычислены на основе UUID. Это необратимая операция. Единственное исключение — брутфорс, когда одно из значений (namespace или текст) уже известно атакующему.
При одних и тех же входных данных генерируемые UUID версий 3 и 5 будут детерминированными.
Версия 4 (ГПСЧ)
Самая простая реализация.
6 битов зарезервированы под версию и вариант, остаётся ещё 122 бита. В этой версии просто генерируется 128 случайных битов, а потом 6 из них заменяется данными о версии и варианте.
Такие UUID полностью зависят от качества ГПСЧ (генератора псевдослучайных чисел). Если его алгоритм слишком прост, или ему не хватает начальных значений, то вероятность повторения идентификаторов возрастает.
В современных языках чаще всего используются UUID версии 4.
Её реализация достаточно простая:
Версия 5 (имя + SHA-1-хэш)
Единственное отличие от версии 3 в том, что мы используем алгоритм хэширования SHA-1 вместо MD5. Эта версия предпочтительнее третьей (SHA-1 > MD5).
Практика
Одним из важных достоинств UUID является то, что их уникальность не зависит от центрального авторизующего органа или от координации между разными системами. Кто угодно может создать UUID с определённой уверенностью в том, что в обозримом будущем это значение больше никем не будет сгенерировано.
Это позволяет комбинировать в одной БД идентификаторы, созданные разными участниками, или перемещать идентификаторы между базами с ничтожной вероятностью коллизии.
UUID можно использовать в качестве первичных ключей в базах данных, в качестве уникальных имён загружаемых файлов, уникальных имён любых веб-источников. Для их генерирования вам не нужен центральный авторизующий орган. Но это обоюдоострое решение. Из-за отсутствия контролёра невозможно отслеживать сгенерированные UUID.
Есть и ещё несколько недостатков, которые нужно устранить. Неотъемлемая случайность повышает защищённость, однако она усложняет отладку. Кроме того, UUID может быть избыточным в некоторых ситуациях. Скажем, не имеет смысла использовать 128 битов для уникальной идентификации данных, общий размер которых меньше 128 битов.
Уникальность
Может показаться, что если у вас будет достаточно времени, то вы сможете повторить какое-то значение. Особенно в случае с версией 4. Но в реальности это не так. Если бы вы генерировали один миллиард UUID в секунду в течение 100 лет, то вероятность повторения одного из значений была бы около 50 %. Это с учётом того, что ГПСЧ обеспечивает достаточное количество энтропии (истинная случайность), иначе вероятность появления дубля будет выше. Более наглядный пример: если бы вы сгенерировали 10 триллионов UUID, то вероятность появления двух одинаковых значений равна 0,00000006 %.
А в случае с версией 1 часы обнулятся только в 3603 году. Так что если вы не планируете поддерживать работу своего сервиса ещё 1583 года, то вы в безопасности.
Впрочем, вероятность появления дубля остаётся, и в некоторых системах стараются это учитывать. Но в подавляющем большинстве случаев UUID можно считать полностью уникальными. Если вам нужно больше доказательств, вот простая визуализация вероятности коллизии на практике.
Универсальный уникальный идентификатор
UUID ( Универсальные уникальные идентификаторы ; Java Class) — это 128-битные числа, которые используются Minecraft для различения отдельных экземпляров.
Представление
Случаи
В следующей таблице представлены ситуации, в которых UUID используются в местах, доступных для игрока:
Технические аспекты
Диапазон значений
Названия разделов шестнадцатеричного формата с переносом через дефис
| Имя раздела | Диапазон бит | |||
|---|---|---|---|---|
| От | до | Размер | Символы | |
| мало времени | 96 | 127 | 32 | 8 |
| время-середина | 80 | 95 | 16 | 4 |
| высокая версия и время | 54 | 79 | 16 | 4 |
| часы-сек-и-зарезервированы | 36 | 53 | 8 | 2 |
| clock-seq-low | 48 | 45 | 8 | 2 |
| узел | 0 | 47 | 48 | 12 |
(Имена имеют смысл только для версии 1 и 2 UUID, но он был передан во все формы используемых UUID.)
Версии и варианты
Было пять версий UUID. Версии 1 и 2 основаны на текущем времени и MAC-адресе; версии 3 и 5 основаны на хешировании строки; версия 4 основана на полностью случайной генерации. Значение «версия» занимает четыре бита и находится в строковом формате UUID в позиции, обозначенной буквой «A».
В Minecraft
Minecraft использует UUID версии 4, вариант 1 (RFC), что означает, что все число, за исключением битов, используемых для метаданных (версия и вариант), генерируется случайным образом. Функция Java UUID.randomUUID () выполняет именно эту задачу.
Таблица с расположениями и значениями метаданных:
Что такое uuid в майнкрафт
UUID (англ. universally unique identifier «универсальный уникальный идентификатор») — это стандарт идентификации, используемый в создании программного обеспечения, стандартизированный Open Software Foundation (OSF) как часть DCE — среды распределённых вычислений. Основное назначение UUID — это позволить распределённым системам уникально идентифицировать информацию без центра координации. Таким образом, любой может создать UUID и использовать его для идентификации чего-либо с приемлемым уровнем уверенности, что данный идентификатор непреднамеренно никогда не будет использован для чего-то ещё. Поэтому информация, помеченная с помощью UUID, может быть помещена позже в общую базу данных, без необходимости разрешения конфликта имен. Наиболее распространённым использованием данного стандарта является Globally Unique Identifier (GUID) фирмы Microsoft. Другими значительными пользователями являются Linux (файловая система ext2/ext3, LUKS шифрованные разделы, GNOME, KDE) и Mac OS X — все они применяют реализацию, полученную из библиотеки uuid, находящейся в пакете e2fsprogs.
Содержание
Стандарты [ править | править код ]
UUID задокументирован как часть ISO/IEC 11578:1996 «Information technology — Open Systems Interconnection — Remote Procedure Call (RPC)» и позже в ITU-T Rec. X.667 | ISO/IEC 9834-8:2008. IETF опубликовала предлагаемый стандарт RFC 4122, который технически идентичен ITU-T Rec. X.667 | ISO/IEC 9834-8.
Формат [ править | править код ]
UUID представляет собой 16-байтный (128-битный) номер. В каноническом представлении UUID изображают в виде числа в шестнадцатеричной системе счисления, разделённого дефисами на пять групп в формате 8-4-4-4-12. Такое представление занимает 36 символов:
4 бита M обозначают версию («version») UUID, а 1-3 старших бита N обозначают вариант («variant») UUID.
Такое разделение на группы основано на структуре UUID:
Эти поля соответствуют версиям UUID 1 и 2, которые генерируются на базе времени, но представление 8-4-4-4-12 используется для любых версий UUID.
RFC 4122 также определяет пространство имён URN для UUID:
Microsoft GUID иногда используется с фигурными скобками:
Кодирование [ править | править код ]
Бинарное представление UUID различается на разных системах.
Варианты [ править | править код ]
По историческим причинам UUID имеет несколько вариантов, обозначаемых одним, двумя или тремя битами.
Вариант 0 [ править | править код ]
Один из вариантов, определенных в RFC 4122, вариант 0 (обозначается одним битом 0xxx2, N = 0..7 ), присутствует ради обратной совместимости с устаревшим форматом UUID Apollo Network Computing System 1.5, разработанным примерно в 1988 году. В этом формате первые 6 октетов UUID представляют собой 48-битную метку времени (количество единиц времени в 4 микросекунды, прошедших с 1 января 1980 года UTC); следующие 2 октета зарезервированы; следующий октет — это «address family»; последние 7 октетов являются 56-битным идентификатором хоста в форме, определенной address family. Несмотря на различие в деталях, можно видеть сходство с современным UUID версии 1. Биты варианта в текущей спецификации UUID совпадают с старшими битами октета семейства адресов в UUID NCS. Хотя семейство адресов может содержать значения в диапазоне 0..255, были определены только значения 0..13. Таким образом, обозначение варианта 0 как 0xxx позволяет избежать конфликтов с историческими UUID NCS, если они всё ещё существуют в базах данных.
Варианты 1 и 2 [ править | править код ]
Эти варианты используются в текущих спецификациях UUID. Вариант 1 (обозначается двумя битами 10xx2 N = 8..b ) является основным и описан в RFC 4122. Вариант 2 (обозначается тремя битами 110x2 N = c..d ) описан в RFC как зарезервированный для обратной совместимости с ранними GUID из Microsoft Windows.
Помимо битов, обозначающих вариант, во всём остальном эти два варианта UUID одинаковы, за исключением того, что при кодировании в бинарную форму для хранения или передачи UUID варианта 1 используют сетевой порядок байтов (big-endian), а GUID варианта 2 используют «нативный» (little-endian) порядок байтов. В каноническом текстовом представлении варианты 1 и 2 одинаковы, за исключением битов вариантов.
Хотя некоторые важные идентификаторы GUID, такие как идентификатор интерфейса IUnknown для COM, являются UUID варианта 2, многие идентификаторы, созданные и используемые в ПО Microsoft Windows и называемые «GUID», по факту являются стандартными UUID варианта 1 с сетевым порядком байтов. Текущая версия утилиты Microsoft guidgen создает стандартные UUID варианта 1. В некоторой документации Microsoft говорится, что «GUID» является синонимом «UUID», [1] как это стандартизировано в RFC 4122. Сам RFC 4122 утверждает, что UUID также известны как GUID («are also known as GUIDs»). Все это говорит о том, что «GUID», хоть и был изначально отдельным вариантом UUID, используемым в Microsoft, сейчас стал просто альтернативным названием для стандартного UUID.
Вариант 3 [ править | править код ]
В RFC 4122 вариант 111x2 (N = e..f ) зарезервирован для использования в будущем.
Версии [ править | править код ]
В стандарте определены пять версий («version») UUID, каждая из которых может подходить лучше или хуже в определённых ситуациях.
Nil UUID [ править | править код ]
Версия 1 (время и MAC-адрес) [ править | править код ]
В отличие от других версий UUID, уникальность UUID версий 1 и 2, основанных на MAC-адресах сетевых карт, частично зависит от идентификатора, выданного центральным регистрирующим органом, а именно от части уникального идентификатора организации (OUI) MAC-адреса, который выдаётся в IEEE производителям сетевого оборудования. [3] Уникальность также зависит от правильного назначения уникальных MAC-адресов сетевых карт производителями, что, как и другие производственные процессы, подвержено ошибкам.
Версия 2 (время, MAC-адрес и DCE security version) [ править | править код ]
RFC 4122 резервирует версию 2 «DCE security», но не предоставляет никаких подробностей о ней. По этой причине во многих реализациях UUID версия 2 отсутствует. Однако описание UUID версии 2 есть в спецификации DCE 1.1 Authentication and Security Services. [5]
Версия 2 похожа на версию 1, но младшие 8 бит clock sequence заменены на номер «локального домена» («local domain» number), а младшие 32 бита метки времени (timestamp) заменены целочисленным идентификатором, значимым в пределах указанного локального домена.
Возможность включить 40-битный домен/идентификатор является компромиссом. С одной стороны, 40 битов допускают около 1 триллиона значений доменов/идентификаторов для одного узла. С другой стороны, с урезанным значением метки времени до 28 старших значащих бит по сравнению с 60 битами в версии 1 время в UUID версии 2 будет «тикать» лишь раз в 429,49 секунды (чуть больше 7 минут) в отличие от 100 наносекунд в версии 1. И с шестибитным clock sequence, в отличие от 14 бит в версии 1, могут быть сгенерированы лишь 64 уникальных UUID для одного узла/домена/идентификатора в течение этих 7 минут. Таким образом UUID версии 2 не подходит, если требуется генерировать UUID чаще чем раз в 7 секунд.
Версии 3 и 5 [ править | править код ]
UUID версий 3 и 5 образуются путём хеширования идентификатора пространства имён и имени. Версия 3 использует алгоритм хеширования MD5, версия 5 — SHA-1.
Спецификация предоставляет UUID для представления пространств имён URL, FQDN, OID и отличительных имён X.500, но любой желаемый UUID может использоваться в качестве идентификатора пространства имен.
Для вычисления UUID версии 3, соответствующего данному пространству имен и имени, UUID пространства имен преобразуется в байтовую, конкатенируется с именем и хешируется алгоритмом MD5, что дает 128 битов. Затем 6 или 7 битов заменяются фиксированными значениями: 4-битной версией (например, 00112 для версии 3) и 2- или 3-битным вариантом («variant») UUID (например, 102, обозначающим RFC 4122 UUID, или 1102, обозначающим legacy Microsoft GUID). Поскольку 6 или 7 битов таким образом предопределены, лишь 121 или 122 бита вносят вклад в уникальность UUID.
UUID версии 5 похож, но использует SHA-1 вместо MD5. Так как SHA-1 даёт 160-битный хеш, он предварительно обрезается до 128 бит.
Суть UUID версий 3 и 5 в том, что одна и та же пара из пространства имён и имени будет отображаться в один и тот же UUID. При этом ни пространство имён, ни имя не могут быть обратно получены из UUID, кроме как методом перебора.
RFC 4122 рекомендует использовать версию 5 вместо версии 3 и не рекомендует использовать ни одну из этих версий в качестве учетных данных для безопасности.
Версия 4 (случайный) [ править | править код ]
Вероятность совпадения UUID [ править | править код ]
p ( n ) ≈ 1 − exp ( N ⋅ ( ln ( N − 1 ) − ln ( N − n ) ) + n ⋅ ( ln ( N − n ) − ln ( N ) − 1 ) − ( ln ( N − 1 ) − ln ( N ) − 1 ) ) 
Где N — количество возможных вариантов (2 128 ); n — число сгенерированных ключей.
p(2 50 ) ≈ 1,87×10 −9
p(2 59 ) ≈ 0.000489
p(2 64 ) ≈ 0.4
p(2 66 ) ≈ 0.999665
Можно с уверенностью сказать, что первый квадриллион ключей (10 15 ) будут уникальными.
Программа для расчета вероятности на языке программирования Java:
UUID ist die Abkürzung für Universally Unique Identifier, was soviel wie «weltweit eindeutige Kennzeichnung» bedeutet (siehe Wikipedia). Damit werden in der Softwareentwicklung Elemente in verteilten Systemen eindeutig gekennzeichnet.
Inhaltsverzeichnis
UUID in Minecraft [ Bearbeiten ]
In Minecraft besteht das verteilte System aus dem Authentication Service von Mojang, der das Login des Spielers prüft, aus den Clients der Spieler und aus den Minecraft-Servern in der ganzen Welt, auf denen man Minecraft spielen kann. In all diesen Elementen des verteilten Systems soll der Spieler (genauer: ein Minecraft-Account) eindeutig identifizierbar sein.
Durch die UUID erhält jeder Minecraft-Account eine eindeutige Seriennummer. Der Accountbesitzer (der Spieler) kann dann seinen Spielernamen oder seine E-Mail-Adresse ändern und behält trotzdem immer die selbe UUID.
Die eigene UUID kann man aus der Datei .minecraft/launcher_profiles.json ablesen. Dort steht sie im Abschnitt «authenticationDatabase». Achtung: Dort stehen verschiedene IDs, die richtige ist die «uuid». Im Spiel wird die UUID beim Fahren mit der Maus über einen Spielernamen im Chat angezeigt.
Mit einer UUID kann man jedoch nicht nur Spieler, sondern beliebige Elemente kennzeichnen. In Minecraft haben z.B. sämtliche Objekte (d.h. alle Kreaturen, Fahrzeuge, Geschosse, Drops etc.) eine UUID. Ebenso die Attribut-Modifikatoren.
Darstellungsformen [ Bearbeiten ]
Verwendung [ Bearbeiten ]
Die folgende tabelle enthält die Situationen, in denen UUIDs an Stellen verwendet werden, auf die der Benutzer Zugriff hat: [Ab 1.16]
| Ort (algemein) | Ort (Pfad) | Format | Verwendung |
|---|---|---|---|
| Alle Objekte (NBT) | UUID | int-array | Eigene UUID |
| Attribut-Modifikatoren (NBT) | UUID | int-array | Eigene UUID. Verwendet bei dem Ausrüsten und Abrüsten des Gegenstands um den Modifikator zu identifizieren, der von der Kreatur entfernt oder hinzugefügt werden soll. |
| Attribut-Modifikatoren (Beutetabellen) | id | String | Setzt UUID von Modifikator in set_attributes Funktion |
| Zähmbare Kreaturen (NBT) | Owner | int-array | Besitzer |
| Projektile (NBT) | Owner | int-array | Objekt, das das Projektil erzeugt hat |
| Drops (NBT) | Owner | int-array | Ziel-Spieler für den Befehl /give |
| Drops (NBT) | Thrower | int-array | Spieler, der den Gegenstand fallen gelassen hat |
| Shulkergeschoss (NBT) | Target | int-array | Objekt, auf das der Angriff zielt |
| Aquisatoren (NBT) | Target | int-array | Objekt, das der Aquisator angreift |
| Spielerköpfe (NBT) | SkullOwner.Id | int-array | Der Spieler, dem der Kopf gehört |
| Spielerköpfe (NBT) | SkullOwner.Properties.textures[].Value.ProfileId | String ohne Bindestriche | Der Spieler, dem der Kopf gehört |
| Kreaturen (NBT) | Leash.UUID | int-array | Objekt, das die Kreatur an der Leine hat |
| Kreaturen, die gepaart werden können (NBT) | LoveCause | int-array | Spieler, der die Kreatur gefüttert hat |
| Dorfbewohnerzombie (NBT) | ConversionPlayer | int-array | Spieler, der gerade den Dorfbewohnerzombie heilt |
| Bienen und Zombifizierte Piglins (NBT) | HurtBy | int-array | Objekt, das die Kreatur angegriffen hat |
| Dorfbewohner (NBT) | Gossips[].Target | int-array | Spieler, der den Tratsch verursacht hat |
| Selektoren (Befehle) | — | String | Alternative zu Spielernamen und Selektorvariablen |
| Diese Seite ist unvollständig. |
Umrechnung UUID in UUIDLeast und UUIDMost [ Bearbeiten ]
In den NBT-Daten werden UUIDs nicht als String gespeichert, sondern in zwei Hälften geteilt und als vorzeichenbehaftete Long-Zahlen UUIDLeast und UUIDMost gespeichert. Für die Umrechnung ist es am einfachsten, externe Werkzeuge zu benutzen, die neben den hier erklärten Formaten auch in das int-array Format umrechnen können. Ein gutes Beispiel ist diese Seite: https://www.soltoder.com/mc-uuid-converter/
Eine manuelle Umrechnung kann allerdings auch durch die folgenden Schritte umgesetzt werden:
Eigene Verwendung [ Bearbeiten ]
UUID setzen [ Bearbeiten ]
Wenn man mit dem Befehl /summon ein Objekt spawnt, wird ihm normalerweise vom Spiel automatisch eine UUID gegeben. Man kann aber auch selbst eine UUID vergeben, wodurch man das Objekt unter Anderem über den Befehl /execute if entity eindeutig identifizieren kann. Dieses Verfahren hat den Vorteil, dass die UUID auch als Selektor eingesetzt werden kann, was im Vergleich zu Selektorvariablen wie @e extrem performant ist.
| UUIDMost | UUIDLeast | UUID |
|---|---|---|
| 0L | 0L | 00000000-0000-0000-0000-000000000000 |
| 0L | 1L | 00000000-0000-0000-0000-000000000001 |
| 0L | 9L | 00000000-0000-0000-0000-000000000009 |
| 0L | 10L | 00000000-0000-0000-0000-00000000000A |
[Bis 1.16] erzeugt ein Schwein mit der UUID 2.
Existieren in Minecraft jedoch Objekte mit der selben UUID, kann es zu Fehlern kommen. Unter anderem können dann Fehlermeldungen wie «Dieses Objekt kann nicht gefunden werden» auftreten. Man kann dieses Problem nur lösen, indem man diese Objekte per Hand tötet oder den Befehl /kill anwendet und die Welt neu öffnet.
| Diese Seite ist unvollständig. |
Generieren von Zufallszahlen [ Bearbeiten ]
Wenn sie nicht manuell festgelegt wurde, ist die UUID von Objekten oder Attribut-Modifikatoren zufällig gesetzt, wodurch sie sich gut für das Generieren von Zufallszahlen eignet.
| Diese Seite ist unvollständig. |
Manipulation von Spielmechaniken [ Bearbeiten ]
Weil eine Vielzahl an Spielmechaniken auf dem Auslesen von in NBT-Daten gespeicherten UUIDs beruht, lassen sich diese durch das Umschreiben dieser Daten verändern.
| Diese Seite ist unvollständig. |
Spielername zu UUID finden [ Bearbeiten ]
Um den Spielernamen zu einer UUID zu finden, verwendet man die Mojang API. Die UUID muss dabei ohne Trennstriche eingegeben werden. Beispiel:
https://api.mojang.com/user/profiles/f498513ce8c84773be26ecfc7ed5185d/names liefert den Spielernamen «jeb».
Umgekehrt kann man zu einem Spielernamen auch die UUID ermitteln:
https://api.mojang.com/users/profiles/minecraft/jeb liefert die UUID «f498513ce8c84773be26ecfc7ed5185d».
Technische Aspekte [ Bearbeiten ]
Wertebereich [ Bearbeiten ]
String Format Abschnittnamen [ Bearbeiten ]
| Abbschnittname | Verwendetes Zeichen | Bit-Bereich | ||
|---|---|---|---|---|
| Von | Bis | Größe | ||
| time-low | a | 96 | 127 | 32 |
| time-mid | b | 80 | 95 | 16 |
| time-high-and-version | c | 54 | 79 | 16 |
| clock-seq-and-reserved | d | 36 | 53 | 8 |
| clock-seq-low | e | 48 | 45 | 8 |
| node | f | 47 | 48 | |
Generierung [ Bearbeiten ]
Minecraft verwended Version 4 UUIDs, was bedeutet, dass die gesamte Zahl, unter Ausnahme der Metadaten, zufällig generiert wird. Eine Tabelle mit den Platzierungen und Werten der Metadaten innerhalb der UUID:
Useful Minecraft Resources
What is this website for?
MCUUID is a project designed to make finding, converting, and looking up Minecraft player UUIDs and usernames, simple and easy. A UUID is a unique identifier issued by Mojang to all users when they purchase the game. This tool is useful when, for example, locating player.dat files on a Minecraft server.
A big thank you to Crafatar for providing player avatars.
For API usage, please do not scrape this site as it may change at any time. We ask that you use the service we provide at PlayerDB.co instead.
Legal Bits
Nodecraft Inc and this website are not affiliated with Mojang AB.