ইউটিউব ভিডিও আইডি জন্য ফর্ম্যাট

ইউটিউব ২.০ এপিআই ডকুমেন্টেশন এবং ৩.০ এপিআই ডকুমেন্টেশন অনুসারে , ভিডিওআইডিড একটি স্ট্রিং, ব্যবহৃত অক্ষরের বর্তমান সেট সম্পর্কে কিছুই নির্দিষ্ট করা হয়নি ...

11 টি অক্ষরের দৈর্ঘ্য সম্পর্কে, ইউটিউব এপিআই টিমের একটি পোস্ট বলবে:

আমি ডকুমেন্টেশনের কোথাও দেখতে পাচ্ছি না যেখানে আমরা আনুষ্ঠানিকভাবে ইউটিউব ভিডিও আইডির জন্য 11 টি অক্ষরের মান দৈর্ঘ্যের প্রতি আনুষ্ঠানিক প্রতিশ্রুতিবদ্ধ। এটি এমন একটি জিনিসের মধ্যে যেখানে আমাদের একটি বর্তমান বাস্তবায়ন রয়েছে এবং এটি অনির্দিষ্টকালের জন্য সেভাবেই থাকতে পারে। তবে আমরা তাতে কোনও সরকারী প্রতিশ্রুতি দিচ্ছি না, সুতরাং আপনার নিজের ঝুঁকিতে এগিয়ে যান।

এবং সর্বশেষে তবে সর্বনিম্ন নয়, অন্য একটি পোস্ট ফর্ম্যাটটি স্পষ্ট করে (বা না):

আমরা ভিডিও আইডির জন্য ফর্ম্যাট সম্পর্কে কোনও পাবলিক গ্যারান্টি দিই না। তারা বর্তমানে ১১ টি চরিত্রের স্ট্রিংগুলিতে রয়েছে যেখানে অক্ষর, সংখ্যা এবং কিছু বিরামচিহ্ন রয়েছে, আমি আপনার অ্যাপ্লিকেশনটিতে হার্ডকোডিংয়ের পরামর্শ দিচ্ছি না (যদি না ভবিষ্যতে এটির পরিবর্তনের কোনও সহজ উপায় না থাকে)।

ইউটিউব দলটি যদি ইউটিউব সার্ভারটি সরাসরি ভিডিও_আইডি সঠিক কিনা তবে (বিদ্যমান ভিডিওটি দেখুন) জিজ্ঞাসা করতে পছন্দ করে:

আপনি যদি এলোমেলোভাবে ব্যবহারকারীর ইনপুটটি কোনও বৈধ ভিডিও আইডির সাথে মিলে যায় তা প্রমাণ করতে চাইলে আমি একটি অভিজ্ঞতা অভিজ্ঞতা নেওয়ার পরামর্শ দেব। অ্যাক্সেস চেষ্টা

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

যদি আপনি 200 টি প্রতিক্রিয়া পান তবে VIDEO_ID টি বৈধ। আপনি যদি 200-অ-প্রতিক্রিয়া পান তবে আপনার একটি অবৈধ আইডি রয়েছে। নতুন আপলোড করা ভিডিও বা ব্যক্তিগত ভিডিওগুলির জন্য কয়েকটি প্রান্তের কেস রয়েছে তবে বেশিরভাগ উদ্দেশ্যে আমি ধরে নিই যে এটি ঠিক আছে।

— ক্যাড্রিক জুলিয়েন
সূত্র

এটি দুর্দান্ত উত্তর, এবং আমার প্রয়োজনীয় সমস্ত তথ্য আমাকে দিয়েছেন! ধন্যবাদ!

— স্বীকার করে

এটি এখন চলে যাওয়া এইচটিটিপি 410 প্রদান করে। এটি এখন যাচাই করার জন্য নতুন ইউআরএলটি কী হওয়া উচিত সে সম্পর্কে কোনও ধারণা?

