답변:
Youtube 2.0 API 문서 및 3.0 API 문서 에 따르면 videoId 는 문자열이며 현재 사용되는 문자 집합에 대해 지정된 것이 없습니다 ...
약 11 자 길이 로 Youtube API 팀 의 게시물 은 다음과 같습니다.
YouTube 동영상 ID의 표준 길이 인 11자를 공식적으로 약속하는 문서의 어느 부분도 보지 못했습니다. 그것은 우리가 현재 구현하고있는 것들 중 하나이며, 무한정 유지 될 수 있습니다. 그러나 이에 대한 공식적인 약속은 제공하지 않으므로 자신의 책임하에 진행하십시오.
그리고 마지막으로, 또 다른 게시물 은 다음과 같은 형식을 명확히 합니다.
동영상 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 권장 사항 과의 차이점 은 인코딩 알파벳에서 두 문자를 대체한다는 것입니다.
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 식별자가 =패딩 문자를 사용하지 않는다는 것입니다 . 각각의 디코딩 된 정수 크기마다 예상되는 인코딩 된 길이가 고정되고 알려져 있기 때문에 필요하지 않다 (각각 64 및 128 비트에 대해 11 및 22 인코딩 된 '숫자').
사소한 예외 (아래에서 설명)를 제외하고는 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 문자열과 정확히 동일한 정보가 포함되어 있고 문자열을 허용하기 때문에이를 수행하는 것이 매우 유용합니다. 유니 코드로 저장된 Base64 문자열과 비교할 때 언제든지 이진 표현이 63 % 더 작고 최대 비트 밀도가 100 %이며 메모리에 더 잘 정렬되고 정렬 및 해시가 더 빠르며, 아마도 가장 중요한 것은 직교 경우 에만 다른 식별자 간의 잘못된 충돌. 그럼에도 불구하고이 마지막 문제는 수치 적으로는 불가능하지만 Base64 ID가 일부 파일 시스템 (예 : Windows , DOS로 거슬러 올라가는 Windows) 에서 와 같이 대소 문자를 구분하지 않는 경우 제외 할 수 없습니다 .
Windows / NTFS 파일 이름의 일부로 videoId / channelId 문자열을 사용하는 경우 대소 문자를 구분하지 않는 경로와 파일 이름을 배포하는 파일 시스템으로 인해 파일 이름 충돌 가능성이 매우 적지 만 0이 아닙니다. .
이 원격으로 가능한 문제가 걱정된다면 수학적으로 제거하는 한 가지 방법은이 기사에서 설명한대로 디코딩 된 정수를 10 진수 또는 10 진수로 다시 인코딩하는 것입니다. cased) 16 진 표현으로, 해당 파일 시스템의 경로 또는 파일 이름에 사용합니다. [주 2] 이 방법에서는, 64 비트 인 videoId는 20 진수 필요
[0-9]8 자리 16 진수[0-9,A-F]( 대 11베이스 64 자리). 128 비트 채널 ID는 39 진수 16 개 진수 숫자 (최대 요구 대 22베이스 64 자리).
바이너리로 디코딩하면에 대한 사소한 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에서 트릭을 수행합니다 (표시되지 않음).
[ edit : ]
더 깊이 생각해 본 결과, 원래 게시물의 일부가 최대로 완료되지 않았습니다. 공정성을 위해 원래 발췌가 유지됩니다 (원하는 경우 건너 뛸 수 있음). 바로 아래에서 나는 빠진 통찰력을 설명합니다.[ 원본 : ]
당신은 당신이 "복구 할 수 쓴 위의 눈치 챘을 수도 "정수. 이것이 원래 인코딩 된 값이 아닙니까? 반드시 그런 것은 아닙니다. 그리고 나는 이진 이미지에 대한 사실을 변경하지 않기 때문에 여기서는 확인할 수없는 부호있는 / 부호없는 구별을 암시하지 않습니다. 숫자 값 자체입니다. " Rosetta Stone 없이"정확한"것으로 알려진 절대 값, 숫자 알파벳 매핑 및 엔디안을 알 수없는 양의 값으로 교차 점검 할 수 있습니다. 즉, 동일한 값을 복구한다고 보장 할 수 없습니다. 다행히도 YouTube가 소위 올바른 값을 덜 불투명 한 형식으로 공개적으로 노출시키지 않는 한, 이것은 중요하지 않습니다.이는 디코딩 된 64 또는 128 비트 값이 식별 토큰으로 만 사용되므로 사용되지 않기 때문에 변환에 대한 유일한 요구 사항은 고유 한 인코딩 (두 개의 고유 한 토큰이 충돌하지 않음) 및 가역성 (디코딩이 원래의 토큰 ID를 복구 함 ) 뿐입니다 .
다시 말해, 우리가 정말로 염려하는 것은 원래 Base64 문자열의 무손실 라운드 트립 입니다. Base64는 손실이없고 뒤집을 수 있기 때문에 ( 인코딩 및 디코딩 모두에 대해 항상 동일한 알파벳 매핑 및 엔디안 가정을 고수하는 한 ) 우리의 목적을 충족시킵니다. 숫자 값이 YouTube의 마스터 볼트에 기록 된 값과 일치하지 않을 수 있지만 차이점을 알 수는 없습니다.
[ 새 분석 : ]
그것은이 밝혀 입니다 은 "사실"에 대한 정보를 알 수있는 몇 가지 단서를 Base64로 매핑. 특정 매핑 만 우리가 관찰하는 최종 위치 문자를 예측합니다. 즉, 해당 문자 의 이진 값 에는 특정 개수의 LSB 0이 있어야합니다. 허.알파벳과 숫자 문자가 오름차순으로 매핑된다는 압도적으로 추정되는 가정과 함께, 우리는 기본적으로 매핑을 위의 표에 표시된 것으로 확인할 수 있습니다. 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 비트의 잉여 비트를 보유 할 수 있습니다. 초과 비트는 0으로 설정되어 인코딩 된 문자열의 마지막 위치에 특정 문자가 나타나지 않도록하는 효과가 있습니다. 특히 videoId 는 항상 다음 문자 중 하나로 끝나도록 보장됩니다.
{ A, E, I, M, Q, U, Y, c, g, k, o, s, w, 0, 4, 8 }
따라서 videoId에 대한 최대 제약 정규식 (RegEx)은 다음과 같습니다.
[0-9A-Za-z_-]{10}[048AEIMQUYcgkosw]
채널 또는 재생 목록 ID
채널 ID 및 playlistId 문자열은 128 비트 (16 바이트) 바이너리 정수 Base64로 부호화함으로써 생성된다. UC채널 자체 UU를 식별 하거나 포함 된 비디오의 전체 재생 목록을 식별 하기 위해 접두어를 붙일 수있는 22 자 문자열을 제공합니다 . 이 24 자리 접두사 문자열은 URL 에서 사용 됩니다 . 예를 들어, 다음은 동일한 채널을 참조하는 두 가지 방법을 보여줍니다. 재생 목록 버전에는 채널의 총 동영상 수가 표시됩니다 ( [주 3 참조]) 채널 페이지에 노출되지 않는 유용한 정보입니다.
채널 URLhttps://www.youtube.com/channel/UC K8sQmJBp8GCxrOtXWBpyEA재생 목록 URLhttps://www.youtube.com/playlist?list=UU K8sQmJBp8GCxrOtXWBpyEA
11 자 videoId 의 경우와 마찬가지로 Base64 당 계산은 22 자 길이의 관측 된 문자열 길이를 정확하게 예측합니다 . 이 경우 출력은 22 × 6 = 1324 비트의 잉여 비트 를 인코딩 할 수 있습니다 . 이 0은 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이 존재하지 않는 경우, 디코더는 경우에 따라 0을 O로, 1을 I 또는 L로 해석 할 수 있습니다. (그러나 기본적으로는 안됩니다. 이전 섹션을 참조하십시오.)
다른 요구 사항을 요구하는 구조로 인코딩되었습니다. 16 진과 32 진의 경우 대문자 또는 소문자 알파벳 사용을 결정합니다. base 64의 경우 영숫자가 아닌 문자 (특히 "/")가 파일 이름과 URL에서 문제가 될 수 있습니다.
식별자로 사용됩니다. 기본 64 알파벳의 "+"및 "/"와 같은 특정 문자는 레거시 텍스트 검색 / 색인 도구에 의해 단어 분리로 처리됩니다.
모든 요구 사항을 충족하는 보편적으로 허용되는 알파벳은 없습니다. 고도로 특수화 된 변형의 예는 IMAP [8]을 참조하십시오. 이 문서에서는 현재 사용되는 일부 알파벳을 문서화하고 이름을 지정합니다.
[2.]
또는 기본적으로 인코딩 된 Base64 인코딩 ID 문자열을 NTFS 파일 시스템에서 파일 또는 경로 이름의 "있는 그대로"구성 요소로 사용하는 문제를 해결하기 위해 기본적으로 대소 문자를 구분하지 않으므로 기술적으로 하나 이상의 충돌 위험이 있습니다. 관련이없는 ID 값) 에 따라 볼륨별로 대 / 소문자를 구분하는 경로 / 파일 이름 으로 NTFS 를 구성 할 수 있습니다 . 기본이 아닌 동작을 활성화하면 여기에 설명 된 문제가 해결 될 수 있지만 볼륨을 검사하거나 액세스하는 모든 개별 응용 프로그램에 대한 기대치를 변경하기 때문에 권장되지 않습니다. 이 옵션을 고려하고 있다면 먼저 읽고 이해하면 마음이 바뀔 것입니다.
[3]
채널 재생 목록 페이지에 표시된 총 비디오 수는 HTTP 클라이언트의 지리적 지역에 따라 제한된 비디오에 대한 제외를 고려한다고 생각합니다. 이는 재생 목록과 채널에 대해 나열된 동영상 수의 차이를 설명합니다.
UC 대 UU 채널 ID의 접두사를.