YouTube वीडियो की आईडी के लिए प्रारूप

Youtube 2.0 API डॉक्यूमेंटेशन और 3.0 API डॉक्यूमेंटेशन के अनुसार , videoId एक स्ट्रिंग है, उपयोग किए गए वर्णों के वर्तमान सेट के बारे में कुछ भी निर्दिष्ट नहीं है ...

11 अक्षरों की लंबाई के बारे में, Youtube API टीम की एक पोस्ट कहती है:

मैं कहीं भी दस्तावेज में नहीं देखता जहाँ हम आधिकारिक तौर पर YouTube वीडियो आईडी के लिए 11 वर्णों की मानक लंबाई के लिए प्रतिबद्ध हैं। यह उन चीजों में से एक है जहां हमारे पास एक वर्तमान कार्यान्वयन है, और यह अनिश्चित काल तक उस तरह से रह सकता है। लेकिन हम उस पर कोई आधिकारिक प्रतिबद्धता नहीं दे रहे हैं, इसलिए अपने जोखिम पर आगे बढ़ें।

और अंतिम लेकिन कम से कम, एक और पोस्ट स्पष्ट (या नहीं) प्रारूप:

हम वीडियो आईडी के प्रारूप के बारे में कोई सार्वजनिक गारंटी नहीं देते हैं। हालांकि वे वर्तमान में 11 वर्णों के तार हैं जिनमें अक्षर, संख्या और कुछ विराम चिह्न शामिल हैं, मैं आपको अपने आवेदन में हार्डकोडिंग की सिफारिश नहीं करूंगा (जब तक कि आपके पास भविष्य में इसे बदलने का आसान तरीका न हो)।

लगता है कि YouTube टीम सीधे Youtube सर्वर से पूछना पसंद करती है, अगर Video_ID सही है या नहीं (मौजूदा वीडियो का संदर्भ लें):

यदि आपको यह प्रमाणित करने की आवश्यकता है कि यादृच्छिक उपयोगकर्ता इनपुट एक वैध वीडियो आईडी से मेल खाती है, तो मैं एक अनुभवजन्य परीक्षण करने की सलाह दूंगा। पहुँचने का प्रयास

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

यदि आपको 200 प्रतिसाद मिलता है, तो VIDEO_ID मान्य है। यदि आपको कोई गैर-200 प्रतिक्रिया मिलती है, तो आपके पास एक अमान्य आईडी है। नए अपलोड किए गए वीडियो या निजी वीडियो के लिए कुछ किनारे मामले हैं, लेकिन अधिकांश उद्देश्यों के लिए मैं मानूंगा कि यह ठीक होगा।

— सेड्रिक जूलियन
स्रोत

यह एक महान जवाब है, और मुझे मेरी ज़रूरत की सभी जानकारी दी है! धन्यवाद!

— asfallows

यह एक HTTP 410 अब चला गया है। इस बात की पुष्टि करने के लिए कि नया URL क्या होना चाहिए?

— विल स्ट्रोहल

वीडियो आईडी सत्यापित करने के लिए: बस youtube से html पेज प्राप्त करें और सत्यापित करें कि मेटा कैनोनिकल लिंक में वही आईडी है जिसे आपने निर्दिष्ट किया था।

— पचू

YouTube वीडियोआईड और चैनलआईड पहचानकर्ता एकल पूर्णांक मान हैं जो बेस 64 एनकोडिंग के थोड़े संशोधित संस्करण में दर्शाए गए हैं । 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 बिट्स के लिए)।

एक मामूली अपवाद (नीचे चर्चा की गई) के साथ, बेस 64 मैपिंग का पूरा विवरण सार्वजनिक रूप से सुलभ डेटा से अनुमान लगाया जा सकता है। अटकलबाजी की एक न्यूनतम के साथ, यह संभव है कि Base64 में प्रयोग किया जाता योजना VIDEOID और चैनल- तार इस प्रकार है:

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