— উইল স্ট্রোহল

ভিডিও আইডি যাচাই করতে: কেবল ইউটিউব থেকে এইচটিএমএল পৃষ্ঠা পান এবং যাচাই করে নিন যে মেটা ক্যানোনিকাল লিঙ্কটি আপনার নির্দিষ্ট করে দিয়েছে।

— পুচু

ইউটিউব ভিডিওআইডি এবং চ্যানেলআইডি শনাক্তকারীরা একক পূর্ণসংখ্যা মানগুলি বেস 6464 এনকোডিংয়ের সামান্য পরিবর্তিত সংস্করণে উপস্থাপিত হয় । আইইটিএফ আরএফসি 464৪৮ সুপারিশের বিপরীতে একটি পার্থক্য হ'ল এনকোডিং বর্ণমালায় দুটি অক্ষরের প্রতিস্থাপন:

 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)

প্রতিস্থাপনটি সম্ভবত এই কারণে হয়েছে যে কোনও কারণে আরএফসি 4648 দুটি অক্ষর নির্বাচন করেছে যা ইতিমধ্যে ইউআরএলে বিশিষ্ট এবং সু-প্রতিষ্ঠিত ফাংশন রয়েছে। ^{[দ্রষ্টব্য 1.]} স্পষ্টতই, এখানে আলোচনার অধীনে ব্যবহারের জন্য, সেই নির্দিষ্ট জটিলতা সবচেয়ে ভাল এড়ানো হয়েছিল।

অফিসিয়াল স্পেসিফিকেশন থেকে আর একটি পার্থক্য হ'ল ইউটিউব শনাক্তকারীরা =প্যাডিং চরিত্রটি ব্যবহার করে না ; এটি প্রয়োজনীয় নয় কারণ সম্পর্কিত ডিকোডযুক্ত পূর্ণসংখ্যার আকার অনুযায়ী প্রত্যাশিত এনকোড দৈর্ঘ্যগুলি স্থির এবং পরিচিত (যথাক্রমে and 64 এবং ১২৮ বিটের জন্য ১১ এবং ২২ এনকোডড 'ডিজিট) থাকে।

একটি ছোটখাট ব্যতিক্রম (নীচে আলোচনা করা হয়েছে), বেস 64 ম্যাপিংয়ের সম্পূর্ণ বিবরণটি সর্বজনীনভাবে অ্যাক্সেসযোগ্য ডেটা থেকে অনুমান করা যায়। ন্যূনতম অনুমানের সাথে, সম্ভবত ভিডিওআইড এবং চ্যানেলআইডি স্ট্রিংগুলিতে ব্যবহৃত বেস 64 স্কিমটি নিম্নরূপ:

    ——₀————₁————₂————₃————₄————₅————₆————₇————₈————₉———₁₀———₁₁———₁₂———₁₃———₁₄———₁₅—
     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 ইউটিউব চ্যানেলআইডি এবং ভিডিওআইড শনাক্তকারীদের ঠিক অস্বাভাবিক চরিত্রের দৈর্ঘ্য (11 এবং 22 অক্ষর) পূর্বাভাস দেয় । তদ্ব্যতীত, remainders করুন Base64- অনুযায়ী গণনা করা পুরোপুরি পাওয়া পর্যবেক্ষিত distributional প্রকরণ ব্যাখ্যা শেষ অক্ষর আইডেন্টিফায়ার স্ট্রিং প্রতিটি ধরনের। নিম্নলিখিত এই পয়েন্টগুলি আলোচনা।

