Formato para la identificación del video de YouTube

Cada video de YouTube tiene una identificación única que se puede utilizar para obtenerlo. Por ejemplo, el video en http://www.youtube.com/watch?v=aN46pEO_jX8tiene la identificación aN46pEO_jX8.

Después de algunas observaciones, me parece que estas identificaciones obedecen las siguientes dos reglas:

• Exactamente 11 caracteres
• Símbolos permitidos: az, AZ, 0-9, - y _

Quiero saber:

1. Si estas dos reglas son siempre correctas.
2. Si hay otras reglas que es importante seguir.

De acuerdo con la documentación de la API de Youtube 2.0 y la documentación de la API 3.0 , el videoId es una cadena, no se especifica nada sobre el conjunto actual de caracteres utilizados ...

Sobre la longitud de 11 caracteres, una publicación de un equipo de API de Youtube dice:

No veo en ninguna parte de la documentación donde nos comprometemos oficialmente a una longitud estándar de 11 caracteres para los identificadores de video de YouTube. Es una de esas cosas donde tenemos una implementación actual, y puede permanecer así indefinidamente. Pero no estamos ofreciendo ningún compromiso oficial con eso, así que proceda bajo su propio riesgo.

Y por último, pero no menos importante, otra publicación aclara (o no) el formato:

No hacemos ninguna garantía pública sobre el formato de los identificadores de video. Si bien actualmente son 11 cadenas de caracteres que contienen letras, números y algunos signos de puntuación, no recomendaría codificarlo en su aplicación (a menos que tenga una manera fácil de cambiarlo en el futuro).

El equipo de Youtube parece preferir preguntar directamente al servidor de Youtube si Video_ID es correcto o no (consulte un video existente):

Si necesita validar que la entrada aleatoria del usuario corresponde a una identificación de video válida, le recomiendo hacer una prueba empírica. Intentar acceder

http://gdata.youtube.com/feeds/api/videos/VIDEO_ID

Si obtiene una respuesta 200, entonces VIDEO_ID es válido. Si obtiene una respuesta que no sea 200, tiene una identificación no válida. Hay algunos casos extremos para los videos recién subidos o videos privados, pero para la mayoría de los propósitos, supongo que estaría bien.

Los identificadores videoId y channelId de YouTube son valores enteros individuales representados en una versión ligeramente modificada de la codificación Base64 . Una diferencia frente a las recomendaciones IETF RFC4648 es la sustitución de dos caracteres en el alfabeto de codificación:

 Payload  ASCII/Unicode      Base64     YouTube
 -------  -------------     ---------  ---------
  0...25  \x41 ... \x5A     'A'...'Z'  'A'...'Z'
 26...51  \x61 ... \x7A     'a'...'z'  'a'...'z'
 52...61  \x30 ... \x39     '0'...'9'  '0'...'9'
    62    \x2F vs. \x2D  →   '/' (2F)   '-' (2D)
    63    \x2B vs. \x5F  →   '+' (2B)   '_' (5F)

La sustitución probablemente se deba al hecho de que, por alguna razón, RFC4648 seleccionó dos caracteres que ya tenían funciones prominentes y bien establecidas en las URL. ^{[nota 1.]} Obviamente, para el uso en discusión aquí, es mejor evitar esa complicación particular.

Otra diferencia de la especificación oficial es que los identificadores de YouTube no usan el =carácter de relleno; no es necesario porque las longitudes codificadas esperadas por cada tamaño entero descodificado respectivo son fijas y conocidas (11 y 22 'dígitos' codificados para 64 y 128 bits, respectivamente).

Con una excepción menor (discutida más abajo), los detalles completos de la asignación de Base64 se pueden inferir de los datos de acceso público. Con un mínimo de conjeturas, es probable que el esquema Base64 utilizado en las cadenas videoId y channelId sea ​​el siguiente:

    ——₀————₁————₂————₃————₄————₅————₆————₇————₈————₉———₁₀———₁₁———₁₂———₁₃———₁₄———₁₅—
     00ᴴ  01ᴴ  02ᴴ  03ᴴ  04ᴴ  05ᴴ  06ᴴ  07ᴴ  08ᴴ  09ᴴ  0Aᴴ  0Bᴴ  0Cᴴ  0Dᴴ  0Eᴴ  0Fᴴ
