รูปแบบสำหรับ ID ของวิดีโอ YouTube

วิดีโอ YouTube ทุกรายการมีรหัสเฉพาะซึ่งสามารถใช้เพื่อรับได้ ตัวอย่างเช่นวิดีโอที่มีประชาชนได้http://www.youtube.com/watch?v=aN46pEO_jX8aN46pEO_jX8

หลังจากการสังเกตุบางอย่างฉันคิดว่า ID เหล่านี้ปฏิบัติตามกฎสองข้อต่อไปนี้

• ตรง 11 ตัวอักษร
• สัญลักษณ์ที่อนุญาต: az, AZ, 0-9, -, และ _

ฉันอยากจะรู้:

1. ไม่ว่ากฎทั้งสองนี้จะถูกต้องหรือไม่
2. หากมีกฎอื่นใดที่สำคัญที่ต้องปฏิบัติตาม

ตามเอกสารของ Youtube 2.0 APIและเอกสารประกอบ API 3.0 , videoIdเป็นสตริงไม่มีการระบุอะไรเกี่ยวกับชุดอักขระปัจจุบันที่ใช้ ...

เกี่ยวกับความยาว 11 ตัวอักษรโพสต์จากทีม Youtube APIพูดว่า:

ฉันไม่เห็นเอกสารใด ๆ ในเอกสารที่เราให้ความยาวมาตรฐาน 11 ตัวอักษรสำหรับรหัสวิดีโอ YouTube มันเป็นหนึ่งในสิ่งที่เรามีการนำไปใช้ในปัจจุบันและมันอาจจะยังคงอยู่อย่างนั้นไปเรื่อย ๆ แต่เราไม่ได้ให้คำมั่นสัญญาอย่างเป็นทางการกับคุณดังนั้นดำเนินการด้วยความเสี่ยงของคุณเอง

และสุดท้าย แต่ไม่ท้ายสุดโพสต์อื่นจะทำให้ชัดเจน (หรือไม่) รูปแบบ:

เราไม่รับประกันสาธารณะใด ๆ เกี่ยวกับรูปแบบสำหรับรหัสวิดีโอ ในขณะที่พวกเขากำลัง 11 สายอักขระที่ประกอบด้วยตัวอักษรตัวเลขและเครื่องหมายวรรคตอนบางอย่างฉันจะไม่แนะนำการเข้ารหัสที่ลงในใบสมัครของคุณ (เว้นแต่คุณจะมีวิธีที่ง่ายในการเปลี่ยนในอนาคต)

ทีม Youtube ดูเหมือนจะถามเซิร์ฟเวอร์ Youtube โดยตรงว่า Video_ID นั้นถูกต้องหรือไม่ (ดูวิดีโอที่มีอยู่):

หากคุณต้องการตรวจสอบว่าการป้อนข้อมูลผู้ใช้แบบสุ่มนั้นสอดคล้องกับรหัสวิดีโอที่ถูกต้องฉันขอแนะนำให้ทำการทดสอบเชิงประจักษ์ พยายามเข้าถึง

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

หากคุณได้รับการตอบกลับ 200 ครั้งแสดงว่า VIDEO_ID ถูกต้อง หากคุณได้รับการตอบกลับที่ไม่ใช่ 200 คุณมีรหัสที่ไม่ถูกต้อง มีกรณีขอบสำหรับวิดีโอที่อัปโหลดใหม่หรือวิดีโอส่วนตัว แต่สำหรับวัตถุประสงค์ส่วนใหญ่ฉันคิดว่ามันจะไม่เป็นไร

YouTube videoidและchannelIdตัวระบุเป็นค่าจำนวนเต็มเดียวเป็นตัวแทนในรุ่นแก้ไขเล็กน้อยของการเข้ารหัส Base64 ข้อแตกต่างอย่างหนึ่งกับข้อเสนอแนะของIETF RFC4648คือการแทนที่อักขระสองตัวในการเข้ารหัสตัวอักษร:

 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)

การทดแทนนั้นมีสาเหตุมาจากความจริงที่ว่าด้วยเหตุผลบางประการRFC4648เลือกอักขระสองตัวที่มีฟังก์ชั่นเด่นและเป็นที่ยอมรับใน URL อยู่แล้ว ^{[หมายเหตุ 1. ]}เห็นได้ชัดว่าสำหรับการใช้งานภายใต้การสนทนาที่นี่หลีกเลี่ยงภาวะแทรกซ้อนที่ดีที่สุด