উভয় ক্ষেত্রেই, বাইনারি "ডেটা" যা বেস64- এনকোডযুক্ত হয় এটি একটি একক পূর্ণসংখ্যা, হয় যথাক্রমে 64৪ বা 128 বিট, ভিডিও আইডি বনাম চ্যানেলআইডির জন্য । তদনুসারে, বেস 6464 ডিকোডার ব্যবহার করে স্ট্রিং আইডেন্টিফায়ার থেকে একটি একক পূর্ণসংখ্যার পুনরুদ্ধার করা যায় এবং এটি করা বেশ কার্যকর হতে পারে কারণ প্রতিটি সংখ্যার আইডিতে বেস 64 স্ট্রিং-এর ঠিক একই তথ্য থাকে এবং স্ট্রিংটিকেও অনুমতি দেয় যেকোন সময় পুনরায় তৈরি করুন - যখন ইউনিকোড হিসাবে সঞ্চিত বেস 64 স্ট্রিংগুলির সাথে তুলনা করা হয়, তখন বাইনারি উপস্থাপনাটি 63% ছোট হয়, সর্বাধিক বিট-ডেনসিটি 100% থাকে, মেমরিতে আরও ভালভাবে সাজায়, দ্রুততর আকারে এবং হ্যাশগুলি দ্রুত সঞ্চার করে এবং সম্ভবত সবচেয়ে গুরুত্বপূর্ণভাবে মুছে ফেলা হয় ates সনাক্তকারীদের মধ্যে মিথ্যা সংঘর্ষ যা কেবল অর্থোগ্রাফিক ক্ষেত্রে পৃথক। এই শেষ সমস্যাটি যদিও সাংখ্যিকভাবে অসম্ভব, তবুও কিছু ফাইল সিস্টেম যেমন বেস 64 আইডি কে কেস-সংবেদনশীল হিসাবে বিবেচনা করা হয় তবে তা অস্বীকার করা যায় না (যেমন উইন্ডোজ , ডস-এর সাথে ডেটে ফিরে এসেছে )।

এটি গুরুত্বপূর্ণ গুরুত্বপূর্ণ: আপনি যদি উইন্ডোজ / এনটিএফএস ফাইলের নাম হিসাবে একটি ভিডিওআইডি / চ্যানেলআইডি স্ট্রিংটি ব্যবহার করেন তবে একটি অদৃশ্যভাবে মিনিসিকিউল রয়েছে — তবে তবুও ফাইল - নাম সংঘর্ষের ক্ষেত্রে ফাইল-নাম সংঘটিত হওয়ার সম্ভাবনা নেই-সংবেদনশীল পথ এবং ফাইল নামকরণ ।

যদি আপনি এই দূরবর্তী সম্ভাব্য সমস্যাটি সম্পর্কে উদ্বিগ্ন থাকেন তবে গাণিতিকভাবে তা দূর করার একটি উপায় হ'ল ডিকোড করা পূর্ণসংখ্যাগুলি পুনরায় এনকোড করা - এখনও এই নিবন্ধে বর্ণিত হিসাবে প্রাপ্ত - একটি বেস -10 (দশমিক) বা (অভিন্ন- কেসড) হেক্সাডেসিমাল উপস্থাপনা, যেমন ফাইল সিস্টেমগুলিতে পাথ বা ফাইলের নাম ব্যবহারের জন্য। ^{[দ্রষ্টব্য 2.]} এই পদ্ধতির মধ্যে, 64-বিট ভিডিও আইডির জন্য 20 দশমিক সংখ্যা [0-9]বা 8 হেক্স অঙ্ক [0-9,A-F]( বনাম 11 বেস 64 সংখ্যা) প্রয়োজন হবে। 128-বিট চ্যানেলআইডির জন্য সর্বোচ্চ 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-বিট সিমডি হার্ডওয়্যার রেজিস্টার হিসাবে উপস্থিত থাকে যখন উপস্থিত হয়)। নেট এ কৌশলটি প্রদর্শন করবে (দেখানো হয়নি)।

