(Globally Unique IDentifier) An implementation of the universally unique ID (see UUID) that is computed by Windows and Windows applications. Using a pseudo-random 128-bit number, GUIDs are used to identify user accounts, documents, software, hardware, software interfaces, sessions, database keys and other items.
First developed to keep track of instances of COM objects, GUIDs were created by an algorithm that used the MAC address of the local Ethernet card. Microsoft later dropped the Ethernet address due to protests that documents could be traced back to a particular user's machine. Following are common Microsoft GUIDs.
Type Used For
AppID Applications
CLSID COM object classes
IID Interfaces
MID Machines
OID Objects
SETID Set of objects
Other GUIDs
Other types of identifiers are also called GUIDs; for example, Atom feeds and some RSS feeds contain unique text-based numbers for each blog post. See Atom syndication format, UUID and OID.
Download Computer Desktop Encyclopedia to your PC, iPhone or Android.
|
|
This article uses bare URLs for citations. Please consider adding full citations so that the article remains verifiable. Several templates and the Reflinks tool are available to assist in formatting. (Reflinks documentation) (April 2012) |
|
|
It has been suggested that this article or section be merged with Universally unique identifier. (Discuss) Proposed since November 2010. |
A globally unique identifier (GUID, /ˈɡwɪd/ or
/ˈɡuːɪd/) is a unique reference number used as an identifier in computer software. The term GUID also is used by various implementations of the Universally unique identifier (UUID) standard.
The value of a GUID is represented as a 32-character hexadecimal string, such as {21EC2020-3AEA-1069-A2DD-08002B30309D}, and is usually stored as a 128-bit integer. The total number of unique keys is 2128 or 3.4×1038. This number is so large that the probability of the same number being generated randomly twice is negligible; however, GUID numbers are not always generated randomly.[1]
|
Contents
|
A GUID can be stored as a 16-byte (128-bit) number, which is usually split into four fields. The UUID standards [2] [3] state that all four fields must be encoded with the most significant byte first (i.e. Big-Endian). However, the reference for a commonly[4] used structure of the data type doesn't mention byte ordering.
| Bits | Bytes | Description | Endianness |
|---|---|---|---|
| 32 | 4 | Data1 | Big |
| 16 | 2 | Data2 | Big |
| 16 | 2 | Data3 | Big |
| 64 | 8 | Data4 | Big |
One to three of the most significant bits of the second byte in Data 4 define the type variant of the GUID:
| Pattern | Description |
|---|---|
| 0xx | Network Computing System backward compatibility |
| 10x | Standard |
| 110 | Microsoft Component Object Model backward compatibility; this includes the GUIDs for important interfaces like IUnknown and IDispatch |
| 111 | Reserved for future use |
The most significant four bits of Data3 define the version number, and the algorithm used.
A GUID is most commonly written in text as a sequence of hexadecimal digits separated into five groups, such as:
This text notation contains the following fields, separated by hyphens:
| Hex digits | Description |
|---|---|
| 8 | Data1 |
| 4 | Data2 |
| 4 | Data3 |
| 4 | Initial two bytes from Data4 |
| 12 | Remaining six bytes from Data4 |
For the first three fields, the most significant digit is on the left. The last two fields are treated as eight separate bytes, each having their most significant digit on the left, and they follow each other from left to right. Note that the digit order of the fourth field may be unexpected, since it's treated differently than in the structure.
Often braces are added to enclose the above format, as such:
When printing fewer characters is desired, GUIDs are sometimes encoded into a base64 or Ascii85 string.
A base64-encoded GUID consists of 22 to 24 characters (depending on padding), for instance:
and Ascii85 encoding gives 20 characters, for example:
In Uniform Resource Names (URN), the v1 GUIDs have namespace identifier "uuid", e.g.:
In the OSF-specified algorithm for generating new (V1) GUIDs, the user's network card MAC address is used as a base for the last group of GUID digits, which means, for example, that a document can be tracked back to the computer that created it. This privacy hole was used when locating the creator of the Melissa virus.[5] Most of the other digits are based on the time while generating the GUID.
V1 GUIDs which contain a MAC address and time can be identified by the digit "1" in the first position of the third group of digits, for example {2f1e4fc0-81fd-11da-9156-00036a0f876a}.
V4 GUIDs use the later algorithm, which is a pseudo-random number. These have a "4" in the same position, for example {38a52be4-9352-453e-af97-5c3b448652f0}. More specifically, the 'data3' bit pattern would be 0001xxxxxxxxxxxx in the first case, and 0100xxxxxxxxxxxx in the second. Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random, given full knowledge of the internal state, it is possible to predict previous and subsequent values.[6]
GUIDs are commonly used as the primary key of database tables, and with that, often the table has a clustered index on that attribute. This presents a performance issue when inserting records because a fully random GUID means the record may need to be inserted anywhere within the table rather than merely appended near the end of it.
As a way of mitigating this issue while still providing enough randomness to effectively prevent duplicate number collisions, several algorithms have been used to generate sequential GUIDs.
The first technique, described by Jimmy Nilsson in August 2002[7] and referred to as a "COMB" ("combined guid/timestamp"), replaces the last 6 bytes of Data4 with the least-significant 6 bytes of the current system date/time. While this can result in GUIDs that are generated out of order within the same fraction of a second, his tests showed this had little real-world impact on insertion. One side effect of this approach is that the date and time of insertion can be easily extracted from the value later, if desired.
Starting with Microsoft SQL Server version 2005, Microsoft added a function to the Transact-SQL language called NEWSEQUENTIALID(),[8] which generates GUIDs that are guaranteed to increase in value, but may start with a lower number (still guaranteed unique) when the server restarts. This reduces the number of database table pages where insertions can occur, but does not guarantee that the values will always increase in value. The values returned by this function can be easily predicted, so this algorithm is not well-suited for generating obscure numbers for security or hashing purposes.
In 2006, a programmer found that the SYS_GUID function provided by Oracle was returning sequential GUIDs on some platforms, but this appears to be a bug rather than a feature.[9]
In the Windows registry, in the key sequence "My Computer\HKEY_Classes_Root\CLSID", the DAO database management system identifies the particular version and type of accessing module of DAO to be used by a group of about a dozen GUIDs that begin with 5 zeros, a three-digit identifier for that particular version and type, with the remainder of the GUID ending in the same value in each case, 0000-0010-8000-00AA006D2EA4, so that the set of GUIDs used by this database system runs from {00000010-0000-0010-8000-00AA006D2EA4} through {00000109-0000-0010-8000-00AA006D2EA4} although not all GUIDs in that range are used.[citation needed]
In the Microsoft Component Object Model (COM), GUIDs are used to uniquely distinguish different software component interfaces. This means that two (possibly incompatible) versions of a component can have exactly the same name but still be distinguishable by their GUIDs. For example, in the creation of components for Microsoft Windows using COM, all components must implement the IUnknown interface to allow client code to find all other interfaces and features of that component, and they do this by creating a GUID which may be called upon to provide an entry point. The IUnknown interface is defined as a GUID with the value of {00000000-0000-0000-C000-000000000046}, and rather than having a named entry point called "IUnknown", the preceding GUID is used, thus every component that provides an IUnknown entry point gives the same GUID, and every program that looks for an IUnknown interface in a component always uses that GUID to find the entry point, knowing that an application using that particular GUID must always consistently implement IUnknown in the same manner and the same way.
GUIDs are also inserted into documents from Microsoft Office programs. Even audio or video streams in the Advanced Systems Format (ASF) are identified by their GUIDs.
A GUID's representation can be little endian or big endian, so all APIs need to ensure that the correct data structure is used.
There are several flavors of GUIDs used in COM:
DCOM introduces many additional GUID subtypes:
These GUID subspaces may overlap, as the context of GUID usage defines its subtype. For example, there might be a class using the same GUID for its CLSID as another class is using for its IID — all without a problem. On the other hand, two classes using the same CLSID could not co-exist.
There is also a guid element in some versions of the RSS specification, and a mandatory id element in Atom, which should contain a unique identifier for each individual article or weblog post. In RSS the contents of the GUID can be any text, and in practice is typically a copy of the article URL. Atom's IDs need to be valid URIs (usually URLs pointing to the entry, or URNs containing any other unique identifier).
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)