बेस 64 का उपयोग करने का कारण यह माना जाता है कि जब हम एनकोडर इनपुट के लिए 64 और 128 बिट्स के मानक पूर्णांक आकार का अनुमान लगाते हैं, बेस 64 YouTube चैनल की असामान्य चरित्र लंबाई (11 और 22 अक्षर) की भविष्यवाणी करता है और वीडियो आईडेंटिफ़ायर पहचानता है। इसके अलावा, बेस 64 के अनुसार गणना की गई गणना प्रत्येक प्रकार के पहचानकर्ता स्ट्रिंग के l̲aderss̲t̲ c̲h̲a̲r̲a̲c̲t̲e̲r̲ में पाए गए वितरणीय भिन्नता को पूरी तरह से समझाती है । इन बिंदुओं की चर्चा इस प्रकार है।

दोनों ही मामलों में, बेस 64-एनकोडेड प्राप्त करने वाला बाइनरी "डेटा" एक एकल पूर्णांक है, या तो 64 या 128 बिट्स के लिए (क्रमशः) वीडियोआईड बनाम चैनलआईड । तदनुसार, बेस 64 डिकोडर का उपयोग करके, स्ट्रिंग पहचानकर्ता से एक पूर्णांक प्राप्त किया जा सकता है, और ऐसा करने के लिए यह काफी उपयोगी हो सकता है, जबकि प्रत्येक पूर्णांक आईडी में बेस 64 स्ट्रिंग जैसी ही जानकारी होती है - और स्ट्रिंग को भी अनुमति देता है किसी भी समय फिर से बनाया जा सकता है - जब यूनिकोड के रूप में संग्रहीत बेस 64 स्ट्रिंग्स की तुलना में, द्विआधारी प्रतिनिधित्व 63% छोटा है, 100% की अधिकतम बिट-घनत्व है, मेमोरी में संरेखित करता है, सॉर्ट करता है और तेजी से हैश करता है, और, शायद सबसे महत्वपूर्ण रूप से, समाप्त करता है पहचानकर्ताओं के बीच गलत टकराव जो केवल ऑर्थोग्राफिक मामले में भिन्न होते हैं। यह अंतिम समस्या है, हालांकि बेहद असंभव संख्यात्मक रूप से, हालांकि तब भी इनकार नहीं किया जा सकता है जब बेस 64 आईडी को केस-असंवेदनशील के रूप में माना जाता है, जैसा कि कुछ फाइलसिस्टम करते हैं (जैसे विंडोज , डॉस से वापस डेटिंग )।

यह महत्वपूर्ण है: यदि आप एक Windows / NTFS फ़ाइल नाम के एक भाग के रूप में एक VideoId / ChannelId स्ट्रिंग का उपयोग कर रहे हैं , तो एक लुप्तप्राय miniscule है- लेकिन फिर भी केस-असंवेदनशील पथ और फ़ाइल नामकरण की तैनाती करने वाले उन सिस्टम सिस्टमों के कारण गैर-शून्य- फ़ाइल नाम टक्कर नहीं है ।

यदि आप इस दूरस्थ संभावित समस्या से चिंतित हैं, तो गणितीय रूप से इसे समाप्त करने का एक तरीका डिकोड किए गए पूर्णांक को फिर से एनकोड करना होगा - फिर भी इस लेख में वर्णित के रूप में प्राप्त किया जाएगा - या तो बेस -10 (दशमलव) या (एकरूप) आवरण) हेक्साडेसिमल प्रतिनिधित्व, ऐसे फाइलसिस्टम पर पथ या फ़ाइल नामों में उपयोग के लिए। ^{[नोट 2.]} इस दृष्टिकोण में, 64-बिट वीडियोआईड को 20 दशमलव अंकों [0-9]या 8 हेक्स अंकों [0-9,A-F]( बनाम 11 बेस 64 अंकों) की आवश्यकता होगी। 128-बिट channelId को अधिकतम 39 दशमलव अंकों या 16 हेक्स अंकों ( बनाम 22 बेस 64 अंकों) की आवश्यकता होगी।

