YouTube videosunun kimliği için biçim

Her YouTube videosu, ulaşmak için kullanılabilecek benzersiz bir kimliğe sahiptir. Örneğin, adresindeki videonun http://www.youtube.com/watch?v=aN46pEO_jX8kimliği var aN46pEO_jX8.

Bazı gözlemlerden sonra, bu kimlikleri aşağıdaki iki kurala uyuyor gibi görünüyor:

• Tam olarak 11 karakter
• İzin verilen semboller: az, AZ, 0-9, - ve _

Bilmek istiyorum:

1. Bu iki kuralın ikisinin de daima doğru olup olmadığı.
2. Uyulması gereken başka kurallar varsa.

Youtube 2.0 API belgelerine ve 3.0 API belgelerine göre, videoId bir dizedir, kullanılan mevcut karakter kümesiyle ilgili hiçbir şey belirtilmemiştir ...

Yaklaşık 11 karakter uzunluğunda, Youtube API Ekibinden bir gönderi şöyle der:

Resmi olarak YouTube video kimlikleri için 11 karakterlik standart bir uzunluğu taahhüt ettiğimiz belgelerde hiçbir yerde göremiyorum. Mevcut bir uygulamamıza sahip olduğumuz şeylerden biri ve süresiz olarak böyle kalabilir. Ancak bunun için herhangi bir resmi taahhütte bulunmuyoruz, bu nedenle kendi sorumluluğunuzdadır.

Ve sonuncusu fakat en az değil, başka bir yazı biçimi açıklığa kavuşturur (veya açıklamaz ):

Video kimliklerinin formatı hakkında herhangi bir genel garanti vermiyoruz. Şu anda harfler, sayılar ve bazı noktalama işaretleri içeren 11 karakter dizgileri olsa da, bunu uygulamanıza kodlamanızı tavsiye etmem (ileride değiştirmek için kolay bir yolunuz yoksa).

Youtube ekibi Video_ID'nin doğru olup olmadığını doğrudan Youtube sunucusuna sormayı tercih ediyor gibi görünüyor (mevcut bir videoya bakın):

Rastgele kullanıcı girişinin geçerli bir video kimliğine karşılık geldiğini doğrulamanız gerekiyorsa, deneysel bir test yapmanızı öneririm. Erişmeye çalış

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

200 yanıt alırsanız, VIDEO_ID geçerlidir. 200 olmayan bir yanıt alırsanız, geçersiz bir kimliğiniz vardır. Yeni yüklenen videolar veya özel videolar için bazı son durumlar vardır, ancak çoğu amaç için bunun iyi olacağını düşünürdüm.

YouTube video kimliği ve kanal kimliği tanımlayıcıları, Base64 kodlamasının biraz değiştirilmiş bir sürümünde temsil edilen tek tam sayı değerleridir . IETF RFC4648 tavsiyelerine göre bir fark , kodlama alfabesindeki iki karakterin yerine konmasıdır :

 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)

Değişim , bir nedenden ötürü RFC4648’in URL’lerde belirgin ve sağlam işlevleri olan iki karakter seçmesinden kaynaklanıyor olabilir . ^{[not 1.]} Açıkçası, burada tartışılan kullanım için, belirli bir komplikasyonun en iyi şekilde engellenmesi gerekiyordu.

Resmi şartnameden bir başka fark, YouTube tanımlayıcılarının =doldurma karakterini kullanmamasıdır ; gerekli değildir, çünkü kod çözülmüş tamsayı büyüklüğü başına beklenen kodlanmış uzunluklar sabittir ve bilinir (sırasıyla 64 ve 128 bitler için 11 ve 22 kodlanmış 'basamaklar').

Küçük bir istisna dışında (aşağıda tartışılmıştır), Base64 eşlemesinin tüm detayları kamuya açık verilerden çıkarılabilir. Asgari bir tahminle, videoId ve channelId dizelerinde kullanılan Base64 şemasının aşağıdaki gibi olması muhtemeldir :

    ——₀————₁————₂————₃————₄————₅————₆————₇————₈————₉———₁₀———₁₁———₁₂———₁₃———₁₄———₁₅—
     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    -    _

Base64'ün kullanıldığına inanmanın nedeni, enkoder girişi için 64 ve 128 bitlik standart tamsayı boyutlarını aldığımızda , Base64'ün YouTube kanalı ve video kimliği tanımlayıcılarının olağandışı karakter uzunluklarını (11 ve 22 karakter) tam olarak tahmin etmesidir . Bundan başka, kalanlar mükemmel bulunan gözlenen dağılım varyasyonu açıklar Base64 göre hesaplanan son karakter tanımlayıcının dize her tür. Bu noktaların tartışılması takip eder.