ข้อแตกต่างจากสเปคอย่างเป็นทางการก็คือตัวระบุของYouTubeจะไม่ใช้=อักขระตัวรอง ไม่จำเป็นเนื่องจากความยาวที่เข้ารหัสตามที่คาดไว้ตามขนาดจำนวนเต็มที่ถอดรหัสได้รับการแก้ไขและเป็นที่รู้จัก (11 หลักและ 22 บิตสำหรับ 64 และ 128 บิตตามลำดับ)

ด้วยข้อยกเว้นเล็กน้อยหนึ่งข้อ (อธิบายไว้ด้านล่าง) รายละเอียดทั้งหมดของการทำแผนที่ Base64 สามารถสรุปได้จากข้อมูลที่สาธารณชนสามารถเข้าถึงได้ ด้วยการคาดเดาขั้นต่ำอาจเป็นไปได้ว่ารูปแบบBase64 ที่ใช้ในสตริงvideoIdและchannelIdมีดังนี้:

    ——₀————₁————₂————₃————₄————₅————₆————₇————₈————₉———₁₀———₁₁———₁₂———₁₃———₁₄———₁₅—
     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 นั้นคือเมื่อเราถือว่าขนาดจำนวนเต็มมาตรฐานของ 64 และ 128 บิตสำหรับอินพุตตัวเข้ารหัส Base64 คาดการณ์ความยาวอักขระผิดปกติ (11 และ 22 ตัวอักษร) ของตัวระบุchannelIdและvideoIdของ YouTube อย่างแน่นอน นอกจากนี้เหลือคำนวณตาม Base64 ที่ดีที่สุดที่จะอธิบายรูปแบบการกระจายสังเกตพบในตัวอักษรตัวสุดท้ายของแต่ละประเภทสตริงระบุ การอภิปรายประเด็นเหล่านี้มีดังนี้

ในทั้งสองกรณีไบนารี "ข้อมูล" ที่ได้รับการเข้ารหัส Base64 เป็นจำนวนเต็มเดียวทั้ง 64 หรือ 128 บิตสำหรับ (ตามลำดับ) videoidกับchannelId ดังนั้นโดยใช้ตัวถอดรหัส Base64 ทำให้สามารถกู้คืนจำนวนเต็มเดียวจากตัวระบุสตริงได้และมันค่อนข้างมีประโยชน์ในการทำเช่นนี้เพราะในขณะที่แต่ละเลขจำนวนเต็มมีข้อมูลเดียวกันกับสตริง Base64 และยังอนุญาตให้สตริง ถูกสร้างขึ้นใหม่ได้ตลอดเวลา - เมื่อเปรียบเทียบกับสตริง Base64 ที่จัดเก็บเป็น Unicode การแทนแบบไบนารี่จะเล็กลง 63% มีความหนาแน่นบิตสูงสุดที่ 100% เรียงหน่วยความจำได้ดีขึ้นเรียงลำดับและแฮชได้เร็วขึ้นและที่สำคัญที่สุด การชนที่ผิดพลาดระหว่างตัวระบุที่แตกต่างกันเฉพาะในกรณีที่เกี่ยวกับการสะกดคำ. ปัญหานี้ที่ผ่านมาตัวเลข แต่ไม่น่าจะเป็นอย่างมาก แต่ไม่สามารถตัดออกเมื่อรหัส Base64 จะถือว่าเป็นกรณีตายในขณะที่บางคนทำระบบไฟล์ (เช่นของ Windowsย้อนหลังไปถึงDOS )

นั่นเป็นสิ่งสำคัญ: หากคุณใช้สตริงvideoId / channelIdเป็นส่วนหนึ่งของชื่อไฟล์ Windows / NTFS จะมีการย่อส่วนเล็ก ๆ น้อย ๆ - แต่อย่างไรก็ตามไม่ใช่ศูนย์ -อาจเกิดจากการชนกันของชื่อไฟล์เนื่องจากระบบไฟล์เหล่านั้น .