बाइनरी में डीकोड करने के लिए मामूली बात है 64-बिट मामले क्योंकि आप एक का उपयोग कर सकते UInt64( ulongमें सी # ) देशी बाइनरी मान कि वापस आता है धारण करने के लिए।

/// <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>, जो 128-बिट SIMD हार्डवेयर रजिस्टर के रूप में प्रकट होता है, जब उपलब्ध होता है) .NET में ट्रिक करेगा (दिखाया नहीं गया)।

[ संपादित करें ]
आगे के विचार के बाद, मेरे मूल पोस्ट का एक हिस्सा अधिकतम रूप से पूर्ण नहीं था। निष्पक्षता के लिए, मूल अंश को बरकरार रखा जाता है (यदि आप चाहें तो इसे छोड़ सकते हैं); नीचे मैं लापता अंतर्दृष्टि की व्याख्या:

[ मूल: ]
आपने ऊपर देखा होगा कि मैंने लिखा था कि आप एक "पूर्णांक " को पुनर्प्राप्त कर सकते हैं । यह मूल रूप से एन्कोड किया गया मान नहीं होगा? जरुरी नहीं। और मैं हस्ताक्षरित / अहस्ताक्षरित भेद के बारे में नहीं बता रहा हूं, जो सच है, यहां पता नहीं लगाया जा सकता है (क्योंकि यह द्विआधारी छवि के बारे में कोई तथ्य नहीं बदलता है)। यह स्वयं संख्यात्मक मान है: बिना कुछ " रोसेटा स्टोन ""जो हमें" सही "ज्ञात पूर्ण मानों के साथ क्रॉस-चेक करने देगा, संख्यात्मक वर्णमाला मैपिंग और एंडियन-नेस को भी सकारात्मक रूप से नहीं जाना जा सकता है, जिसका अर्थ है कि कोई गारंटी नहीं है कि आप उसी मान को पुनर्प्राप्त कर रहे हैं जो YouTube पर कंप्यूटर एन्कोडेड होते हैं। सौभाग्य से, जब तक YouTube कभी भी सार्वजनिक रूप से तथाकथित सही मानों को कम-अपारदर्शी प्रारूप में कहीं और उजागर नहीं करता है, यह संभवतः मायने नहीं रख सकता है।

ऐसा इसलिए है क्योंकि डिकोड किए गए 64- या 128-बिट मानों का वैसे भी एक पहचान चिह्न के रूप में उपयोग करने के अलावा कोई उपयोग नहीं है, इसलिए परिवर्तन के लिए हमारी केवल आवश्यकताएं अलग एन्कोडिंग हैं (कोई दो अद्वितीय टोकन टकराते नहीं हैं) और प्रतिवर्तीता (डिकोडिंग मूल टोकन पहचान को ठीक करता है)।

दूसरे शब्दों में, हम वास्तव में परवाह करते हैं कि मूल बेस 64 स्ट्रिंग का दोषरहित दौर-ट्रिपिंग है। चूंकि बेस 64 दोषरहित और प्रतिवर्ती है (जब तक आप हमेशा एक ही वर्णमाला मानचित्रण और एन्कोडिंग और डिकोडिंग दोनों के लिए एकरूपता की धारणा से चिपके रहते हैं ) यह हमारे उद्देश्यों को संतुष्ट करता है। आपके संख्यात्मक मान YouTube के मास्टर वॉल्ट में दर्ज किए गए लोगों के साथ मेल नहीं खा सकते हैं, लेकिन आप कोई अंतर नहीं बता पाएंगे।
[ नए विश्लेषण: ]
यह पता चला है कि कर रहे हैं में कुछ सुराग कि हमें "सही" के बारे में बता सकते हैं Base64 मानचित्रण। केवल कुछ मैपिंग ही अंतिम स्थिति वाले पात्रों की भविष्यवाणी करते हैं, जिनका हम निरीक्षण करते हैं, जिसका अर्थ है कि केवल उन पात्रों के लिए द्विआधारी मूल्य में निश्चित संख्या में एलएसबी शून्य होना चाहिए। हे।

एक साथ होने वाली संभावित धारणा के साथ लिया जाता है कि वर्णमाला और अंकों के पात्रों को आरोही क्रम में मैप किया जाता है, हम मूल रूप से मैपिंग की पुष्टि कर सकते हैं कि ऊपर की तालिकाओं में दिखाया गया है। केवल शेष अनिश्चितता, जिसके बारे में एलएसबी विश्लेषण अनिर्णायक है, पात्रों -और _( 62/ 63) की संभावित स्वैप है ।

मूल पाठ ने इस एलएसबी मुद्दे पर चर्चा की (नीचे देखें), लेकिन उस समय मुझे पूरी तरह से पता नहीं चला था कि एलएसबी की जानकारी कैसे संभव है कि बेस 64 मैपिंग को प्रतिबंधित किया जाए ।

इस पर एक अंतिम टिप्पणी यह है कि आप वास्तव में बाइनरी व्याख्या के लिए जानबूझकर बड़े-एंडियन को चुन सकते हैं , जो आपका ऐप आंतरिक रूप से काम करता है (भले ही यह आजकल छोटे एंडियन की तुलना में कम आम है और इस तरह YouTube 'आधिकारिक रूप से' नहीं हो सकता है) यह)। कारण यह है कि यह एक ही मूल्य पर दोहरे विचारों का मामला है, जैसे कि वास्तविक बाइट क्रम को बेसिन प्रतिपादन में स्पष्ट रूप से उजागर किया गया है। यह बाइनरी मान और (कुछ अधिक) मानव-पठनीय बेस 64 स्ट्रिंग के बीच क्रमबद्ध क्रम को बनाए रखने के लिए सहायक और कम भ्रामक है , लेकिन छोटे-एंडियन बाइनरी मानों का प्रकार वांछित एएससीआईआई / लेक्सिकल प्रकार का गैर-तुच्छ स्क्रैम्बल है। ।