[ সম্পাদনা: ]
আরও চিন্তা করার পরে, আমার মূল পোস্টের একটি অংশ সর্বাধিক সম্পূর্ণ হয়নি not ন্যায্যতার জন্য, মূল অংশটি ধরে রাখা হয় (আপনি চাইলে এটি এড়িয়ে যেতে পারেন); অবিলম্বে নীচে আমি নিখোঁজ অন্তর্দৃষ্টি ব্যাখ্যা:

[ মূল: ]
আপনি সম্ভবত লক্ষ্য করেছেন যে আমি লিখেছি যে আপনি " একটি " পূর্ণসংখ্যা পুনরুদ্ধার করতে পারেন । এটি কি মূলত এনকোড করা মান হবে না? অগত্যা। এবং আমি স্বাক্ষরিত / স্বাক্ষরযুক্ত স্বতন্ত্রতার ইঙ্গিত দিচ্ছি না যা সত্য, এটি এখানে নির্ধারণ করা যায় না (কারণ এটি বাইনারি চিত্র সম্পর্কে কোনও তথ্য পরিবর্তন করে না)। এগুলি নিজেই সংখ্যাসূচক মান: কিছু " রোসটা স্টোন ছাড়াই"এটি আমাদেরকে" সঠিক "হিসাবে পরিচিত নিরঙ্কুশ মানগুলি ক্রস-চেক করতে দেয়, সংখ্যার বর্ণমালা ম্যাপিং এবং এন্ডিয়ান-নেস ইতিবাচকভাবে জানা যায় না, যার অর্থ আপনি একই মান পুনরুদ্ধার করার কোনও গ্যারান্টি নেই there's ভাগ্যক্রমে, যতক্ষণ না ইউটিউব প্রকাশ্য তথাকথিত সঠিক মানগুলি অন্য কোথাও স্বচ্ছ অস্বচ্ছ বিন্যাসে প্রকাশ করে না, সম্ভবত এটি গুরুত্ব পাবে না।

এর কারণ হ'ল ডিকোডেড 64৪- বা 128-বিট মানগুলির যাইহোক শনাক্তকরণ টোকেন হিসাবে ব্যতীত অন্য কোনও ব্যবহার নেই, সুতরাং রূপান্তরটির জন্য আমাদের একমাত্র প্রয়োজনীয়তাগুলি পৃথক এনকোডিং (কোনও দুটি অনন্য টোকেন সংঘর্ষে নেই) এবং বিপর্যয়যোগ্যতা (ডকোডিংটি মূল টোকেন পরিচয়টি পুনরুদ্ধার করে)।

অন্য কথায়, আমরা সত্যই যা যত্ন করি তা হ'ল আসল বেস 64 স্ট্রিংয়ের ক্ষতিহীন গোল-ট্রিপিং । যেহেতু করুন Base64- অবচয়হীন এবং উলটাকর (যতদিন আপনি সবসময় একই বর্ণমালা ম্যাপিং এবং বিদ্ধ হয় endianness উভয় এনকোডিং ও ডিকোডিং জন্য ধৃষ্টতা) এটিকে সন্তুষ্ট আমাদের উদ্দেশ্য। আপনার সংখ্যার মানগুলি ইউটিউবের মাস্টার ভল্টে রেকর্ড হওয়া সাথে মেলে না তবে আপনি কোনও পার্থক্য বলতে পারবেন না।
[ নতুন বিশ্লেষণ: ]
এটি সক্রিয় আউট যে হয় কয়েক সংকেত সনাক্ত করুন যে "সত্যিকারের" সম্পর্কে বলতে পারেন করুন Base64- ম্যাপিং। কেবলমাত্র কিছু ম্যাপিংসই চূড়ান্ত অবস্থানের অক্ষরগুলির পূর্বাভাস দেয় যা আমরা পর্যবেক্ষণ করি, যার অর্থ কেবল সেই অক্ষরের বাইনারি মান অবশ্যই একটি নির্দিষ্ট সংখ্যক এলএসবি জিরো থাকতে পারে। হেহ।

