Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday July 19 2019, @05:08PM   Printer-friendly
from the interesting dept.

Over the years I have viewed many a video on YouTube. I quickly noticed an "ID" string that appeared in each video URL. Here's an example: https://www.youtube.com/watch?v=ShvnDSgjfXw -- see that string "ShvnDSgjfXw"? What characters are permitted? How long is it?

Along the way, I came upon an amazingly useful utility: youtube-dl. I accidentally discovered that it will happily download a YouTube video given just the Video ID. (Don't let the name of the utility mislead you; it seems to work fine with Instagram, Twitter, Sound Cloud... it's amazing!)

Now with my curiosity suitably piqued, I started a genuine search for what the parameters were that defined a valid YouTube Video ID. This question on "Web Applications Stack Exchange" was most helpful. Especially this response.

It appears that the Video ID (and the Channel ID) are modified base64 encodings of 64-bit (and 128-bit) integers. The primary change is that the base64 encoding produces two characters that are verboten in URLs. A generated "/" is replaced with "-" and a generated "+" is replaced with a "_".

There is no official documentation claiming that the ID lengths are guaranteed to always be 11 or 22 characters long, but empirical evidence suggests that is the current, de-facto standard.

There is even mention of " the maximally-constrained regular expression (RegEx) for the videoId" being:

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

Things get even more interesting if you are using Windows. Under NTFS, file names default to be case-preserving, but case-insensitive. Say I create a file called "Foo.txt" and then get a directory listing. Sure enough, I see: "Foo.txt" displayed. The fun comes if I do "DIR foo.txt" or "DIR FOO.TXT" or any other variation... they all find the same file: "Foo.txt"; this is counter to Unix where filenames are case-sensitive and each of those variations would be treated as separate and distinct files. Though it is possible to make an NTFS volume case-sensitive, it is not for the faint of heart!

One could, therefore, reverse-engineer the integer that produced the Video ID and use that in addition (or for the adventuresome: instead of) the Video ID.