หากคุณกังวลเกี่ยวกับปัญหาที่อาจเกิดขึ้นจากระยะไกลวิธีหนึ่งในการกำจัดทางคณิตศาสตร์คือการเข้ารหัสตัวเลขจำนวนเต็มที่ถอดรหัสใหม่ซึ่งยังคงได้รับตามที่อธิบายไว้ในบทความนี้ในฐานสิบ (ทศนิยม) หรือเครื่องแบบ cased) การแสดงเลขฐานสิบหกเพื่อใช้ในพา ธ หรือชื่อไฟล์ในระบบไฟล์ดังกล่าว ^{[หมายเหตุ 2]}ในวิธีการนี้videoId 64 บิตจะต้องมีทศนิยม 20 หลัก[0-9]หรือ 8 ฐานสิบหก[0-9,A-F]( เทียบกับ 11 Base64 หลัก) channelIdแบบ 128 บิตจะต้องมีจำนวนทศนิยมสูงสุด 39 หลักหรือ 16 ฐานสิบหก ( เทียบกับ 22 Base64 หลัก)

การถอดรหัสไบนารี่เป็นเรื่องเล็กน้อยสำหรับเคส64- บิตเนื่องจากคุณสามารถใช้UInt64( ulongในC # ) เพื่อเก็บค่าไบนารี่ดั้งเดิมที่กลับมา

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

สำหรับกรณีของค่า128- บิตนั้นค่อนข้างซับซ้อนกว่าเพราะหากคอมไพเลอร์ของคุณมีการเป็น__int128ตัวแทนคุณจะต้องหาวิธีในการเก็บสิ่งของทั้งหมดและเก็บมันรวมกันเมื่อคุณส่งมันไป ประเภทค่าแบบง่าย (หรือSystem.Numerics.Vectors.Vector<T>ซึ่งแสดงว่าการลงทะเบียนฮาร์ดแวร์ SIMD แบบ 128 บิตหากมี) จะใช้กลอุบายใน. NET (ไม่แสดง)

[ แก้ไข: ]
หลังจากคิดเพิ่มเติมส่วนหนึ่งของโพสต์ต้นฉบับของฉันไม่สมบูรณ์ที่สุด เพื่อความเป็นธรรมข้อความที่ตัดตอนมาดั้งเดิมจะถูกเก็บไว้ (คุณสามารถข้ามไปได้หากต้องการ) ด้านล่างนี้ฉันอธิบายความเข้าใจที่ขาดหายไปทันที:

[ เดิม: ]
คุณอาจสังเกตเห็นข้างต้นที่ผมเขียนว่าคุณสามารถกู้คืน " " จำนวนเต็ม นี่จะเป็นค่าที่เข้ารหัสมาหรือไม่ ไม่จำเป็น. และฉันก็ไม่ได้พูดถึงความแตกต่างที่มีการลงนาม / ไม่ได้ลงนามซึ่งเป็นเรื่องจริงไม่สามารถยืนยันได้ที่นี่ (เพราะมันไม่เปลี่ยนข้อเท็จจริงใด ๆ เกี่ยวกับภาพไบนารี) มันเป็นค่าตัวเลขเอง: หากไม่มี " Rosetta Stone ""ที่จะให้เราตรวจสอบอย่างถูกต้องด้วยค่าสัมบูรณ์ที่รู้กันว่า" ถูกต้อง "การทำแผนที่ตัวอักษรตัวเลขและ endian-ness ไม่สามารถรู้ได้ในเชิงบวกซึ่งหมายความว่าไม่มีการรับประกันว่าคุณจะกู้คืนค่าเดิมที่ คอมพิวเตอร์ที่เข้ารหัสใน YouTube โชคดีที่ตราบใดที่ YouTube ไม่เปิดเผยค่าที่ถูกต้องในรูปแบบทึบแสงน้อยกว่าที่อื่น

นั่นเป็นเพราะถอดรหัส 64 หรือ 128 บิตค่าได้ใช้ยกเว้นเป็นอยู่ดีโทเค็นระบุไม่ดังนั้นความต้องการเฉพาะของเราสำหรับการแปลงมีการเข้ารหัสที่แตกต่างกัน (ไม่มีสองราชสกุลที่ไม่ซ้ำกันชน) และreversibility (ถอดรหัสกู้ตัวตนโทเค็นเดิม)

สิ่งที่เราสนใจจริงๆก็คือการสูญเสียการปัดเศษของเบส Base64 ดั้งเดิม เนื่องจาก Base64 นั้นไม่มีการสูญเสียและย้อนกลับได้ (ตราบใดที่คุณยังคงยึดมั่นกับการทำแผนที่ตัวอักษรและสมมติฐานendiannessสำหรับการเข้ารหัสและการถอดรหัส) มันเป็นไปตามวัตถุประสงค์ของเรา ค่าตัวเลขของคุณอาจไม่ตรงกับค่าที่บันทึกในห้องนิรภัยหลักของ YouTube แต่คุณจะไม่สามารถบอกความแตกต่างได้

---

[ วิเคราะห์ใหม่: ]
มันปรากฎว่ามีเป็นปมไม่กี่คนที่สามารถบอกเราเกี่ยวกับ "ความจริง" Base64การทำแผนที่ มีเพียงการแมปบางอย่างเท่านั้นที่คาดการณ์อักขระตำแหน่งสุดท้ายที่เราสังเกตซึ่งหมายถึงค่าไบนารีสำหรับตัวละครเหล่านั้นเท่านั้นที่จะต้องมีจำนวน LSB เป็นศูนย์ หึ

เมื่อนำมารวมกับข้อสันนิษฐานที่น่าสงสัยอย่างมากว่าตัวอักษรและตัวอักษรหลักถูกแมปตามลำดับจากน้อยไปมากโดยทั่วไปเราสามารถยืนยันการแมปเป็นสิ่งที่แสดงในตารางด้านบน ความไม่แน่นอนที่เหลืออยู่เพียงอย่างเดียวเกี่ยวกับการวิเคราะห์ LSB ที่ไม่สามารถสรุปได้คือการสลับที่เป็นไปได้ของอักขระ-และ_( 62/ 63)

ข้อความเดิมได้ปรึกษาเรื่องนี้ LSB ปัญหา (ดูเพิ่มเติมด้านล่าง) แต่สิ่งที่ฉันไม่ได้ตระหนักถึงในขณะที่เป็นวิธี LSB ข้อมูลทำหน้าที่ในการ จำกัด ที่เป็นไปได้Base64แมป

ความคิดเห็นล่าสุดเกี่ยวกับเรื่องนี้คือในความเป็นจริงแล้วคุณอาจต้องการที่จะเลือกนักแปลระดับ ใหญ่สำหรับการตีความเลขฐานสองที่แอปของคุณทำงานร่วมกับภายใน (แม้ว่ามันจะเป็นเรื่องธรรมดาน้อยกว่าผู้ที่มีความเอนเอียงน้อยในปัจจุบัน) มัน). เหตุผลก็คือว่านี่เป็นกรณีของมุมมองแบบคู่ในค่าเดียวกันเช่นลำดับไบต์ที่แท้จริงจะถูกเปิดเผยอย่างชัดเจนในการเรนเดอร์ Base64 มันมีประโยชน์และสับสนน้อยกว่าเพื่อให้การเรียงลำดับสอดคล้องกันระหว่างค่าไบนารีและสตริง Base64 (ค่อนข้างมากกว่า) ที่มนุษย์อ่านได้ แต่การเรียงลำดับของค่าเลขฐานสองเล็ก ๆ น้อย ๆ นั้นเป็นการแย่งกันแบบ ASCII / ศัพท์ที่ไม่สำคัญ .