00→ 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
      A    B    C    D    E    F    G    H    I    J    K    L    M    N    O    P

    —₁₆———₁₇———₁₈———₁₉———₂₀———₂₁———₂₂———₂₃———₂₄———₂₅———₂₆———₂₇———₂₈———₂₉———₃₀———₃₁—
     10ᴴ  11ᴴ  12ᴴ  13ᴴ  14ᴴ  15ᴴ  16ᴴ  17ᴴ  18ᴴ  19ᴴ  1Aᴴ  1Bᴴ  1Cᴴ  1Dᴴ  1Eᴴ  1Fᴴ
01→ 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
      Q    R    S    T    U    V    W    X    Y    Z    a    b    c    d    e    f

    —₃₂———₃₃———₃₄———₃₅———₃₆———₃₇———₃₈———₃₉———₄₀———₄₁———₄₂———₄₃———₄₄———₄₅———₄₆———₄₇—
     20ᴴ  21ᴴ  22ᴴ  23ᴴ  24ᴴ  25ᴴ  26ᴴ  27ᴴ  28ᴴ  29ᴴ  2Aᴴ  2Bᴴ  2Cᴴ  2Dᴴ  2Eᴴ  2Fᴴ
10→ 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
      g    h    i    j    k    l    m    n    o    p    q    r    s    t    u    v

    —₄₈———₄₉———₅₀———₅₁———₅₂———₅₃———₅₄———₅₅———₅₆———₅₇———₅₈———₅₉———₆₀———₆₁———₆₂———₆₃—
     30ᴴ  31ᴴ  32ᴴ  33ᴴ  34ᴴ  35ᴴ  36ᴴ  37ᴴ  38ᴴ  39ᴴ  3Aᴴ  3Bᴴ  3Cᴴ  3Dᴴ  3Eᴴ  3Fᴴ
11→ 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111
      w    x    y    z    0    1    2    3    4    5    6    7    8    9    -    _

La razón para creer que se está utilizando Base64 es que, cuando asumimos tamaños enteros estándar de 64 y 128 bits para la entrada del codificador, Base64 predice las longitudes de caracteres inusuales (11 y 22 caracteres) de los identificadores channelId y videoId de YouTube exactamente. Además, los residuos calculados según Base64 explican perfectamente la variación distribucional observada que se encuentra en l̲a̲s̲t̲ c̲h̲a̲r̲a̲c̲t̲e̲r̲ de cada tipo de cadena de identificación. La discusión de estos puntos sigue.

En ambos casos, los "datos" binarios que se codifican en Base64 son un solo número entero, ya sea 64 o 128 bits, para (respectivamente) videoId versus channelId . En consecuencia, mediante el uso de un decodificador Base64, se puede recuperar un solo entero del identificador de cadena, y puede ser bastante útil hacerlo porque, mientras que cada ID de entero contiene exactamente la misma información que la cadena Base64, y también permite que la cadena volver a crearse en cualquier momento: en comparación con las cadenas Base64 almacenadas como Unicode, la representación binaria es un 63% más pequeña, tiene una densidad de bits máxima del 100%, se alinea mejor en la memoria, ordena y pica más rápido y, quizás lo más importante, elimina falsas colisiones entre identificadores que difieren solo en caso ortográfico. Este último problema, aunque extremadamente improbable numéricamente, no se puede descartar cuando las ID de Base64 se tratan como mayúsculas y minúsculas, como lo hacen algunos sistemas de archivos (por ejemplo , Windows , que se remonta a DOS ).

Eso es un poco importante: si está utilizando una cadena videoId / channelId como parte de un nombre de archivo de Windows / NTFS, existe una posibilidad minúscula, pero no distinta de cero, de colisiones de nombres de archivo debido a que los sistemas de archivos implementan una ruta sin distinción entre mayúsculas y minúsculas y nombres de archivos .