বর্ণমালা এবং অঙ্কের অক্ষরগুলি আরোহী ক্রমে ম্যাপ করা হয়েছে এমন অতিমাত্রায় অনুমানের সাথে একত্রিত হয়ে, আমরা মূলত উপরের টেবিলগুলিতে প্রদর্শিত ম্যাপিংটিকে নিশ্চিত করতে পারি। এলএসবি বিশ্লেষণটি যে ক্ষেত্রে কেবলমাত্র অনিশ্চিত, তার মধ্যে কেবলমাত্র অনিশ্চয়তা -এবং _অক্ষরগুলির ( 62/ 63) সম্ভাব্য অদলবদল ।

মূল টেক্সট করেনি এই lsb সমস্যা (আরও নিচে দেখুন) আলোচনা, কিন্তু কি আমি সম্পূর্ণরূপে সময়ে বুঝতে পারছি না কিভাবে lsb তথ্য সম্ভব সীমিত করতে কাজ করে ছিল করুন Base64- ম্যাপিং।

এ সম্পর্কে একটি সর্বশেষ মন্তব্যটি হ'ল আপনি সম্ভবত নিজের অ্যাপ্লিকেশনটি অভ্যন্তরীণভাবে কাজ করে বাইনারি ব্যাখ্যার জন্য ইচ্ছাকৃতভাবে বড়-ইন্ডিয়ান বেছে নিতে চান (যদিও এটি আজকাল লিটল-এন্ডিয়ানের চেয়ে কম সাধারণ এবং এইভাবে ইউটিউব 'আনুষ্ঠানিকভাবে' যেভাবে করে না এটা)। কারণটি হ'ল এটি একই মানটির উপর দ্বৈত দর্শনগুলির একটি ক্ষেত্রে, যেমন আসল বাইট ক্রমটি দৃশ্যমানভাবে बेस 64 রেন্ডিশনে প্রকাশিত হয়। এটা তোলে সহায়ক এবং কম রাখার বিভ্রান্তিকর সাজানোর ক্রম বাইনারি মান এবং (কিছুটা বেশি) মানুষের পাঠযোগ্য করুন Base64- স্ট্রিং, কিন্তু অল্প endian বাইনারি মান সাজানোর মধ্যে সামঞ্জস্যপূর্ণ পছন্দসই হওয়া ASCII / আভিধানিক সাজানোর একটি অ-তুচ্ছ একত্র হয় ।

আপনি যদি লিটল-এন্ডিয়ান আইডি মান দিয়ে শুরু করেন তবে এই সমস্যাটির জন্য কোনও সহজ সমাধান নেই (অর্থাত্ তাদের ধরণের বিপরীত কাজ করবে না)। পরিবর্তে, আপনাকে এগিয়ে পরিকল্পনা করতে হবে এবং ডিকোডিংয়ের সময় প্রতিটি বাইনারি মানের বাইটগুলি বিপরীত করতে হবে । সুতরাং আপনি যদি বাইনারি মানগুলির বাছাইয়ের সাথে মিলে বর্ণানুক্রমিক প্রদর্শনের বিষয়ে যত্নশীল হন তবে আপনি উপরে প্রদর্শিত ফাংশনটি পরিবর্তন করতে চাইতে পারেন যাতে এটি পরিবর্তে বড়-এন্ডিয়ান 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);
}

ইউটিউব আইডি

ভিডিও আইডি