Her iki durumda da, Base64 ile kodlanan ikili "veri" (sırasıyla) videoId'ye karşı channelId için 64 veya 128 bit olan tek bir tam sayıdır . Buna göre, bir Base64 kod çözücüsü kullanılarak, dize tanımlayıcısından tek bir tam sayı elde edilebilir ve bunu yapmak oldukça yararlı olabilir, çünkü her tamsayı kimliği tam olarak Base64 dizesiyle aynı bilgileri içerirken ve dizgenin herhangi bir zamanda yeniden oluşturulabilir - Unicode olarak depolanan Base64 dizeleriyle karşılaştırıldığında, ikili gösterimi% 63 daha küçüktür,% 100'lük maksimum bit yoğunluğuna sahiptir, bellekte daha iyi hizalanır, sıralar ve karmaları daha hızlı ve belki de en önemlisi ortadan kaldırır sadece ortografik durumda farklı olan tanımlayıcılar arasındaki yanlış çarpışmalar. Bu son sorun, sayısal olarak son derece olanaksız olsa da, Base64 ID'leri bazı dosya sistemlerinde olduğu gibi (örneğin , DOS'a dayanan Windows gibi) büyük / küçük harf duyarlı olarak değerlendirildiğinde göz ardı edilemez .

Bu çok önemli: bir Windows / NTFS dosya adının bir parçası olarak bir videoId / channelId dizgisi kullanıyorsanız, kaybolan bir miniklik var - ancak yine de sıfır olmayan — dosya adında bir büyük harf duyarsız yol ve dosya adlandırma kullanan dosya sistemleri nedeniyle .

Bu uzaktan olası sorun hakkında endişeleniyorsanız, matematiksel olarak ortadan kaldırmanın bir yolu, hala bu makalede açıklandığı gibi elde edilen kodu çözülmüş tamsayıları bir baz-10 (ondalık) veya (tekdüze) şeklinde yeniden kodlamak olacaktır. cased) onaltılık gösterim, bu tür dosya sistemlerinde yol veya dosya adlarında kullanım için. ^{[not 2.]} Bu yaklaşımda, 64 bit videoId 20 ondalık rakam gerekir [0-9]ya da 8 heks basamak [0-9,A-F]( genel 11 Base64 basamağı). 128 bit channelId , en fazla 39 ondalık basamak veya 16 onaltılık basamak gerektirir ( vs. 22 Base64 basamak).