इस समस्या के लिए कोई सरल निर्धारण नहीं है यदि आप छोटे-एंडियन आईडी मूल्यों के साथ शुरू करते हैं (यानी बस उनके प्रकार को उलटने से काम नहीं चलेगा)। इसके बजाय, आपको डिकोडिंग के समय प्रत्येक बाइनरी वैल्यू के बाइट्स को आगे और पीछे करना होगा । इसलिए यदि आप द्विआधारी मूल्यों की छँटाई से मिलते-जुलते वर्णमाला प्रदर्शन के बारे में परवाह करते हैं, तो आप ऊपर दिखाए गए फ़ंक्शन को बदलना चाहते हैं ताकि यह बड़े-एंडियन 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 ID

वीडियो आईडी

के लिए VIDEOID , यह एक 8-बाइट (64-बिट) पूर्णांक है। बेस 6-एन्कोडिंग को डेटा के 8 बाइट्स पर लागू करने के लिए 11 वर्णों की आवश्यकता होती है । हालाँकि, प्रत्येक बेस 64 वर्ण 6 बिट्स (अर्थात, 2als 64 के बराबर) का पता लगाता है, यह आवंटन वास्तव में 11 × 6 = 66बिट्स तक पकड़ सकता है - 64 बिट्स जो हमारे पेलोड की ज़रूरतों पर 2 बिट्स का अधिशेष है। अतिरिक्त बिट्स शून्य पर सेट हैं, जिसमें एन्कोडेड स्ट्रिंग की अंतिम स्थिति में कुछ वर्णों को कभी भी बाहर करने का प्रभाव होता है। विशेष रूप से, 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]

चैनल या प्लेलिस्ट आईडी

चैनल- और playlistId तार एक 128-बिट (16-बाइट) द्विआधारी पूर्णांक Base64-एन्कोडिंग द्वारा उत्पादित कर रहे हैं। यह एक 22-कैरेक्टर स्ट्रिंग देता है जिसे या तो UCचैनल की पहचान करने के लिए उपसर्ग किया जा सकता है, या UUइसमें शामिल वीडियो की पूरी प्लेलिस्ट की पहचान कर सकता है। इन 24-वर्णों के उपसर्गों का उपयोग URL में किया जाता है । उदाहरण के लिए, निम्न एक ही चैनल को संदर्भित करने के दो तरीके दिखाता है। ध्यान दें कि प्लेलिस्ट संस्करण चैनल में कुल वीडियो की संख्या दिखाता है, ^{[नोट 3 देखें]]} एक उपयोगी जानकारी है जिसे चैनल पृष्ठ उजागर करते हैं।