ভিডিওআইডির জন্য এটি একটি 8-বাইট (64-বিট) পূর্ণসংখ্যা। 8 বাইট ডেটাতে বেস 64-এনকোডিং প্রয়োগের জন্য 11 টি অক্ষর প্রয়োজন । তবে যেহেতু প্রতিটি বেস 64 অক্ষর হুবহু 6 টি বিট দেয় (যেমন, 2⁶ সমান 64৪), এই বরাদ্দটি আসলে 11 × 6 = 66বিটগুলি ধরে রাখতে পারে - আমাদের পেডলোডের চাহিদার 64 বিটের চেয়ে 2 বিটের একটি উদ্বৃত্ত। অতিরিক্ত বিটগুলি শূন্যে সেট করা আছে, যা এনকোডযুক্ত স্ট্রিংয়ের শেষ অবস্থানে উপস্থিত থেকে নির্দিষ্ট অক্ষরকে বাদ দেওয়া প্রভাব ফেলে। বিশেষত, ভিডিও আইডিটি সর্বদা নিম্নলিখিত অক্ষরের সাথে শেষ হওয়ার গ্যারান্টিযুক্ত:

{ 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 স্ট্রিং একটি 128-বিট (16 বাইট) বাইনারি পূর্ণসংখ্যা করুন Base64- এনকোডিং দ্বারা উত্পাদিত হয়। এটি একটি 22-চরিত্রের স্ট্রিং দেয় যা UCচ্যানেলটি সনাক্ত করতে বা UUএটিতে থাকা ভিডিওর একটি সম্পূর্ণ প্লেলিস্ট সনাক্তকরণের সাথে উপসর্গ করা যেতে পারে। এই 24-অক্ষরের উপসর্গযুক্ত স্ট্রিংগুলি ইউআরএল-এ ব্যবহৃত হয় । উদাহরণস্বরূপ, নীচে একই চ্যানেলটি উল্লেখ করার দুটি উপায় দেখায়। লক্ষ্য করুন যে প্লেলিস্ট সংস্করণ চ্যানেলে ভিডিওগুলির মোট সংখ্যা দেখায়, ^{[চিরকুটটি দেখুন]]} একটি দরকারী তথ্য অংশ যা চ্যানেল পৃষ্ঠাগুলি প্রকাশ করে না।

চ্যানেল ইউআরএল
https://www.youtube.com/channel/UC K8sQmJBp8GCxrOtXWBpyEA
প্লেলিস্ট ইউআরএল
https://www.youtube.com/playlist?list=UU K8sQmJBp8GCxrOtXWBpyEA

11-চরিত্রের ভিডিওআইডির মতো , বেস 64 এর গণনাটি 22-অক্ষরের পর্যবেক্ষণ করা স্ট্রিং দৈর্ঘ্যের সঠিকভাবে ভবিষ্যদ্বাণী করে । এই ক্ষেত্রে, আউটপুট 22 × 6 = 1324 টি বিটের উদ্বৃত্ত বিটগুলি এনকোডিং করতে সক্ষম ; এই শূন্যগুলি শেষ পর্যন্ত উপস্থিত হওয়া থেকে 64৪ টি বর্ণমালার প্রতীকগুলির মুসোসিতিকে সীমাবদ্ধ রেখে শেষ করেছে, কেবলমাত্র ৪ জন যোগ্য। আমরা তাই জানি যে ইউটিউব চ্যানেলআইডি স্ট্রিংয়ের শেষ চরিত্রটি নিম্নলিখিতগুলির মধ্যে একটি হতে হবে:

{ A, Q, g, w }

এটি আমাদেরকে একটি চ্যানেলআইডির সর্বাধিক সীমাবদ্ধ নিয়মিত অভিব্যক্তি দেয় :

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