İkili kodunu çözmek için önemsiz , 64-bit bir kullanabilir çünkü durumunda UInt64( ulongin C # geri gelir ikil değerini tutmak için).

/// <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 = { "", "==", "=" };

Durumunda için 128 bit değerlerinin, bu derleyici bir olmadıkça, çünkü biraz daha yanıltıcıdır __int128temsilini, her şeyi depolamak ve tutmak için bir yol dışarı rakam gerekecek combobulated bunu etrafında geçerken. Basit bir değer türü (veya varsa System.Numerics.Vectors.Vector<T>128 bitlik bir SIMD donanım kaydı olarak görünen), hileyi .NET'te (gösterilmemiştir) gerçekleştirir.

[ değiştir: ]
Daha fazla düşündükten sonra, asıl gönderimin bir kısmı azami derecede tamamlanmadı. Adalet için asıl alıntı korunur (istenirse atlayabilirsiniz); hemen aşağıda eksik kavrayışı açıklıyorum:

[ original: ]
Yukarıda " bir " tamsayı kurtarabileceğinizi yazdığımı fark etmiş olabilirsiniz . Bu başlangıçta kodlanmış olan değer olmaz mıydı? Şart değil. Ve burada doğru olmadığı tespit edilemeyen imzalı / imzasız ayrımdan bahsetmiyorum (çünkü ikili imge hakkındaki gerçekleri değiştirmez). Sayısal değerlerin kendileri: Bazı " Rosetta Stone'suz"bu," doğru "olduğu bilinen mutlak değerlerle çapraz kontrol yapmamızı sağlar, sayısal alfabe eşlemesi ve ayrıca endianity, pozitif olarak bilinemez; YouTube’daki bilgisayarlar şifreli. Neyse ki, YouTube, sözde doğru değerleri daha az opak olmayan bir biçimde başka bir yerde herkese açık bir şekilde göstermediği sürece, bu önemli olamaz.

Bunun nedeni, kodu çözülmüş 64 veya 128 bitlik değerlerin, belirleyici bir belirteç dışında hiçbir kullanımının olmamasıdır, bu yüzden dönüşüm için tek gereksinimlerimiz, farklı kodlama (iki benzersiz belirteç çarpışmaz) ve tersine çevrilebilirliktir (kod çözme, orijinal belirteç kimliğini kurtarır).

Başka bir deyişle, tek umursadığımız şey, orijinal Base64 dizisinin kayıpsız yuvarlak şekilde atılması. Base64 kayıpsız ve geri dönüşümlü olduğundan (her zaman hem kodlama hem de kod çözme için aynı alfabe eşlemesine ve endianness varsayımına sadık kaldığınız sürece ) amaçlarımızı yerine getirir . Sayısal değerleriniz, YouTube'un ana kasasına kaydedilenlerle eşleşmeyebilir, ancak herhangi bir fark söyleyemezsiniz.

---

[ Yeni analiz: ]
Orada çıkıyor olan "gerçek" bahseder birkaç ipucu Base64 haritalama. Yalnızca belirli eşlemeler gözlemlediğimiz son konum karakterlerini tahmin eder; bu, yalnızca bu karakterlerin ikili değerinin belirli sayıda LSB sıfırına sahip olması gerektiği anlamına gelir . Heh.

Alfabenin ve rakam karakterlerinin artan sırada eşleştirildiği konusunda büyük olasılıkla kabul edilmiş varsayım ile birlikte ele alındığında, haritalamayı yukarıdaki tablolarda gösterilenler olarak temelde doğrulayabiliriz. LSB analizinin sonuçsuz kaldığı tek belirsizlik kalan -ve _karakterlerinin ( 62/ 63) değişmesidir .

Orijinal metin yaptığı bu LSB sorunu (daha fazla aşağıya bakınız) tartışmak, ama ne tam olarak anda fark etmedi bilgilerin mümkün kısıtlamak davranıyor LSB oldu Base64 eşleştirmeleri.

Bununla ilgili son bir yorum, aslında uygulamanızın dahili olarak çalıştığı ikili yorumlama için kasıtlı olarak büyük-endian'ı seçmek isteyebilirsiniz ( bugünlerde küçük-endian'dan daha az yaygın olsa da YouTube'un 'resmi olarak' yaptığı gibi olmayabilir). o). Bunun nedeni, gerçek byte sırasının Base64 yorumunda gözle görülür şekilde ortaya çıkması için aynı değerde ikili görünümlerin bir durumudur. Sıralama düzenini ikili değer ile (biraz daha fazla) insan tarafından okunabilen Base64 dizgisi arasında tutarlı tutmak yararlı ve daha az kafa karıştırıcıdır , ancak küçük endian ikili değerlerinin sıralaması istenen ASCII / sözcük sıralamasının önemsiz bir çabasıdır .

Endian kimliği değerleriyle başlarsanız (yani sıralamalarını tersine çevirmek işe yaramaz) bu sorun için basit bir düzeltme yoktur. Bunun yerine, kod çözme sırasında her ikilik değerin baytını önceden planlayıp tersine çevirmeniz gerekir . Bu nedenle, ikili değerlerin sıralamasıyla eşleşen alfabetik göstergeyi önemsiyorsanız, yukarıda gösterilen işlevi değiştirmek yerine büyük-endian ulong değerlerine dönüşmesini isteyebilirsiniz . İşte bu kod:

// 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);
}

YouTube kimlikleri

Video Kimliği

