Định dạng cho ID của video YouTube

Mỗi video YouTube có một ID duy nhất có thể được sử dụng để lấy nó. Ví dụ: video tại http://www.youtube.com/watch?v=aN46pEO_jX8có id aN46pEO_jX8.

Sau khi quan sát, có vẻ như những ID này tuân theo hai quy tắc sau:

• Chính xác là 11 ký tự
• Các ký hiệu được phép: az, AZ, 0-9, - và _

Tôi muốn biết:

1. Cho dù hai quy tắc này đều luôn luôn đúng.
2. Nếu có bất kỳ quy tắc khác quan trọng để làm theo.

Theo tài liệu API Youtube 2.0 và tài liệu API 3.0 , videoId là một chuỗi, không có gì được chỉ định về bộ ký tự hiện tại được sử dụng ...

Về độ dài 11 ký tự, một bài đăng từ Nhóm API Youtube cho biết:

Tôi không thấy bất cứ nơi nào trong tài liệu mà chúng tôi chính thức cam kết độ dài tiêu chuẩn là 11 ký tự cho id video YouTube. Đó là một trong những điều mà chúng tôi có triển khai hiện tại và nó có thể duy trì theo cách đó vô thời hạn. Nhưng chúng tôi không đưa ra bất kỳ cam kết chính thức nào về điều đó, vì vậy hãy tự chịu rủi ro.

Và cuối cùng nhưng không kém phần quan trọng, một bài đăng khác làm rõ (hoặc không) định dạng:

Chúng tôi không đảm bảo công khai về định dạng cho id video. Mặc dù chúng hiện có 11 chuỗi ký tự có chứa các chữ cái, số và một số dấu chấm câu, tôi không khuyên bạn nên mã hóa mã đó vào ứng dụng của mình (trừ khi bạn có cách dễ dàng thay đổi nó trong tương lai).

Nhóm Youtube dường như muốn trực tiếp hỏi máy chủ Youtube xem Video_ID có chính xác hay không (tham khảo một video hiện có):

Nếu bạn cần xác thực rằng đầu vào người dùng ngẫu nhiên tương ứng với id video hợp lệ, tôi khuyên bạn nên thực hiện kiểm tra theo kinh nghiệm. Cố gắng truy cập

http://gdata.youtube.com/feed/api/ideo/VIDEO_ID

Nếu bạn nhận được 200 phản hồi, thì VIDEO_ID là hợp lệ. Nếu bạn nhận được phản hồi không phải 200, bạn có id không hợp lệ. Có một số trường hợp cạnh cho video mới tải lên hoặc video riêng tư, nhưng đối với hầu hết các mục đích, tôi cho rằng điều đó sẽ ổn.

Số nhận dạng videoId và channelId của YouTube là các giá trị số nguyên duy nhất được biểu thị trong phiên bản mã hóa Base64 được sửa đổi một chút . Một điểm khác biệt so với khuyến nghị của IETF RFC4648 là việc thay thế hai ký tự trong bảng chữ cái mã hóa:

 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)

Sự thay thế có thể là do thực tế là, vì một số lý do, RFC4648 đã chọn hai ký tự đã có chức năng nổi bật và được thiết lập tốt trong các URL. ^{[lưu ý 1.]} Rõ ràng, đối với việc sử dụng được thảo luận ở đây, sự phức tạp cụ thể đó là tốt nhất nên tránh.

Một điểm khác biệt so với thông số kỹ thuật chính thức là số nhận dạng YouTube không sử dụng =ký tự đệm; không cần thiết vì độ dài được mã hóa dự kiến ​​cho mỗi kích thước số nguyên được giải mã tương ứng là cố định và đã biết (lần lượt là 11 và 22 chữ số được mã hóa cho 64 và 128 bit).

Với một ngoại lệ nhỏ (được thảo luận bên dưới), các chi tiết đầy đủ của ánh xạ Base64 có thể được suy ra từ dữ liệu có thể truy cập công khai. Với tối thiểu phỏng đoán, có khả năng lược đồ Base64 được sử dụng trong chuỗi videoId và channelId như sau:

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

