Like elbekko and MadHatter have already explained, the NULL byte is used to terminate strings. Here's some history 
A string, as you might now, is an array of characters. In the ASCII character set, each character is represented by one byte. Each byte has a number between 0 and 255 according to the ASCII table:
As you can see, the character at index zero in the table is called NULL (or NUL, it's the same thing). You can also see that the number zero doesn't represent any particular character. So, if we wanted to store the word "hello" in a string, we would create an array of bytes with the contents:
104,101,108,108,111
But there's a problem with this. If we then want to print that string to the screen, we need to know how many bytes to print. If we don't, we would just continue forever and print whatever appears after this string in the computer's memory. One solution to this problem would be to keep track of how many characters the string contains in a variable in our program. However, that solution isn't very efficient or convenient because then we need an extra variable every time we need to use a string. Instead, we just append the null byte at the end:
104,101,108,108,111,0
Since the number zero doesn't represent any character, we can program our print-to-screen function to continue printing until it encounters the null byte. Most functions that deal with strings work this way. They continue until they encounter the null byte. This is all very convenient, but it has it's own problems. For example, if a program has a string that contains 5 characters followed by the null byte and someone manages to insert a string that is longer than that, we end up with what's called a buffer overrun. But that's a whole different story.
Due to some bugs in PHP, we need to care about null bytes as well. PunBB 1.2.13 contained a patch for a null byte vulnerability that was exploitable by admins only. Here's how it works.
PunBB stores a variable called avatar_path to keep track of where to store avatar images. A malicious administrator (I know, it's almost an oxymoron) can POST a custom form to admin_options.php and set the avatar_path to, for example, "img/avatars/shell.php/%00". %00 is the null byte that has been URL encoded. The administration then uploads an avatar image that has embedded PHP code (for example in the EXIF header). When PunBB receives the file (which it believes to be an image), it will attempt to move the file to the avatar path. The avatar path is img/avatars/shell.php/%00, but due to a bug in PHP, it interprets the null byte as the end of the string which results in the uploaded file being moved to img/avatars/shell.php. We end up with a file called shell.php in the avatars directory that contains PHP code. Not good.
) is the correct way. If you have any other information on this, I would appreciate a look.