ไม่มีการแก้ไขที่ง่ายสำหรับปัญหานี้หากคุณเริ่มต้นด้วยค่า ID แบบ end-endian เล็ก ๆ น้อย ๆ (เช่นการย้อนกลับการเรียงลำดับจะไม่ทำงาน) แต่คุณต้องวางแผนล่วงหน้าและย้อนกลับไบต์ของค่าไบนารีแต่ละช่วงเวลาของการถอดรหัส ดังนั้นหากคุณสนใจจอแสดงผลแบบตัวอักษรที่ตรงกับการเรียงลำดับของค่าไบนารีคุณอาจต้องการเปลี่ยนฟังก์ชั่นที่แสดงด้านบนเพื่อให้ถอดรหัสเป็นค่าใหญ่สุด ulongแทน นี่คือรหัส:

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

รหัสวิดีโอ

สำหรับvideoIdมันเป็นจำนวนเต็ม 8 ไบต์ (64- บิต) การประยุกต์ใช้ Base64 เข้ารหัสถึง 8 ไบต์ของข้อมูลต้องมี11 ตัวอักษร อย่างไรก็ตามเนื่องจากอักขระ Base64 แต่ละตัวสื่อถึง 6 บิต (กล่าวคือ, 2⁶เท่ากับ 64) การจัดสรรนี้สามารถเก็บได้ถึง11 × 6 = 66บิต - เกินดุล 2 บิตจาก 64 บิตตามที่เราต้องการ บิตส่วนเกินถูกตั้งค่าเป็นศูนย์ซึ่งมีผลของการยกเว้นอักขระบางตัวจากที่เคยปรากฏในตำแหน่งสุดท้ายของสตริงที่เข้ารหัส โดยเฉพาะอย่างยิ่งvideoIdรับประกันว่าจะลงท้ายด้วยหนึ่งในตัวละครต่อไปนี้:

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