Lý do để tin rằng Base64 đang được sử dụng là, khi chúng ta giả định kích thước nguyên tiêu chuẩn của 64 và 128 bit cho đầu vào bộ mã hóa, Base64 dự đoán độ dài bất thường ký tự (11 và 22 ký tự) của YouTube Danh Kênh và videoid định danh chính xác. Hơn nữa, phần dư được tính theo Base64 giải thích hoàn hảo biến thể phân phối quan sát được tìm thấy trong l̲a̲s̲t̲ c̲h̲a̲r̲a̲c̲t̲e̲r̲ của từng loại chuỗi định danh. Thảo luận về những điểm sau đây.

Trong cả hai trường hợp, "dữ liệu" nhị phân được mã hóa Base64 là một số nguyên duy nhất, 64 hoặc 128 bit, cho (tương ứng) videoId so với channelId . Theo đó, bằng cách sử dụng bộ giải mã Base64, một số nguyên duy nhất có thể được phục hồi từ mã định danh chuỗi và nó có thể khá hữu ích để làm điều này bởi vì, trong khi mỗi id số nguyên chứa chính xác thông tin như chuỗi Base64 và cũng cho phép chuỗi được tạo lại bất cứ lúc nào, khi so sánh với các chuỗi Base64 được lưu dưới dạng Unicode, biểu diễn nhị phân nhỏ hơn 63%, mật độ bit tối đa 100%, sắp xếp trong bộ nhớ tốt hơn, sắp xếp và băm nhanh hơn và có lẽ quan trọng nhất là loại bỏ va chạm sai giữa các định danh chỉ khác nhau trong trường hợp chỉnh hình. Vấn đề cuối cùng này, tuy vô cùng khó khăn về mặt số lượng, tuy nhiên không thể loại trừ khi ID Base64 được coi là không phân biệt chữ hoa chữ thường, như một số hệ thống tệp thực hiện (ví dụ: Windows , có từ thời DOS ).

Đó là khá quan trọng: nếu bạn đang sử dụng một videoid / Danh Kênh chuỗi như một phần của tên tập tin Windows / NTFS, có một vanishingly miniscule- tuy nhiên không zero- -chance va chạm filename do những hệ thống tập tin triển khai case-insensitive đường dẫn và cách đặt tên tệp .

Nếu bạn lo lắng về vấn đề có thể xảy ra từ xa này, một cách để loại bỏ một cách toán học đó là mã hóa lại các số nguyên được giải mã - vẫn thu được như mô tả trong bài viết này - thành cơ sở 10 (thập phân) hoặc (thống nhất- cased) biểu diễn thập lục phân, để sử dụng trong tên đường dẫn hoặc tên tệp trên các hệ thống tệp đó. ^{[lưu ý 2.]} Trong phương pháp này, videoId 64 bit sẽ cần 20 chữ số thập phân [0-9]hoặc 8 chữ số hex [0-9,A-F]( so với 11 chữ số Base64). ChannelId 128 bit sẽ yêu cầu tối đa 39 chữ số thập phân hoặc 16 chữ số hex ( so với 22 chữ số Base64).