চূড়ান্ত দ্রষ্টব্য হিসাবে, উপরে প্রদর্শিত নিয়মিত প্রকাশগুলি কেবল উপসর্গ, স্ল্যাশ, বিভাজনকারী ইত্যাদি ইত্যাদি ব্যার আইডি মানগুলি বর্ণনা করে যা ইউআরএল এবং অন্যান্য বিভিন্ন ব্যবহারের মধ্যে উপস্থিত থাকতে হবে। আমি যে রেগেক্স প্যাটার্নগুলি উপস্থাপন করেছি তা সনাক্তকারী স্ট্রিংয়ের বৈশিষ্ট্যগুলি হিসাবে গণিতের তুলনায় যথাসম্ভব ন্যূনতম, তবে অতিরিক্ত প্রসঙ্গ ব্যতীত যদি এটি ব্যবহার করা হয় তবে তারা সম্ভবত প্রচুর পরিমাণে মিথ্যা-পজিটিভ তৈরি করতে পারে, এটি: ভুলভাবে মজাদার পাঠ্যের সাথে মেলে। প্রকৃত ব্যবহারে এই সমস্যাটি এড়াতে, যতটা সম্ভব প্রত্যাশিত সংলগ্ন প্রসঙ্গটি দিয়ে তাদের ঘিরে রাখুন।

নোটস

[১.]
উপরে প্রতিশ্রুতি হিসাবে, এখানে বেস 64 স্পেসিফিকেশন থেকে একটি অংশ রয়েছে যা বর্ণমালার প্রতীক নির্বাচন করার ক্ষেত্রে তাদের বিবেচনার বিষয়ে আলোচনা করে। ইউআরএল শব্দার্থবিজ্ঞানের সাথে অক্ষর নির্বাচনের প্রক্রিয়াটি কীভাবে শেষ হয়েছে তা বুঝতে আগ্রহী ব্যক্তিরা ব্যাখ্যাটি কিছুটা অবিশ্রুত করতে পারেন।

3.4। বর্ণমালা নির্বাচন করা

বর্ণমালার অক্ষরগুলির জন্য বিভিন্ন অ্যাপ্লিকেশনের বিভিন্ন প্রয়োজনীয়তা রয়েছে। এখানে কয়েকটি প্রয়োজনীয়তা রয়েছে যা নির্ধারণ করে যে কোন বর্ণমালাটি ব্যবহার করা উচিত:

মানুষের দ্বারা পরিচালিত "0" এবং "ও" অক্ষরগুলি সহজেই বিভ্রান্ত হয়, যেমন "1", "এল" এবং "আমি"। নীচের বেস 32 বর্ণমালায় যেখানে 0 (শূন্য) এবং 1 (এক) উপস্থিত নেই, সেখানে একটি ডিকোডার 0 কে O হিসাবে এবং 1 কে ক্ষেত্রে বা তার উপর নির্ভর করে I বা L ব্যাখ্যা করতে পারে। (তবে, ডিফল্টরূপে এটি হওয়া উচিত নয়; পূর্ববর্তী বিভাগটি দেখুন))

কাঠামোতে এনকোড করা হয়েছে যা অন্যান্য প্রয়োজনীয়তার আদেশ দেয়। বেস 16 এবং বেস 32 এর জন্য, এটি উচ্চ- বা ছোট হাতের বর্ণমালাগুলির ব্যবহার নির্ধারণ করে। বেস 64৪ এর জন্য, অ-অক্ষরীয় অক্ষরগুলি (বিশেষত, "/") ফাইলের নাম এবং URL গুলিতে সমস্যাযুক্ত হতে পারে।

সনাক্তকারী হিসাবে ব্যবহৃত হয়। কিছু নির্দিষ্ট অক্ষর, উল্লেখযোগ্যভাবে "+" এবং "/" বেস 64 এর বর্ণমালায়, উত্তরাধিকারের পাঠ্য অনুসন্ধান / সূচীকরণ সরঞ্জাম দ্বারা শব্দ বিরতি হিসাবে বিবেচিত হয়।

এমন কোনও বিশ্বব্যাপী অনুমোদিত বর্ণমালা নেই যা সমস্ত প্রয়োজনীয়তা পূরণ করে। উচ্চতর বিশেষায়িত বৈকল্পিকের উদাহরণের জন্য, IMAP [8] দেখুন। এই দস্তাবেজে, আমরা বর্তমানে ব্যবহৃত কিছু বর্ণমালা ডকুমেন্ট এবং নামকরণ করি।

