回答:
Youtube 2.0 APIドキュメントおよび3.0 APIドキュメントによると、videoIdは文字列であり、使用されている現在の文字セットについては何も指定されていません...
Youtube APIチームの投稿によると、長さは約11文字です。
YouTubeの動画IDの標準の長さである11文字を公式にコミットしているドキュメントには、どこにも記載されていません。現在実装されているものの1つであり、無期限にそのままである可能性があります。しかし、私たちはそれに対する公式のコミットメントを提供していませんので、あなた自身の責任で進めてください。
最後に重要なことですが、別の投稿で形式を明確にします（または明確にしません）。
動画IDの形式については、いかなる公的な保証も行いません。現在、文字、数字、句読点を含む11文字の文字列ですが、アプリケーションにハードコーディングすることはお勧めしません（将来変更する簡単な方法がない限り）。
Youtubeチームは、Video_IDが正しいかどうかをYoutubeサーバーに直接問い合わせることを好むようです（既存のビデオを参照）。
ランダムなユーザー入力が有効なビデオIDに対応していることを検証する必要がある場合は、経験的なテストを行うことをお勧めします。アクセスを試みる
http://gdata.youtube.com/feeds/api/videos/VIDEO_ID
200の応答を受け取った場合、VIDEO_IDは有効です。200以外の応答を受け取った場合、無効なIDがあります。新しくアップロードされた動画やプライベート動画にはいくつかのエッジケースがありますが、ほとんどの目的ではそれで問題ないと思います。
YouTube videoIdおよびchannelId識別子は、Base64エンコーディングのわずかに変更されたバージョンで表される単一の整数値です。IETF RFC4648勧告との違いの1つは、エンコーディングアルファベットの2文字の置換です。
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にすでに著名で確立された機能を持っている2つの文字を選択したという事実による可能性があります。[注1.]明らかに、ここで議論している使用法では、その特定の合併症を避けるのが最善でした。
公式の仕様とのもう1つの違いは、YouTubeの識別子は=パディング文字を使用しないことです。それぞれのデコードされた整数サイズごとに予想されるエンコードされた長さは固定されており（それぞれ64ビットと128ビットのエンコードされた11と22の「桁」）ため、必要ありません。
1つの小さな例外（以下で説明します）を除き、Base64マッピングの完全な詳細は、公開されているアクセス可能なデータから推測できます。最小限の当て推量で、videoIdおよびchannelId文字列で使用されるBase64スキームは次のようになります。
——₀————₁————₂————₃————₄————₅————₆————₇————₈————₉———₁₀———₁₁———₁₂———₁₃———₁₄———₁₅—
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はYouTube channelIdおよびvideoId識別子の異常な文字長（11および22文字）を正確に予測するためです。さらに、Base64に従って計算された剰余は、各タイプの識別子文字列のl̲a̲s̲t̲ c̲h̲a̲r̲a̲c̲t̲e̲r̲に見られる分布の変動を完全に説明しています。これらのポイントの説明は次のとおりです。
どちらの場合でも、Base64でエンコードされるバイナリ「データ」は、videoIdとchannelIdのそれぞれに対して、64ビットまたは128ビットの単一の整数です。したがって、Base64デコーダーを使用すると、文字列識別子から単一の整数を復元できます。これは、各整数idにBase64文字列とまったく同じ情報が含まれ、文字列がいつでも再作成できます。Unicodeとして保存されたBase64文字列と比較すると、バイナリ表現は63％小さく、最大ビット密度は100％で、メモリ内でより適切に整列し、ソートとハッシュが高速になります。正書法の場合にのみ異なる識別子間の誤った衝突。この最後の問題は、数値的には非常にありそうにありませんが、それでもBase64 IDが大文字と小文字を区別しないものとして扱われる場合、一部のファイルシステムがそうであるように除外できません（Windows、DOSに遡るなど）。
それは非常に重要です：Windows / NTFSファイル名の一部としてvideoId / channelId文字列を使用している場合、非常に小さな- しかしそれでもゼロではない-大文字と小文字を区別しないパスとファイル名を展開するファイルシステムによるファイル名の衝突の可能性があります。
このリモートで発生する可能性のある問題を心配している場合、数学的にそれを排除する1つの方法は、デコードされた整数を、この記事で説明されているように取得して、ベース10（10進数）または（均一そのようなファイルシステム上のパスまたはファイル名で使用するための、16進表記。[注2.]このアプローチでは、64ビットのvideoIdには20桁の10進数
[0-9]または8桁の16 進数が必要です[0-9,A-F]（対 Base64桁11桁）。128ビットchannelIdは、 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表現を、あなたは全部を保存し、それを維持する方法を把握する必要がありますcombobulatedあなたがそれを周りに渡すよう。単純な値型（またはSystem.Numerics.Vectors.Vector<T>、利用可能な場合、128ビットSIMDハードウェアレジスタとして現れる）が.NETでトリックを実行します（図示せず）。
[ 編集： ]
さらに考えた後、元の投稿の一部が最大限に完成していませんでした。公平を期すために、元の抜粋は保持されます（必要に応じてスキップできます）。すぐ下に、不足している洞察を説明します。[ original： ]
上記の「整数」を回復できることを書いたことに気づいたかもしれません。これは元々エンコードされていた値ではないでしょうか？必ずしも。そして、ここでは確認できない署名された/署名されていない区別をほのめかしていません（バイナリイメージに関する事実を変更しないため）。それは数値そのものです：「Rosetta Stone」なし「これにより、「正しい」ことがわかっている絶対値とのクロスチェックが可能になります。数値のアルファベットマッピングとエンディアンネスも明確に知ることができません。つまり、同じ値を回復している保証はありません。幸いなことに、YouTubeがいわゆる正しい値を不透明度の低い形式で他の場所に公開しない限り、これは問題になりません。デコードされた64ビットまたは128ビットの値は、いずれにしても識別トークン以外の用途がないため、トランスフォームの唯一の要件は、個別のエンコード（2つの一意のトークンが衝突しない）と可逆性（デコードは元のトークンIDを回復する）だけです。
言い換えれば、私たちが本当に気にするのは、元のBase64文字列のロスレスラウンドトリップです。Base64はロスレスで可逆的であるため（エンコードとデコードの両方で常に同じアルファベットマッピングとエンディアンネスの仮定に従う限り）、目的を満たします。数値は、YouTubeのマスターボールトに記録されている数値と一致しない場合がありますが、違いを見分けることはできません。
[ 新しい分析： ]
それはそこにあることが判明している「真」について教えすることができますいくつかの手がかりのBase64マッピングが。特定のマッピングのみが、観察する最終位置文字を予測します。つまり、これらの文字のみのバイナリ値には、一定数のLSBゼロが必要です。へえ。アルファベットと数字が昇順でマッピングされるという圧倒的に可能性の高い仮定と合わせて考えると、基本的に上記の表に示されているマッピングであることを確認できます。LSB分析が決定的でない唯一の不確実性は、
-と_文字（62/63）のスワップの可能性です。元のテキストでは、このLSBの問題について説明しました（以下を参照）が、その時点で完全に認識していなかったのは、LSB情報がBase64マッピングの可能性を制限する方法です。
これに関する最後のコメントは、実際にアプリが内部で動作するバイナリ解釈にビッグエンディアンを意図的に選択したい場合があるということです （最近ではリトルエンディアンよりも一般的ではないため、YouTubeの公式の方法ではないかもしれませんが）それ）。理由は、これは同じ値のデュアルビューの場合であり、実際のバイトオーダーがBase64レンディションで可視的に公開されるためです。バイナリ値と（多少は）人間が読めるBase64文字列との間でソート順を一致させることは役に立ちますが、混乱は少なくなりますが、リトルエンディアンバイナリ値のソートは、目的のASCII /字句ソートの重要なスクランブルです。
リトルエンディアンのID値で開始する場合（つまり、単に並べ替えを元に戻せない場合）、この問題に対する簡単な修正はありません。代わりに、デコード時に各バイナリ値のバイトを事前に計画し、逆にする必要があります。そのため、バイナリ値のソートに一致するアルファベット順の表示を気にする場合は、上記の関数を変更して、代わりにビッグエンディアン 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);
}
ビデオID
ためVIDEOID、それは8バイト（64ビット）の整数です。Base64エンコードを8バイトのデータに適用するには、11文字が必要です。ただし、各Base64文字は正確に6ビット（つまり、2⁶は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]
チャンネルまたはプレイリストID
channelIdとplaylistId文字列は、128ビット（16バイト）のバイナリ整数をBase64で符号化することによって製造されます。これにより、22文字の文字列が得られます。この文字列の先頭にはUC、チャンネル自体を識別するか、UU含まれている動画の完全なプレイリストを識別することができます。これらの24文字のプレフィックス文字列はURLで使用されます。たとえば、次は同じチャネルを参照する2つの方法を示しています。プレイリストバージョンには、チャンネル内の動画の合計数が表示されることに注意してください（注3を参照）。チャンネルページが公開しない有用な情報です。
チャンネルURLhttps://www.youtube.com/channel/UC K8sQmJBp8GCxrOtXWBpyEAプレイリストURLhttps://www.youtube.com/playlist?list=UU K8sQmJBp8GCxrOtXWBpyEA
11文字のvideoIdの場合と同様に、Base64ごとの計算では、観測された22文字の文字列長が正しく予測されます。この場合、出力は22 × 6 = 1324ビットの余剰ビットをエンコードできます。これらのゼロにより、64個のアルファベット記号のm̲o̲s̲t̲が最後の位置に表示されなくなり、残りの4つだけが対象となります。したがって、YouTube channelId文字列の最後の文字は次のいずれかでなければなりません。
{ A, Q, g, w }
これにより、channelIdの最大制約付き正規表現が得られます。
[0-9A-Za-z_-]{21}[AQgw]
最後の注意事項として、上記の正規表現は、URLやその他のさまざまな用途に存在する必要があるプレフィックス、スラッシュ、セパレータなどを除く、ベアID値のみを説明しています。私が提示したRegExパターンは、識別子文字列のプロパティを考えると、可能な限り数学的に最小限ですが、コンテキストを追加せずにそのまま使用すると、多くの誤検知、つまり、誤ったテキストと誤って一致する可能性があります。実際の使用でこの問題を回避するには、可能な限り予想される隣接コンテキストでそれらを囲みます。
注
[1.]
上記で約束したように、アルファベット記号を選択する際の考慮事項を説明するBase64仕様からの抜粋を次に示します。URLセマンティクスを使用した文字の選択でプロセスがどのように終了するかを理解しようとする個人は、説明がやや役に立たないことがあります。
3.4。アルファベットの選択
アプリケーションによって、アルファベットの文字に関する要件が異なります。以下に、使用するアルファベットを決定する要件をいくつか示します。
人間によって処理されます。「0」と「O」の文字は、「1」、「l」、「I」のように簡単に混同されます。以下のbase32アルファベットでは、0（ゼロ）と1（1）が存在しないため、デコーダは0をO、1をIまたはLとして解釈する場合があります。（ただし、デフォルトではそうではありません。前のセクションを参照してください。）
他の要件を要求する構造にエンコードされています。ベース16およびベース32の場合、これは大文字または小文字のアルファベットの使用を決定します。ベース64では、英数字以外の文字（特に「/」）がファイル名とURLで問題になる場合があります。
識別子として使用されます。特定の文字、特にベース64アルファベットの「+」と「/」は、従来のテキスト検索/インデックスツールによって単語区切りとして扱われます。
すべての要件を満たす、広く受け入れられているアルファベットはありません。高度に特殊化されたバリアントの例については、IMAP [8]を参照してください。このドキュメントでは、現在使用されているいくつかのアルファベットをドキュメント化して名前を付けています。
[2.]
または、Base64でエンコードされたID文字列をNTFSファイルシステム上のファイル名またはパス名の「そのままの」コンポーネントとして使用する問題を解決します。無関係のID値）、ボリュームごとに大文字と小文字を区別するパス/ファイルの名前付けでNTFS を構成できるようになります。デフォルト以外の動作を有効にすると、ここで説明する問題が解決する場合がありますが、ボリュームを検査またはアクセスするさまざまなアプリケーションに対する期待が変わるため、お勧めできません。このオプションを検討している場合は、最初にこれを読んで理解してください。そうすれば、おそらく考えが変わるでしょう。
[3.]
チャンネルプレイリストページに表示される動画の総数では、HTTPクライアントの地理的地域に応じて制限されている動画の除外が考慮されていると思います。これは、再生リストとチャンネルでリストされている動画の数の不一致を説明しています。
UC 対 UU channelIdの接頭辞を。