The whole discussion was well-worth the read and highly recommended for anyone who would like more information on where it came from and how it came about.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by digitalaudiorock on Saturday July 20 2019, @02:30AM (7 children)

    by digitalaudiorock (688) on Saturday July 20 2019, @02:30AM (#869258) Journal

    Amen to that...I'd mod your post if it wasn't already +5. The strange thing to me is the notion that case insensitive file systems are some how more simple. I'd bed the original decisions to make Unix file systems case sensitive...like most decisions made in Unix...was because it is the more simple approach. Maybe it's just my technical look on things but it sure seems so to me. In a case insensitive file system, I have a file MyFile.txt. So what exactly uniquely defines that file? Is it MyFile.txt, myfile.txt, MyFiLe.TXT...the answer is really all of the above. Fuck that. In 'nix the unique identifier are the characters of the file name...period.

    You gotta love how Windows used to limit file names to the 8.3 format when Unix could have almost any file/directory names at all. This included name with spaces, yet they were smart enough to avoid them because their a PIA. Yet as soon as MS supported spaces in names, they decide to put excusables (under their own directories) under "C:My Pretty Little Program Files" because "we can". I'll take ALL the Unix choices any day of the week and this is one of those.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1, Insightful) by Anonymous Coward on Saturday July 20 2019, @03:38AM (1 child)

    by Anonymous Coward on Saturday July 20 2019, @03:38AM (#869272)

    Sure, more simple from a *programming* perspective. That would be fine if only computers used computers, but they don't.

    • (Score: 2) by digitalaudiorock on Saturday July 20 2019, @03:04PM

      by digitalaudiorock (688) on Saturday July 20 2019, @03:04PM (#869386) Journal

      I suppose it's a matter of preference. I'm certainly not a computer and I prefer case sensitivity in a big way, mostly because it just makes more sense to me.

  • (Score: 0) by Anonymous Coward on Saturday July 20 2019, @03:50AM

    by Anonymous Coward on Saturday July 20 2019, @03:50AM (#869275)

    Oh, forgot to add, those arbitrary spaces placed in Windows 95/NT 4 path names helped bang in to applications that they HAD to support spaces in file names. Back then there were a LOT of freshly ported 3.1/NT 3.51, poorly written, 32-bit applications that would die if you tried to open/save a file or path that had a space.

    (Oh, and since you probably can't read it, by HAD I mean had, and LOT I mean lot, but with more emphasis.)

  • (Score: 0) by Anonymous Coward on Saturday July 20 2019, @07:28AM (2 children)

    by Anonymous Coward on Saturday July 20 2019, @07:28AM (#869321)

    UNIX/Linux/BSD had a very different linage than Windows.

    Windows had to work with DOS/CMS style disks. Not 'oh it would be ok if', *had to* as in hard requirement. To be used by people spending money and wanted the software they already paid for to continue to work. Backwards compatibility was a huge deal to windows. They spend a lot of effort and money making it happen.

    UNIX on the other hand takes the approach of re-write it and damned backwards compatibility. API compat was where it was at. That worked because you would buy your computer and the OS that came along with it would be custom for your computer. In many cases you would compile it then install it. Some software you would buy would be the same way.

    DOS had none of that. It had to fit in 640k (usually less). It had to fit on a 360k disk. Upper lower case not happening. To do that compromises were made. The UNIX way only works with a much more rich environment where wasting hundreds of K is no big deal. If you look at the old systems they would bitpack things to save space. These days inventing something new you would have a json descriptor and not worry too much about the wasted space.

    We live today with choices made in the mid 80s to fit things into a borderline embedded computer that did not cost 20,000 just to get in the door with. Remember a computer with a 2MB of RAM and 5MB drive was wildly expensive. Computers would come with 2 floppy drives just so you did not have buy more hard drive or memory. Because floppies were comparatively cheaper than both. Simpler is not always best. Cost maters a lot too. I am sure my 15 year old self would have loved to have a 'technically simple system' and would have lorded that over anyone who did not have it. But my 15 year old selfs parents would have looked at the sticker price and said 'yeah thats not happening ever'.

    Case insensitivity is annoying sometimes. But then again so is case sensitivity. You can look at a file Myfile.txt and MyfIle.txt and miss the case very easy depending on font choice. Insensitivity makes it more usable. But it does come at a cost in both directions. UNIX works the way you think it would work. Windows uses the way people actually use a computer.

    All systems with a bit of age on them have some warts. ls instead of catalog or dir. cp instead of copy spring to mind right away. mv instead of move. That was because of the UNIX lineage of being on a teletype. Where less characters meant you got more done. But came with a cognitive load of having to basically learning random 2 char string phrases to do anything. Remember these were timeshare style systems. Every second counts and the bill is running.

    Understand your systems, where they come from, and you can work those limitations and even know how to bend them to your will.

    I expect soon that windows will have native built in ext4 mounting options and at that point the whole thing is a non issue. You will pick which way you want it.

    • (Score: 2) by digitalaudiorock on Saturday July 20 2019, @03:07PM (1 child)

      by digitalaudiorock (688) on Saturday July 20 2019, @03:07PM (#869388) Journal

      I expect soon that windows will have native built in ext4 mounting options and at that point the whole thing is a non issue. You will pick which way you want it.

      Wow...any citation as to these even being on any road map? Personally, I'll believe that one when I see it. NTFS is a complete piece of shit that should have been replaced by just about anything years ago, but like so much of Windows, I'd say the OS if married to that cluster fuck forever, just like drive letters.

      • (Score: 0) by Anonymous Coward on Saturday July 20 2019, @06:01PM

        by Anonymous Coward on Saturday July 20 2019, @06:01PM (#869432)

        Why would they *not* put it in? They are shipping the linux kernel in the next version https://www.theverge.com/2019/5/6/18534687/microsoft-windows-10-linux-kernel-feature [theverge.com]

        It is not that big of leap of logic that windows users can native mount ext4 and all of the other linux style file systems.

        NTFS should have had many major fixes (and it has). But it is showing its age. It was designed in a time where HD space cost a bit more than it does now. The central MFT is one of the stumbling blocks. Where as the place anywhere inode style OS's seem to be working better. Both come at a cost. For the time NTFS came out it was the best there was for the price.

        The NT driver system is not some special magic sauce that only MS has access to. https://www.paragon-drivers.com/en/lfswin/ [paragon-drivers.com] https://sourceforge.net/projects/ext2fsd/ [sourceforge.net] They have an option here buy/build.

        They will probably want a way to do it such that they do not have to open source windows (yet). Which I suspect they will eventually do anyway. The problem they have is the amount of 3rd party software they bought and plugged into windows. For example their defragment library is a 3rd party program. They will have to either re-negotiate those bits or strip them out if they want that. For example the last line of this https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=5803 [microsoft.com] https://devblogs.microsoft.com/oldnewthing/20181221-00/?p=100535 [microsoft.com] and that is just an ad on game! They are doing some bits where they can https://github.com/microsoft/calculator [github.com]

  • (Score: 2) by toddestan on Sunday July 21 2019, @12:44AM

    by toddestan (4982) on Sunday July 21 2019, @12:44AM (#869485)

    Linux is actually kind of crazy as you can use pretty much any byte you want in the name of a file, except NUL and '/'. Yes, that includes control characters like carriage return and new line.

    I wish I could find it, but I ran across a webpage once where some guy was trying to describe everything you would have to do to properly handle all possible file paths in Linux. I seem to remember he concluded it would be just about impossible, but he reasoned it would probably be okay to just not handle a lot of the edge cases because no one is legitimately going to use file names with new lines in them anyway.