चैनल यूआरएल
https://www.youtube.com/channel/UC K8sQmJBp8GCxrOtXWBpyEA
प्लेलिस्ट URL
https://www.youtube.com/playlist?list=UU K8sQmJBp8GCxrOtXWBpyEA

जैसा कि 11-चरित्र वाले वीडियोआईड के साथ हुआ था , बेस 64 की गणना सही ढंग से 22-वर्णों की देखी गई स्ट्रिंग लंबाई की भविष्यवाणी करती है । इस मामले में, आउटपुट 22 × 6 = 132बिट्स को एन्कोडिंग करने में सक्षम है , 4 बिट्स का अधिशेष; वे शून्य अंत में 64 वर्णमाला प्रतीकों के m̲oers̲t the को अंतिम स्थिति में प्रदर्शित होने से रोकते हैं, केवल 4 शेष पात्र हैं। इसलिए हम जानते हैं कि YouTube चैनल में अंतिम वर्ण स्ट्रिंग में निम्नलिखित में से एक होना चाहिए:

{ A, Q, g, w }

यह हमें एक ChannelId के लिए अधिकतम-विवश नियमित अभिव्यक्ति देता है :

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

अंतिम नोट के रूप में, ऊपर दिखाए गए नियमित भाव केवल उपसर्ग, स्लैश, विभाजक आदि के बिना नंगे आईडी मानों का वर्णन करते हैं, जो कि URL और अन्य विभिन्न उपयोगों में मौजूद होना चाहिए। RegEx पैटर्न मैंने प्रस्तुत किया है जो कि पहचानकर्ता तारों के गुणों को देखते हुए गणितीय रूप से न्यूनतम है, लेकिन अगर अतिरिक्त संदर्भ के बिना उपयोग किया जाता है तो वे संभवतः बहुत सारे झूठे-सकारात्मक उत्पन्न करेंगे, जो है: गलत तरीके से मेल खाने वाले पाठ। वास्तविक उपयोग में इस समस्या से बचने के लिए, उन्हें यथासंभव आसन्न संदर्भ के साथ घेरें।

नोट्स

[1.]
जैसा कि ऊपर बताया गया है, यहाँ बेस 64 विनिर्देश का एक अंश है जो वर्णमाला प्रतीकों के चयन में उनके विचारों पर चर्चा करता है । यह समझने की कोशिश करने वाले व्यक्ति कि URL शब्दार्थ के साथ वर्णों के चयन में प्रक्रिया कैसे संपन्न हुई, स्पष्टीकरण कुछ अप्रत्याशित हो सकता है।

3.4। वर्णमाला चुनना

वर्णमाला के वर्णों पर विभिन्न अनुप्रयोगों की अलग-अलग आवश्यकताएं होती हैं। यहां कुछ आवश्यकताएं हैं जो यह निर्धारित करती हैं कि किस वर्णमाला का उपयोग किया जाना चाहिए:

मनुष्यों द्वारा संभाला गया। "0" और "O" अक्षर आसानी से भ्रमित होते हैं, जैसे कि "1", "l", और "I"। नीचे बेस 32 वर्णमाला में, जहां 0 (शून्य) और 1 (एक) मौजूद नहीं है, एक डिकोडर 0 को हे के रूप में व्याख्या कर सकता है, और 1 के रूप में 1 या मैं मामले के आधार पर एल। (हालांकि, डिफ़ॉल्ट रूप से यह नहीं होना चाहिए; पिछला अनुभाग देखें।)

अन्य आवश्यकताओं को अनिवार्य बनाने वाली संरचनाओं में एन्कोडेड। बेस 16 और बेस 32 के लिए, यह ऊपरी या निचले अक्षर का उपयोग निर्धारित करता है। आधार 64 के लिए, गैर-अल्फ़ान्यूमेरिक वर्ण (विशेष रूप से, "/") फ़ाइल नाम और URL में समस्याग्रस्त हो सकते हैं।