İçin VideoId , bir 8 bayt (64 bit) bir tam sayıdır. Base64 kodlamasını 8 bayt veriye uygulamak için 11 karakter gerekir . Bununla birlikte, her bir Base64 karakteri tam olarak 6 bit (yani, 2 64, 64'e eşittir) taşıdığından, bu tahsis aslında 11 × 6 = 6664 bitleri tutabilir - 64 bitin üzerinde 2 bitlik bir artı-yük ihtiyacımız. Aşırı bit, sıfıra ayarlanmıştır; bu, kodlanmış dizenin son konumunda belirli karakterlerin hiç görünmemesini engelleyen etkiye sahiptir. Özellikle videoId'nin daima aşağıdaki karakterlerden biriyle biteceği garanti edilir:

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

Bu nedenle, videoId için maksimum kısıtlı düzenli ifade (RegEx) aşağıdaki gibi olacaktır:

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

Kanal veya Oynatma Listesi No

KanalNo ve playlistId şeritler 128 bitlik (16 bayt) bir ikili tamsayı Base64 kodlayan üretilir. Bu UC, kanalın kendisini tanımlamak için ya UUda içerdiği videoların tam oynatma listesini tanımlamak için önek eklenebilir 22 karakterli bir dize verir . Bu 24 karakterli önekli dizeler URL'lerde kullanılır . Örneğin, aşağıda aynı kanala atıfta bulunmak için iki yol gösterilmektedir. Çalma listesi sürümünün kanaldaki toplam video sayısını gösterdiğine ^{dikkat edin} ; ^{[not 3.]} kanal sayfalarının göstermediği yararlı bir bilgi parçasıdır.

Kanal URL'si

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

Oynatma listesi URL'si

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

11 karakterlik videoId'de olduğu gibi , Base64'e göre hesaplama, 22 karakterden oluşan gözlemlenen dize uzunluğunu doğru tahmin eder . Bu durumda, çıktı 22 × 6 = 1324 bitlik bir artı olan bitleri kodlama yeteneğine sahiptir ; bu sıfırlar, 64 alfabe sembolünün m̲o̲s̲t last'ının son konumda görünmesini engeller, sadece 4 tanesi kaldı. Bu nedenle, bir YouTube channelId dizesindeki son karakterin aşağıdakilerden biri olması gerektiğini biliyoruz:

{ A, Q, g, w }

Bu bize bir channelId için maksimum kısıtlı düzenli ifade verir :

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

Son bir not olarak, yukarıda gösterilen normal ifadeler, yalnızca URL'lerde ve diğer çeşitli kullanımlarda bulunması gereken önek, eğik çizgi, ayırıcı vb. Olmadan çıplak kimlik değerlerini açıklar. Sunulan RegEx desenleri, tanımlayıcı dizgelerin özellikleri göz önüne alındığında mümkün olduğu kadar matematiksel olarak minimum düzeydedir, ancak ek bağlam olmadan olduğu gibi kullanılması durumunda, muhtemelen birçok yanlış pozitif üretecektir, yani: yanlış metin sahte eşleşir. Gerçek kullanımda bu sorunu önlemek için, onları mümkün olan en fazla bitişik bağlamla çevreleyin.

Notlar

[1.]
Yukarıda söz verildiği gibi, burada, alfabe sembollerini seçmedeki dikkatlerini tartışan Base64 şartnamesinden bir alıntıdır . URL semantiğine sahip karakterlerin seçiminde sürecin nasıl sonuçlandığını anlamaya çalışan bireyler açıklamaları biraz değiştirici bulabilirler.

3.4. Alfabeyi Seçmek

Farklı uygulamaların alfabedeki karakterlerde farklı gereksinimleri vardır. Hangi alfabenin kullanılması gerektiğini belirleyen birkaç gereksinim:

• İnsanlar tarafından işlenir. "0" ve "O" karakterleri, "1", "l" ve "I" harfleriyle kolayca karıştırılır. Alttaki32 alfabesinde, 0 (sıfır) ve 1 (bir) bulunmadığında, bir kod çözücü, duruma bağlı olarak 0, O veya 1, I veya L olarak yorumlayabilir. (Ancak, varsayılan olarak olmamalıdır; önceki bölüme bakınız.)

• Diğer gereklilikleri zorunlu kılan yapılara kodlanmıştır. Taban 16 ve taban 32 için, bu, büyük veya küçük harf alfabe kullanımını belirler. 64 tabanı için, alfasayısal olmayan karakterler (özellikle "/") dosya adlarında ve URL'lerde sorunlu olabilir.

• Tanımlayıcı olarak kullanılır. Temel 64 alfabesinde belirli karakterler "özellikle" + "ve" / ", eski metin arama / dizin araçları tarafından sözcük sonları olarak değerlendirilir.

Tüm gereklilikleri yerine getiren evrensel olarak kabul edilmiş bir alfabe yoktur. Çok özel bir değişken örneği için IMAP [8] 'e bakınız. Bu belgede, şu anda kullanılan bazı alfabeleri belgeliyoruz ve isimlendiriyoruz.

[2]
Alternatif olarak, Base64 ile kodlanmış ID dizgilerinin, NTFS dosya sistemindeki "olduğu gibi" bileşenleri olduğu gibi, varsayılan olarak büyük / küçük harf duyarlılığı olmayan (ve bu nedenle teknik olarak bir veya daha fazlasının birleştirilmesi riskini doğurabilir) çözme ilgisiz kimlik değerleri), böylece NTFS birim başına büyük / küçük harf duyarlı yol / dosya adlandırma ile yapılandırılabilir . Varsayılan olmayan davranışı etkinleştirmek, burada açıklanan sorunu giderebilir, ancak nadiren önerilir, çünkü hacmi denetleyen veya bunlara erişen farklı uygulamalar için beklentileri değiştirir. Bu seçeneği düşünüyorsanız bile, önce bunu okuyun ve anlayın , muhtemelen fikrinizi değiştirirsiniz.

[3.]
Kanal oynatma listesi sayfasının gösterilen toplam video sayısının, HTTP istemcisinin coğrafi bölgesine göre kısıtlanan videoların hariç tutulduğunu dikkate aldığına inanıyorum. Bu, oynatma listesi için kanala listelenen videoların sayısı ile kanal arasında herhangi bir tutarsızlık olduğunu gösterir.