Giải mã thành nhị phân là không đáng kể đối với trường hợp 64 bit vì bạn có thể sử dụng một UInt64( ulongtrong C # ) để giữ giá trị nhị phân gốc quay trở lại.

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

Đối với trường hợp của các giá trị 128 bit , nó hơi phức tạp hơn bởi vì, trừ khi trình biên dịch của bạn có một __int128đại diện, bạn sẽ phải tìm ra cách lưu trữ toàn bộ và giữ cho nó được kết hợp khi bạn vượt qua nó. Một loại giá trị đơn giản (hoặc System.Numerics.Vectors.Vector<T>, biểu hiện dưới dạng thanh ghi phần cứng SIMD 128 bit, khi khả dụng) sẽ thực hiện thủ thuật trong .NET (không hiển thị).

[ sửa: ]
Sau khi suy nghĩ thêm, một phần bài viết gốc của tôi đã không hoàn thành tối đa. Để công bằng, đoạn trích gốc được giữ lại (bạn có thể bỏ qua nếu muốn); ngay bên dưới tôi giải thích cái nhìn sâu sắc còn thiếu:

[ gốc: ]
Bạn có thể nhận thấy ở trên rằng tôi đã viết rằng bạn có thể khôi phục số nguyên " một ". Đây sẽ không phải là giá trị được mã hóa ban đầu? Không cần thiết. Và tôi không ám chỉ đến sự phân biệt đã ký / chưa ký, điều đó đúng, không thể được xác định ở đây (vì nó không thay đổi bất kỳ sự thật nào về hình ảnh nhị phân). Đó là giá trị số: Không có " Rosetta Stone"điều đó sẽ cho phép chúng tôi kiểm tra chéo với các giá trị tuyệt đối được gọi là" chính xác ", ánh xạ bảng chữ cái số và cả phần cuối không thể được biết một cách tích cực, điều đó có nghĩa là không có gì đảm bảo rằng bạn đang phục hồi cùng một giá trị Các máy tính tại YouTube được mã hóa. May mắn thay, miễn là YouTube không bao giờ công khai các giá trị được gọi là chính xác ở định dạng ít mờ hơn ở một nơi khác, điều này không thể quan trọng.

Đó là bởi vì các giá trị 64 hoặc 128 bit được giải mã không được sử dụng ngoại trừ mã thông báo nhận dạng, do đó, yêu cầu duy nhất của chúng tôi đối với chuyển đổi là mã hóa riêng biệt (không có hai mã thông báo duy nhất va chạm) và khả năng đảo ngược (giải mã phục hồi nhận dạng mã thông báo gốc).

Nói cách khác, tất cả những gì chúng tôi thực sự quan tâm là việc ngắt vòng không mất chuỗi của chuỗi Base64 gốc. Kể từ Base64 là lossless và đảo ngược (miễn là bạn luôn dính vào ánh xạ bảng chữ cái giống nhau và endianness giả định cho cả hai mã hóa và giải mã) nó thỏa mãn mục đích của chúng tôi. Các giá trị số của bạn có thể không khớp với các giá trị được ghi trong kho chính của YouTube, nhưng bạn sẽ không thể nhận thấy bất kỳ sự khác biệt nào.

---

[ Phân tích mới: ]
Nó chỉ ra rằng có là một vài manh mối có thể cho chúng tôi biết về "true" Base64 lập bản đồ. Chỉ một số ánh xạ nhất định dự đoán các ký tự vị trí cuối cùng mà chúng ta quan sát, có nghĩa là giá trị nhị phân chỉ cho các ký tự đó phải có một số 0 LSB nhất định. Heh.

Được kết hợp với giả định rất có khả năng rằng các ký tự chữ cái và chữ số được ánh xạ theo thứ tự tăng dần, về cơ bản chúng ta có thể xác nhận ánh xạ là những gì được hiển thị trong các bảng trên. Sự không chắc chắn duy nhất còn lại về phân tích LSB là không thuyết phục là sự hoán đổi có thể có của các ký tự -và _( 62/ 63).

Văn bản gốc đã thảo luận về vấn đề LSB này (xem thêm bên dưới), nhưng điều tôi chưa hoàn toàn nhận ra lúc đó là cách thông tin LSB hành động để hạn chế ánh xạ Base64 có thể .

Một nhận xét cuối cùng về vấn đề này là trên thực tế bạn có thể muốn cố ý chọn big endian cho giải thích nhị phân mà ứng dụng của bạn hoạt động với bên trong (mặc dù hiện tại nó ít phổ biến hơn so với endian nhỏ và do đó có thể không phải là cách YouTube 'chính thức' nó). Lý do là đây là trường hợp của các khung nhìn kép trên cùng một giá trị, sao cho thứ tự byte thực tế được hiển thị rõ ràng trong biểu hiện Base64. Thật hữu ích và ít gây nhầm lẫn để giữ thứ tự sắp xếp nhất quán giữa giá trị nhị phân và chuỗi Base64 có thể đọc được của con người, nhưng loại giá trị nhị phân nhỏ cuối cùng là một sự xáo trộn không tầm thường của loại ASCII / từ vựng mong muốn .

Không có cách khắc phục đơn giản nào cho vấn đề này nếu bạn bắt đầu với các giá trị ID cuối nhỏ (nghĩa là chỉ cần đảo ngược sắp xếp chúng sẽ không hoạt động). Thay vào đó, bạn phải lập kế hoạch trước và đảo ngược các byte của từng giá trị nhị phân tại thời điểm giải mã . Vì vậy, nếu bạn quan tâm đến việc hiển thị bảng chữ cái phù hợp với việc sắp xếp các giá trị nhị phân, bạn có thể muốn thay đổi hàm được hiển thị ở trên để thay vào đó nó giải mã thành các ulong giá trị lớn . Đây là mã:

// 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 YouTube

Id video

Đối với videoId , nó là số nguyên 8 byte (64 bit). Áp dụng mã hóa Base64 cho 8 byte dữ liệu cần 11 ký tự . Tuy nhiên, vì mỗi ký tự Base64 truyền tải chính xác 6 bit (viz., 2⁶ bằng 64), việc phân bổ này thực sự có thể chứa tới 11 × 6 = 66bit bit một lượng dư thừa 2 bit so với 64 bit mà nhu cầu tải trọng của chúng tôi. Các bit thừa được đặt thành 0, có tác dụng loại trừ các ký tự nhất định không xuất hiện ở vị trí cuối cùng của chuỗi được mã hóa. Đặc biệt, videoId được đảm bảo luôn kết thúc bằng một trong các ký tự sau:

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

Do đó, biểu thức chính quy bị ràng buộc tối đa (RegEx) cho videoId sẽ như sau:

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

Id kênh hoặc danh sách phát

Các Danh Kênh và playlistId dây được sản xuất bởi Base64 mã hóa 128-bit (16-byte) số nguyên nhị phân. Điều này cung cấp một chuỗi gồm 22 ký tự có thể được thêm tiền tố UCđể xác định chính kênh đó hoặc UUđể xác định danh sách phát đầy đủ các video mà nó chứa. Các chuỗi có tiền tố 24 ký tự này được sử dụng trong các URL . Ví dụ: các cách sau đây cho thấy hai cách để tham chiếu đến cùng một kênh. Lưu ý rằng phiên bản danh sách phát hiển thị tổng số video trong kênh, ^{[xem ghi chú 3.]} một thông tin hữu ích mà các trang kênh không lộ ra.

URL kênh

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

URL danh sách phát

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

Như trường hợp với videoId 11 ký tự , phép tính trên Base64 dự đoán chính xác độ dài chuỗi quan sát là 22 ký tự . Trong trường hợp này, đầu ra có khả năng mã hóa 22 × 6 = 132bit, thặng dư 4 bit; những con số không cuối cùng đã hạn chế m̲o̲s̲t̲ trong số 64 ký hiệu bảng chữ cái xuất hiện ở vị trí cuối cùng, chỉ còn 4 đủ điều kiện. Do đó, chúng tôi biết rằng ký tự cuối cùng trong chuỗi kênh YouTubeId phải là một trong những điều sau đây:

{ A, Q, g, w }

Điều này mang lại cho chúng ta biểu thức chính quy bị hạn chế tối đa cho một channelId :

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

Lưu ý cuối cùng, các biểu thức chính quy được hiển thị ở trên chỉ mô tả các giá trị ID trần, không có tiền tố, dấu gạch chéo, dấu phân cách, v.v., phải có trong URL và các cách sử dụng khác nhau. Các mẫu RegEx mà tôi đã trình bày ở mức tối thiểu về mặt toán học có thể được cung cấp các thuộc tính của các chuỗi định danh, nhưng nếu được sử dụng như không có ngữ cảnh bổ sung, chúng có thể sẽ tạo ra rất nhiều lỗi sai, đó là: khớp văn bản giả không chính xác. Để tránh vấn đề này trong sử dụng thực tế, hãy bao quanh chúng với càng nhiều bối cảnh liền kề dự kiến ​​càng tốt.

Ghi chú

[1.]
Như đã hứa ở trên, đây là một đoạn trích từ đặc tả Base64 thảo luận về những cân nhắc của họ trong việc lựa chọn các ký hiệu bảng chữ cái. Các cá nhân đang tìm cách hiểu làm thế nào quá trình kết thúc trong việc lựa chọn các ký tự với ngữ nghĩa URL có thể tìm thấy các giải thích có phần không hợp lý.

3.4. Chọn bảng chữ cái

Các ứng dụng khác nhau có các yêu cầu khác nhau về các ký tự trong bảng chữ cái. Dưới đây là một vài yêu cầu xác định bảng chữ cái nào sẽ được sử dụng:

• Được xử lý bởi con người. Các ký tự "0" và "O" dễ bị nhầm lẫn, như "1", "l" và "I". Trong bảng chữ cái base32 bên dưới, trong đó không có 0 (không) và 1 (một), bộ giải mã có thể hiểu 0 là O và 1 là I hoặc L tùy theo trường hợp. (Tuy nhiên, theo mặc định thì không nên; xem phần trước.)

• Được mã hóa thành các cấu trúc bắt buộc các yêu cầu khác. Đối với cơ sở 16 và cơ sở 32, điều này xác định việc sử dụng bảng chữ cái viết hoa hoặc viết thường. Đối với cơ sở 64, các ký tự không phải là chữ và số (cụ thể là "/") có thể có vấn đề trong tên tệp và URL.

• Được sử dụng như định danh. Một số ký tự nhất định, đáng chú ý là "+" và "/" trong bảng chữ cái 64 cơ sở, được coi là ngắt từ bằng các công cụ tìm kiếm / chỉ mục văn bản cũ.

Không có bảng chữ cái được chấp nhận phổ biến đáp ứng tất cả các yêu cầu. Để biết ví dụ về một biến thể chuyên dụng cao, xem IMAP [8]. Trong tài liệu này, chúng tôi ghi lại và đặt tên cho một số bảng chữ cái hiện đang được sử dụng.

[2.]
Ngoài ra, để giải quyết vấn đề sử dụng chuỗi ID được mã hóa Base64 dưới dạng các thành phần "as-is" của tên tệp hoặc đường dẫn trên hệ thống tệp NTFS, mặc định không phân biệt chữ hoa chữ thường giá trị ID không liên quan), do đó, NTFS có thể được cấu hình với cách đặt tên đường dẫn / tệp phân biệt chữ hoa chữ thường trên cơ sở mỗi khối. Kích hoạt hành vi không mặc định có thể khắc phục sự cố được mô tả ở đây, nhưng hiếm khi được đề xuất vì nó thay đổi kỳ vọng cho bất kỳ / tất cả các ứng dụng khác nhau kiểm tra hoặc truy cập vào ổ đĩa. Nếu bạn thậm chí đang xem xét tùy chọn này, hãy đọc và hiểu điều này trước, và có lẽ bạn sẽ thay đổi suy nghĩ của mình.

[3.]
Tôi tin rằng tổng số video được hiển thị trên trang danh sách phát kênh sẽ tính đến việc loại trừ các video bị hạn chế theo khu vực địa lý của máy khách HTTP. Tài khoản này cho bất kỳ sự khác biệt nào giữa số lượng video được liệt kê cho danh sách phát so với kênh.