ดังนั้นการแสดงออกปกติข้อ จำกัด สูงสุด (RegEx) สำหรับvideoIdจะเป็นดังนี้:

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

รหัสช่องหรือเพลย์ลิสต์

channelIdและplaylistIdสตริงมีการผลิตโดย Base64 เข้ารหัส 128 บิต (16 ไบต์) จำนวนเต็มไบนารี นี่เป็นสตริง 22 อักขระซึ่งสามารถนำหน้าด้วยUCเพื่อระบุช่องของตัวเองหรือUUเพื่อระบุเพลย์ลิสต์แบบเต็มของวิดีโอที่มีอยู่ เหล่านี้ 24 ตัวอักษรนำหน้าสายที่ใช้ในURL ที่ ตัวอย่างเช่นต่อไปนี้แสดงสองวิธีในการอ้างถึงช่องทางเดียวกัน โปรดสังเกตว่าเวอร์ชันเพลย์ลิสต์แสดงจำนวนวิดีโอทั้งหมดในช่อง^{[ดูหมายเหตุ 3]}ข้อมูลที่มีประโยชน์ซึ่งหน้าช่องไม่แสดง

URL ช่องทาง

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

URL เพลย์ลิสต์

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

ในฐานะที่เป็นกรณีที่มี 11 ตัวอักษรvideoidคำนวณต่อ Base64 อย่างถูกต้องคาดการณ์ความยาวสตริงสังเกตของ22 ตัวอักษร ในกรณีนี้เอาต์พุตสามารถเข้ารหัส22 × 6 = 132บิตได้ส่วนเกิน 4 บิต ศูนย์เหล่านั้นจะสิ้นสุดการ จำกัด m̲o̲s̲t̲ ของสัญลักษณ์ตัวอักษร 64 ตัวจากการปรากฏในตำแหน่งสุดท้ายโดยเหลือเพียง 4 สิทธิ์เท่านั้น เราจึงรู้ว่าอักขระตัวสุดท้ายในสตริงช่องchannel ของ YouTube ต้องเป็นอย่างใดอย่างหนึ่งต่อไปนี้:

{ A, Q, g, w }

สิ่งนี้ทำให้เรามีการแสดงออกปกติข้อ จำกัด สูงสุดสำหรับchannelId :

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

ในฐานะโน้ตสุดท้ายนิพจน์ทั่วไปที่แสดงด้านบนจะอธิบายค่า ID เปล่าเท่านั้นโดยไม่มีส่วนนำหน้าสแลชตัวคั่น ฯลฯ ที่ต้องแสดงใน URL และการใช้งานอื่น ๆ รูปแบบ RegEx ที่ฉันนำเสนอมีค่าทางคณิตศาสตร์น้อยที่สุดเท่าที่จะเป็นไปได้เนื่องจากคุณสมบัติของสตริงตัวระบุ แต่ถ้าใช้ตามที่เป็นโดยไม่มีบริบทเพิ่มเติม เพื่อหลีกเลี่ยงปัญหานี้ในการใช้งานจริงล้อมรอบพวกเขาด้วยบริบทที่อยู่ติดกันมากที่สุดเท่าที่จะทำได้

หมายเหตุ

