Viewers: in countries Watching now:
Learn how to find and manipulate text quickly and easily using regular expressions. Author Kevin Skoglund covers the basic syntax of regular expressions, shows how to create flexible matching patterns, and demonstrates how the regular expression engine parses text to find matches. The course also covers referring back to previous matches with backreferences and creating complex matching patterns with lookaround assertions, and explores the most common applications of regular expressions.
In this movie, let's take a look at how to write a regular expression that would match URLs. To begin with, let's get an idea of what kind of sample data we are working with. What can a URL be? Remember in the introductory movie to this chapter, I told you that that's the best first step, is to really get an idea of what you want to match. So some good sample URLs; a very basic one, of course, would just be http://www.nowhere.com. The http portion is referred to as the protocol. The www is known as a subdomain, and then the nowhere.com is known as the domain.
It's also valid to have a URL that doesn't have a subdomain; just to omit the www, dot. And it's also valid to have a different subdomain, like blog.nowhere.com. You can also have a different protocol. In addition to http, there is https, and that's the secure http protocol. You would use that with sites that use credit cards, or bank transactions; things like that. Now, all of these get us to the right server, but then once we are on the server, of course, we are going to start surfing around, and we are going to start hitting different pages. So the URL can also have the page information after it.
So, product_page.html. And, of course, those can be nested inside other folders, and the file endings might also include things like images. It's entirely possible that you would just have a URL that doesn't have an actual file ending. You might know that that would either use index.html by default, or a Web application might use it to do something else more complex. You can also append numbers in there, or you can use a query string at the end. So for example, product_page.php?; the question mark indicates that you've got a query string at the end, and then product=28.
That query string can contain a lot of different stuff. It can contain ampersands if we have more than one, it can contain square brackets, and percent signs. There are all sorts of characters that are allowed to be in there. You will also notice in this last example that we don't even have that trailing slash after .com anymore. Now it just goes straight to the query string: .com? So we won't want to take that trailing slash for granted. It's not always there. And in fact, we can actually use an anchor as well, which would be the hash or pound sign, and that would tell it what part of the page we wanted to go to after it got there.
Okay, so now that we have this sample data, I think we are ready to start thinking about how we want to match this. And I am looking at it; I am seeing several different parts. I am seeing that there's really the protocol portion, and that always comes before the ://. Then there is the domain portion, which may or may not include a subdomain. And then, once we get to the right server, there is the instructions for that server, and that can made up of a page, and a query string, just a page, just a query string, or something else, like an anchor. Let's try writing it by focusing on those three blocks: the protocol, the domain, and the location and query string portion.
To start with the domain, we know that we want to use an anchor tag at the beginning, and we want to use multi-line anchors, because we are actually checking many of these at one time. So let's go ahead and just start with our first one, and let's match the beginning of the line against http://. So that works; that gets most of our cases. It doesn't allow for the special case where we have the secure connection, though. A couple of ways we can do this. We can either put S, and then question mark for making it optional. Now that matches. Or, a lot of people prefer to do it this way instead; to do open parentheses, http, and then make it an option.
Depending on the context, you could, of course, make this whole protocol portion optional, because you can have a valid URL that's just nowhere.com, and that would just assume that the protocol was http://. But again, that depends on your context. If you wanted it optional, you know how you could turn it to an optional group. Now let's move on to the domain portion, which may or may not have a subdomain. The domain is very similar to what we saw with the e-mail addresses. So we could go ahead and use the same regular expression that we used to match the domain there. And if you want to refer back there, you'll remember how we talked about how this isn't specific to make sure that the domain actually exists.
But in this case, I think it's okay, because you know what? We don't actually know that the page exists after that anyway. A URL isn't necessarily valid until you test it, and see whether it actually exists. So I don't see it as a big problem if we don't know if the domain is valid, because we have no way of knowing if the URL is actually valid. So in this case, I think that the broader version is going to be better. But there is a problem here. While this does allow for domains and subdomains just fine, there is also another case that we haven't considered, which is where we could use an IP address. So one of the edge cases might be that we have 255.255.255.255.
Now, we will talk more about how to match IP addresses in a moment, but for now, I just want to make sure that we allow for something that will at least accommodate this basic usage of an IP address. One way that we can do that is to modify our regular expression so that we say, instead of this having to be letters here, this allows for numbers already, with the w for word character. So instead of restricting this last portion to being only letters, uppercase and lowercase, we need it to be numbers as well. So in order to do that, I am just going to change this back to being the backslash, W.
That now allows for that IP address. I am going to go ahead and remove this restriction as well, and just make it a simple plus. And then I could actually put this whole thing in parentheses, and say that there may be portions that repeat there. So what I'm saying is, there's some portion, and then after that there's a dot, and some more, and then a dot, and some more, and a dot, and some more, and a dot, and some more. I am not caring what those things are; they are just word characters. We also should allow this to be a hyphen inside here. Let's do that; there we go. So now we are matching all possibilities where we just have something, followed by a dot, followed by something, followed by a dot, followed by something, and so on.
And I won't try and get more specific. Again, if you want to, you can refer back to the movie about matching e-mails, or the upcoming movie about matching IP addresses. So now what about the page and query string portion? Well, the simplest approach is just to say there can be any character, using the wildcard, then zero more times, and then the end of the string, and that will match anything. And that's because there are so many possibilities for what could be there, and we don't want to try and rule them all out. So there could be semicolons, there could be question marks; there are all sorts of possibilities. Now, if you wanted to, you could be more specific, and you could say, alright, you know what? That first character that goes right here, separating it; that needs to be either a forward slash, a pound sign, or a question mark, and you can limit it to just those.
Of course, we need to make that optional. But once we've done that, I mean, we've made an optional group that says that it's one of those characters, but then right after that, we've got a wildcard. So if it doesn't match one of those characters, it's meaningless, because it will just say, okay, I guess it wasn't there, and the wildcard will still match everything. So the only way this becomes meaningful is if we start making the wildcard more specific. And anything we put here in the wildcard; it's probably going to include those characters anyway. So, I don't think it's actually that meaningful to try and figure out what that dividing character might be.
We can tighten up this wildcard just a little bit by putting in some of the most common characters that you would see in there, and then you could add to it if you think of more. For example, I notice that the semicolon is not in there. We can add in a semicolon as well. Then, of course, that character set needs to be repeated to be able to match everything. So this is the broadest possible match, and then you can tighten it up to fit your individual needs. The very last thing that I recommend you do when you are working with these regular expressions is look for groups that are being captured. If you're not using capturing, then turn them into non-capturing groups, like this. This group is a non-capturing group, and there we go. Those are the two, and now those are non-capturing groups, so we've made our regular expression a little more efficient.
There are currently no FAQs about Using Regular Expressions.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.