Si le preocupa este problema remotamente posible, una forma de eliminarlo matemáticamente sería volver a codificar los enteros decodificados, que todavía se obtienen como se describe en este artículo, en una base 10 (decimal) o (uniforme) representación hexadecimal, para usar en rutas o nombres de archivos en dichos sistemas de archivos. ^{[nota 2.]} En este enfoque, el videoId de 64 bits necesitaría 20 dígitos decimales [0-9]u 8 dígitos hexadecimales [0-9,A-F]( frente a 11 dígitos Base64). El channelId de 128 bits requeriría un máximo de 39 dígitos decimales o 16 dígitos hexadecimales ( frente a 22 dígitos Base64).

La decodificación en binario es trivial para el caso de 64 bits porque puede usar un UInt64( ulongen C # ) para mantener el valor binario nativo que regresa.

/// <summary> Recover the unique 64-bit value from an 11-character videoID </summary>
/// <remarks>
/// The method of padding shown here (i.e. 'b64pad') is provided to demonstrate the
/// full and correct padding requirement for Base64 in general. For our cases:
///
///    videoId    →  11 chars  →  b64pad[11 % 3]  →  b64pad[2]  →  "="
///    channelId  →  22-chars  →  b64pad[22 % 3]  →  b64pad[1]  →  "=="
///
/// Note however that, because it returns 'ulong', this function only works for videoId 
/// values, and the padding will always end up being "=". This is assumed in the revised
/// version of this code given further below, by just hard-coding the value "=".
/// </remarks>

static ulong YtEnc_to_videoId(String ytId)
{
    String b64 = ytId.Replace('-', '+').Replace('_', '/') + b64pad[ytId.Length % 3];

    return BitConverter.ToUInt64(Convert.FromBase64String(b64), 0);
}

static String[] b64pad = { "", "==", "=" };

Para el caso de los valores de 128 bits , es un poco más complicado porque, a menos que su compilador tenga una __int128representación, tendrá que encontrar una manera de almacenar todo y mantenerlo combinado mientras lo pasa. Un tipo de valor simple (o System.Numerics.Vectors.Vector<T>, que se manifiesta como un registro de hardware SIMD de 128 bits, cuando esté disponible) hará el truco en .NET (no se muestra).

[ editar: ]
Después de pensarlo más, una parte de mi publicación original no estaba completa al máximo. Para ser justos, se conserva el extracto original (puede omitirlo si lo desea); Inmediatamente a continuación explico la información faltante:

[ original: ]
Puede que hayas notado anteriormente que escribí que puedes recuperar " un " número entero. ¿No sería este el valor codificado originalmente? No necesariamente. Y no estoy aludiendo a la distinción con signo / sin signo que, es cierto, no se puede determinar aquí (porque no cambia ningún hecho sobre la imagen binaria). Son los valores numéricos mismos: sin algo de " Rosetta Stone"eso nos permitiría realizar una verificación cruzada con valores absolutos que se sabe que son" correctos ", el mapeo alfabético numérico y también la endianidad no se pueden conocer positivamente, lo que significa que no hay garantía de que esté recuperando el mismo valor que las computadoras en YouTube codificaron. Afortunadamente, mientras YouTube nunca exponga públicamente los llamados valores correctos en un formato menos opaco en otro lugar, esto no puede importar.

Esto se debe a que los valores decodificados de 64 o 128 bits no tienen uso, excepto como un token de identificación de todos modos, por lo que nuestros únicos requisitos para la transformación son la codificación distinta (no chocan dos tokens únicos) y la reversibilidad (la decodificación recupera la identidad del token original).

En otras palabras, todo lo que realmente nos importa es el disparo redondo sin pérdidas de la cadena Base64 original. Dado que Base64 no tiene pérdidas y es reversible (siempre y cuando siempre cumpla con el mismo mapeo alfabético y la suposición de endianness tanto para la codificación como para la decodificación) satisface nuestros propósitos. Es posible que sus valores numéricos no coincidan con los registrados en la bóveda maestra de YouTube, pero no podrá notar ninguna diferencia.

---

[ Nuevo análisis: ]
Resulta que hay son algunas pistas que pueden decirnos acerca de la "verdadera" base 64 de mapeo. Solo ciertas asignaciones predicen los caracteres de posición final que observamos, lo que significa que el valor binario de solo esos caracteres debe tener un cierto número de ceros LSB. Je

En conjunto con la suposición abrumadoramente probable de que los caracteres del alfabeto y los dígitos están mapeados en orden ascendente, básicamente podemos confirmar que el mapeo es lo que se muestra en las tablas anteriores. La única incertidumbre restante sobre la cual el análisis LSB no es concluyente es el posible intercambio de los caracteres -y _( 62/ 63).

El texto original hizo discutir este tema LSB (véase más adelante), pero lo que no me había dado cuenta plenamente en el momento era cómo LSB información actúa para restringir los posibles base 64 asignaciones.

Un último comentario sobre esto es que, de hecho, es posible que desee elegir intencionalmente big-endian para la interpretación binaria con la que trabaja internamente su aplicación (a pesar de que hoy en día es menos común que little-endian y, por lo tanto, podría no ser la forma en que YouTube 'oficialmente' lo hace eso). La razón es que este es un caso de vistas duales en el mismo valor, de modo que el orden de bytes real está visiblemente expuesto en la representación de Base64. Es útil y menos confuso mantener el orden de clasificación coherente entre el valor binario y la cadena Base64 legible por humanos (algo más), pero el tipo de valores binarios little endian es una mezcla no trivial del tipo ASCII / léxico deseado. .

No hay una solución simple para este problema si comienzas con valores de ID little-endian (es decir, simplemente revertir su clasificación no funcionará). En su lugar, debe planificar con anticipación e invertir los bytes de cada valor binario en el momento de la decodificación . Entonces, si le importa que la visualización alfabética coincida con la clasificación de los valores binarios, es posible que desee alterar la función que se muestra arriba para que decodifique en valores big-endian ulong . Aquí está ese código:

// Recover the unique 64-bit value (big-endian) from an 11-character videoID
static ulong YtEnc_to_videoId(String ytId)
{
    var a = Convert.FromBase64String(ytId.Replace('-', '+').Replace('_', '/') + "=");
    if (BitConverter.IsLittleEndian)   // true for most computers nowadays
        Array.Reverse(a); 
    return BitConverter.ToUInt64(a, 0);
}

ID de YouTube

ID del video

Para el videoId , es un entero de 8 bytes (64 bits). La aplicación de codificación Base64 a 8 bytes de datos requiere 11 caracteres . Sin embargo, dado que cada carácter Base64 transmite exactamente 6 bits (es decir, 2⁶ es igual a 64), esta asignación podría contener hasta 11 × 6 = 66bits, un excedente de 2 bits sobre los 64 bits que necesita nuestra carga útil. El exceso de bits se establece en cero, lo que tiene el efecto de excluir que ciertos caracteres aparezcan en la última posición de la cadena codificada. En particular, se garantiza que el videoId siempre terminará con uno de los siguientes caracteres:

{ A, E, I, M, Q, U, Y, c, g, k, o, s, w, 0, 4, 8 }

Por lo tanto, la expresión regular (RegEx) con restricciones máximas para el videoId sería la siguiente:

[0-9A-Za-z_-]{10}[048AEIMQUYcgkosw]

ID de canal o lista de reproducción

Las cadenas channelId y playlistId se producen codificando Base64 en un entero binario de 128 bits (16 bytes). Esto proporciona una cadena de 22 caracteres que puede tener el prefijo UCpara identificar el canal en sí o UUpara identificar una lista de reproducción completa de los videos que contiene. Estas cadenas prefijadas de 24 caracteres se usan en las URL . Por ejemplo, a continuación se muestran dos formas de referirse al mismo canal. Observe que la versión de la lista de reproducción muestra el número total de videos en el canal, ^{[vea la nota 3.]} una información útil que las páginas del canal no exponen.

URL del canal

https://www.youtube.com/channel/UC K8sQmJBp8GCxrOtXWBpyEA

URL de lista de reproducción

https://www.youtube.com/playlist?list=UU K8sQmJBp8GCxrOtXWBpyEA

Como fue el caso con el videoId de 11 caracteres , el cálculo por Base64 predice correctamente la longitud de cadena observada de 22 caracteres . En este caso, la salida es capaz de codificar 22 × 6 = 132bits, un excedente de 4 bits; esos ceros terminan restringiendo que m̲o̲s̲t̲ de los 64 símbolos del alfabeto aparezcan en la última posición, con solo 4 restantes elegibles. Por lo tanto, sabemos que el último carácter en una cadena channelId de YouTube debe ser uno de los siguientes:

{ A, Q, g, w }

Esto nos da la expresión regular con restricciones máximas para un channelId :

[0-9A-Za-z_-]{21}[AQgw]

Como nota final, las expresiones regulares que se muestran arriba describen solo los valores de ID desnudos, sin los prefijos, barras, separadores, etc., que deben estar presentes en las URL y los otros usos. Los patrones RegEx que presenté son matemáticamente mínimos, dadas las propiedades de las cadenas de identificación, pero si se usan tal cual sin contexto adicional, probablemente generarán muchos falsos positivos, es decir: coinciden incorrectamente el texto falso. Para evitar este problema en el uso real, enciérrelos con la mayor cantidad de contexto adyacente posible.

Notas

[1.]
Como se prometió anteriormente, aquí hay un extracto de la especificación Base64 que analiza sus consideraciones al seleccionar los símbolos del alfabeto. Las personas que buscan entender cómo concluyó el proceso en la selección de caracteres con semántica de URL pueden encontrar las explicaciones algo poco edificantes.

3.4. Elegir el alfabeto

Las diferentes aplicaciones tienen diferentes requisitos sobre los caracteres del alfabeto. Aquí hay algunos requisitos que determinan qué alfabeto se debe usar:

• Manejado por humanos. Los caracteres "0" y "O" se confunden fácilmente, al igual que "1", "l" e "I". En el siguiente alfabeto base32, donde 0 (cero) y 1 (uno) no están presentes, un decodificador puede interpretar 0 como O y 1 como I o L, según el caso. (Sin embargo, por defecto no debería; consulte la sección anterior).

• Codificado en estructuras que exigen otros requisitos. Para la base 16 y la base 32, esto determina el uso de alfabetos en mayúsculas o minúsculas. Para la base 64, los caracteres no alfanuméricos (en particular, "/") pueden ser problemáticos en los nombres de archivos y URL.

• Usado como identificadores. Ciertos caracteres, especialmente "+" y "/" en el alfabeto de base 64, son tratados como saltos de palabras por las herramientas de búsqueda / índice de texto heredado.

No existe un alfabeto universalmente aceptado que cumpla con todos los requisitos. Para ver un ejemplo de una variante altamente especializada, consulte IMAP [8]. En este documento, documentamos y nombramos algunos alfabetos utilizados actualmente.

[2.]
Alternativamente, para resolver el problema del uso de cadenas de identificación codificadas en Base64 como componentes "tal cual" de los nombres de archivo o ruta en el sistema de archivos NTFS, que no distingue entre mayúsculas y minúsculas por defecto (y por lo tanto técnicamente corre el riesgo de combinar uno o más valores de ID no relacionados), sucede que NTFS se puede configurar con nombres de ruta / archivo sensibles a mayúsculas y minúsculas por volumen. Habilitar el comportamiento no predeterminado puede solucionar el problema descrito aquí, pero rara vez se recomienda, ya que altera las expectativas para cualquiera / todas las aplicaciones dispares que inspeccionan o acceden al volumen. Si incluso está considerando esta opción, lea y comprenda esto primero, y probablemente cambiará de opinión.

[3.]
Creo que el número total de videos que se muestran en la página de la lista de reproducción del canal tiene en cuenta la exclusión de videos que están restringidos de acuerdo con la región geográfica del cliente HTTP. Esto explica cualquier discrepancia entre la cantidad de videos enumerados para la lista de reproducción frente al canal.