[1. ] ดัง
ที่ได้กล่าวไว้ข้างต้นนี่คือข้อความที่ตัดตอนมาจากข้อกำหนด Base64ซึ่งกล่าวถึงข้อควรพิจารณาในการเลือกสัญลักษณ์ตัวอักษร บุคคลที่พยายามเข้าใจว่ากระบวนการสรุปในการเลือกอักขระที่มีความหมาย URL อาจพบว่าคำอธิบายค่อนข้างไม่มีการแก้ไข

3.4 การเลือกตัวอักษร

แอปพลิเคชั่นที่แตกต่างกันมีข้อกำหนดที่แตกต่างกันสำหรับตัวอักษรในตัวอักษร ต่อไปนี้เป็นข้อกำหนดบางประการที่ระบุว่าควรใช้ตัวอักษรใด:

• จัดการโดยมนุษย์ อักขระ "0" และ "O" สับสนง่ายเช่นเดียวกับ "1", "l" และ "I" ในตัวอักษร base32 ด้านล่างซึ่งไม่มี 0 (ศูนย์) และ 1 (หนึ่ง) ตัวถอดรหัสอาจตีความ 0 เป็น O และ 1 เป็น I หรือ L ขึ้นอยู่กับกรณี (อย่างไรก็ตามโดยค่าเริ่มต้นแล้วไม่ควร; ดูหัวข้อก่อนหน้า)

• เข้ารหัสเป็นโครงสร้างที่ทำหน้าที่กำหนดข้อกำหนดอื่น ๆ สำหรับฐาน 16 และฐาน 32 นี่เป็นการกำหนดการใช้ตัวอักษรตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็ก สำหรับฐาน 64 อักขระที่ไม่ใช่ตัวอักษรและตัวเลข (โดยเฉพาะ "/") อาจมีปัญหาในชื่อไฟล์และ URL

• ใช้เป็นตัวระบุ อักขระบางตัวโดยเฉพาะอย่างยิ่ง "+" และ "/" ในตัวอักษรฐาน 64 ถือว่าเป็นตัวแบ่งคำโดยเครื่องมือค้นหา / ดัชนีข้อความดั้งเดิม

ไม่มีตัวอักษรที่เป็นที่ยอมรับในระดับสากลที่ตอบสนองความต้องการทั้งหมด สำหรับตัวอย่างของตัวแปรที่มีความเชี่ยวชาญสูงโปรดดู IMAP [8] ในเอกสารนี้เราจัดทำเอกสารและตั้งชื่อตัวอักษรที่ใช้งานอยู่ในปัจจุบัน

[2. ]
อีกทางหนึ่งเพื่อแก้ปัญหาการใช้สตริง ID ที่เข้ารหัส Base64 เป็นส่วนประกอบ "ตามที่เป็น" ของชื่อไฟล์หรือชื่อพา ธ ในระบบไฟล์ NTFS ซึ่งเป็นแบบตัวพิมพ์เล็กและตัวพิมพ์ใหญ่โดยค่าเริ่มต้น ค่า ID ที่ไม่เกี่ยวข้อง) มันจึงเกิดขึ้นที่ NTFS สามารถกำหนดค่าด้วยการกำหนดเส้นทาง / ชื่อไฟล์ตามตัวพิมพ์เล็กและตัวพิมพ์ใหญ่สำหรับแต่ละวอลุ่ม การเปิดใช้งานลักษณะการทำงานที่ไม่ใช่ค่าเริ่มต้นอาจแก้ไขปัญหาที่อธิบายไว้ที่นี่ แต่ไม่ค่อยได้รับการแนะนำเนื่องจากเป็นการเปลี่ยนแปลงความคาดหวังสำหรับแอปพลิเคชันที่แตกต่างกัน / ทั้งหมดที่ตรวจสอบหรือเข้าถึงไดรฟ์ หากคุณกำลังพิจารณาตัวเลือกนี้อยู่ให้อ่านและทำความเข้าใจสิ่งนี้ก่อนและคุณอาจเปลี่ยนใจ

[3. ]
ฉันเชื่อว่าจำนวนวิดีโอทั้งหมดที่แสดงหน้าเพลย์ลิสต์ของช่องนั้นคำนึงถึงการยกเว้นวิดีโอที่ถูก จำกัด ตามพื้นที่ทางภูมิศาสตร์ของไคลเอนต์ HTTP บัญชีนี้สำหรับความคลาดเคลื่อนระหว่างจำนวนวิดีโอที่ระบุไว้สำหรับเพลย์ลิสต์กับช่อง