Function CMMetadataCreateIdentifierForKeyAndKeySpace 

pub unsafe extern "C-unwind" fn CMMetadataCreateIdentifierForKeyAndKeySpace(
    allocator: Option<&CFAllocator>,
    key: &CFType,
    key_space: &CFString,
    identifier_out: NonNull<*const CFString>,
) -> i32

Available on crate feature CMMetadata only.

Creates a URL-like string identifier that represents a key/keyspace tuple.

Metadata entities are identified by a key whose interpretation is defined by its keyspace. When writing metadata to a QuickTime Movie, this tuple is part of the track’s format description.

The following constants make up the current list of supported keyspaces, which are documented elsewhere in this file:

kCMMetadataKeySpace_QuickTimeUserData
• kCMMetadataKeySpace_ISOUserData
• kCMMetadataKeySpace_iTunes
• kCMMetadataKeySpace_ID3
• kCMMetadataKeySpace_QuickTimeMetadata
• kCMMetadataKeySpace_Icy

Some keyspaces use OSTypes (a.k.a. FourCharCodes) to define their keys, and as such their keys are four bytes in length. The keyspaces that fall into this category are: kCMMetadataKeySpace_QuickTimeUserData, kCMMetadataKeySpace_ISOUserData, kCMMetadataKeySpace_iTunes, and kCMMetadataKeySpace_ID3.

The keyspace kCMMetadataKeySpace_QuickTimeMetadata defines its key values to be expressed as reverse-DNS strings, which allows third parties to define their own keys in a well established way that avoids collisions.

As a matter of convenience, known keyspaces allow for a key to be passed in using a variety of CFTypes. Note that what is returned by CMMetadataCreateKeyFromIdentifier depends upon the keyspace, and may be a different CFType than what is passed to this routine (see the discussion below for what CFTypes are returned for known keyspaces). To get a key represented as CFData, call CMMetadataCreateKeyFromIdentifierAsCFData.

For OSType keyspaces, a key may be passed as a CFNumber, a CFString, or a CFData. A key passed as a CFNumber will have its value retrieved as kCFNumberSInt32Type comprising the four bytes of the key’s numeric value in big-endian byte order. A key passed as a CFString must be a valid ASCII string of four characters. A key passed as a CFData must be comprised of the four bytes of the key’s numeric value in big-endian byte order.

All other keyspaces allow the key to be passed as a CFString or CFData. In both cases, the key will be interpreted as an ASCII string for the purposes of identifier encoding.

Safety

• key should be of the correct type.
• identifier_out must be a valid pointer.