[২]
বিকল্প হিসাবে, বেসটি 64৪-এনকোডড আইডি স্ট্রিংগুলি এনটিএফএস ফাইল সিস্টেমের ফাইল বা পাথের নামগুলির "হিসাবে রয়েছে" হিসাবে ব্যবহার করার সমস্যা সমাধানের জন্য, এটি ডিফল্টরূপে সংবেদনশীল নয় (এবং প্রযুক্তিগতভাবে এক বা একাধিক সংঘাতের ঝুঁকিপূর্ণ সম্পর্কযুক্ত আইডি মানগুলি), এমনটি ঘটে যে এনটিএফএস প্রতি-ভলিউমের ভিত্তিতে কেস-সংবেদনশীল পাথ / ফাইলের নামকরণের মাধ্যমে কনফিগার করা যায় । অ-ডিফল্ট আচরণ সক্ষম করা এখানে বর্ণিত সমস্যাটিকে ঠিক করতে পারে তবে খুব কমই সুপারিশ করা হয় কারণ এটি যে কোনও / সমস্ত বিচ্ছিন্ন অ্যাপ্লিকেশনগুলির প্রত্যাশা পরিবর্তন করে যা ভলিউম পরিদর্শন করে বা অ্যাক্সেস করে। আপনি যদি এই বিকল্পটি বিবেচনাও করেন তবে প্রথমে এটি পড়ুন এবং বুঝুন এবং আপনি সম্ভবত নিজের মতামত পরিবর্তন করবেন।

[৩.]
আমি বিশ্বাস করি যে চ্যানেল প্লেলিস্ট পৃষ্ঠাটি দেখানো মোট ভিডিও সংখ্যা এইচটিটিপি ক্লায়েন্টের ভৌগলিক অঞ্চল অনুযায়ী সীমাবদ্ধ এমন ভিডিওগুলিকে বাদ দেওয়ার বিষয়টি বিবেচনা করে। প্লেলিস্ট বনাম চ্যানেলের জন্য তালিকাভুক্ত ভিডিওর সংখ্যার মধ্যে যে কোনও তাত্পর্য হওয়ার জন্য এটি অ্যাকাউন্ট করে।

— গ্লেন স্লেডেন
সূত্র

এটি কিছু চিত্তাকর্ষক গোয়েন্দা কাজ।

— আলে

পবিত্র guacamole, এই উত্তর upvotes এর 1,000s দাবী

— পলান্ন

ইউটিউব চ্যানেল আইডি এখন ২২ টি চর দীর্ঘ, 22 টি নয়; যেমন UCjXfkj5iapKHJrhYfAF9ZGg; উৎস: stackoverflow.com/questions/14366648/...

— evandrix

@ আইভানড্রিক্স আপনার নোটের জন্য ধন্যবাদ। আমার পোস্টের শেষ অনুচ্ছেদটি এই ইস্যুটিকে সম্বোধন করার উদ্দেশ্যে করা হয়েছিল; আমি কেবল আইডি স্ট্রিংয়ের পরিবর্তনশীল অংশটিই আলোচনা করি । চ্যানেল আইডির উপসর্গ রয়েছে (উদাহরণস্বরূপ ইউসি বা ইউইউ হতে পারে ) যা এই পোস্টে আলোচনা করা হয়নি। আপনার উদাহরণের মতো যদি আপনার উপসর্গীকৃত মান থাকে তবে আমার দেওয়া তথ্যটি সর্বশেষ 22 টি অক্ষরের জন্য প্রযোজ্য।

— গ্লেন স্লেডেন

@ ইভানড্রিক্স আপনি যদি এখনও আগ্রহী হন তবে UC ভার্সেস UU চ্যানেলআইড উপসর্গ সম্পর্কে তথ্য অন্তর্ভুক্ত করার জন্য আমি কেবল নিবন্ধটি আপডেট করেছি ।

— গ্লেন স্লেডেন