पहचानकर्ता के रूप में उपयोग किया जाता है। आधार 64 वर्णमाला में कुछ वर्ण, विशेष रूप से "+" और "/" को विरासत पाठ खोज / सूचकांक टूल द्वारा शब्द-विराम के रूप में माना जाता है।

कोई सार्वभौमिक रूप से स्वीकृत वर्णमाला नहीं है जो सभी आवश्यकताओं को पूरा करती है। एक अति विशिष्ट संस्करण के उदाहरण के लिए, IMAP [8] देखें। इस दस्तावेज़ में, हम वर्तमान में उपयोग किए गए कुछ अक्षर का नाम देते हैं।

[२.]
वैकल्पिक रूप से, एनटीएफएस फाइलसिस्टम पर फ़ाइल या पथ नामों के "जैसा है" के घटकों के रूप में बेस ६४-एन्कोडेड आईडी स्ट्रिंग्स का उपयोग करने की समस्या को हल करने के लिए, जो कि डिफ़ॉल्ट रूप से केस-असंवेदनशील है (और इस तरह तकनीकी रूप से जोखिम एक या एक से अधिक होने का जोखिम है। असंबंधित आईडी मान), ऐसा होता है कि NTFS को केस-संवेदी पथ / फ़ाइल नामकरण के साथ प्रति-वॉल्यूम आधार पर कॉन्फ़िगर किया जा सकता है । गैर-डिफ़ॉल्ट व्यवहार को सक्षम करना यहां वर्णित समस्या को ठीक कर सकता है, लेकिन इसकी अनुशंसा शायद ही कभी की जाती है, क्योंकि यह किसी भी / सभी असमान अनुप्रयोगों के लिए अपेक्षाओं को बदल देता है जो वॉल्यूम का निरीक्षण या उपयोग करते हैं। यदि आप इस विकल्प पर विचार कर रहे हैं, तो पहले इसे पढ़ें और समझें , और आप शायद अपना मन बदल लेंगे।

[३.]
मेरा मानना है कि चैनल प्लेलिस्ट पेज पर दिखाए गए वीडियो की कुल संख्या वीडियो के बहिष्करण को ध्यान में रखती है जो HTTP क्लाइंट के भौगोलिक क्षेत्र के अनुसार प्रतिबंधित हैं। यह प्लेलिस्ट बनाम चैनल के लिए सूचीबद्ध वीडियो की संख्या के बीच किसी भी विसंगति के लिए जिम्मेदार है।

— ग्लेन स्लेडेन
स्रोत

यह कुछ प्रभावशाली जासूसी का काम है।

— ऐले

पवित्र गुआमकोल, यह उत्तर 1,000s के पात्र हैं

— पिलाउ

YouTube चैनल आईडी अब २४ नहीं, २४ वर्णों वाली है; उदा। UCjXfkj5iapKHJrhYfAF9ZGg; स्रोत: stackoverflow.com/questions/14366648/…

— evandrix

@evandrix अपने नोट के लिए धन्यवाद। मेरी पोस्ट का अंतिम पैराग्राफ इस मुद्दे को संबोधित करने के लिए था; मैं केवल आईडी स्ट्रिंग के चर भाग पर चर्चा करता हूं । चैनल आईडी के लिए उपसर्ग हैं (उदाहरण के लिए यूसी या यूयू हो सकते हैं ) जो इस पोस्ट में चर्चा नहीं की गई हैं। यदि आपके पास एक उपसर्ग मूल्य है जैसे कि आपका उदाहरण, मेरे द्वारा दी गई जानकारी अंतिम 22 वर्णों पर लागू होती है।

— ग्लेन स्लेडेन

@evandrix यदि आप अभी भी रुचि रखते हैं, तो मैंने केवल UC बनाम UU ChannelId उपसर्गों के बारे में जानकारी शामिल करने के लिए लेख को अपडेट किया है।

— ग्लेन स्लेडेन