As to your update, your standard cryptographic hash functions (MD5, SHA-1, SHA-2 family, SHA-3) try to approximate random oracles (and do not attempt to be injective). That is they attempt to map any input to an output chosen uniformly at random in your output space (and do this mapping consistently). With overwhelming probability, random oracles will not be injective when the number of possible inputs is significantly larger than the square root of the number of possible outputs, due to the birthday paradox.
For example, if you have a 128-bit hash output (a 16-byte hash with 2128 possible outputs) and use a random oracle to hash significantly more than sqrt(2128) = 264 inputs, it begins to become overwhelmingly probable that there will be collisions. On the other hand, if you hash significantly fewer than 264 inputs, it will be very unlikely to have a collision if you started with an ideal random oracle. (If you hash around 264 inputs than the chance of being injective is approximately 1/2; there may be a collision or not).
As a specific example, if you hash all 272 possible 9-byte inputs the probability of a random oracle being injective onto a 16-byte space is about exp(-n2/2m) ≈ 10-14231, where n = 272 ≈ 4.7 x 1021 and m = 2128 ≈ 3.4 x 1038. This is incredibly unlikely; roughly equivalent to playing powerball (odds of winning 1 in 292 million) twice a week for 16 years and winning the jackpot each and every time with no losing tickets. And again, this is only for a 9-byte input; with a 15-byte input the probability of being injective is about 10-1127492937032632506267955467381579!
Meanwhile, if you hash all possible 7-byte inputs, there's only 256 of them so with large probability there will be no collisions (that is it will be injective). As this is significantly less than sqrt(2128), a random oracle would not be injective with probability with odds of 0.0000076 (about 1 in 130 000 times it would not be injective and the rest of the time it would be injective).
See the probability table on wikipedia for more information.
Granted this is not a proof for any specific hash function; to prove it we would have to generate a specific collision within the input space which would in general is difficult to show.
Now if you need an injective function that acts similar to a hash, this is quite simple to achieve by using a block cipher (formally known as a pseudorandom permutation) like AES and choose a random key to encrypt it with. Block ciphers are necessarily both injective and surjective. If a block cipher was not injective, then a person with the key and the decryption function and a block of ciphertext to decrypt with couldn't possibly recover the original block.
The downside of using a block cipher instead of a hash function is that the block cipher requires input of just one fixed length and transforms it into output of the same fixed length. For example, AES can only take a input that is 128-bit and transform it into a 128-bit output. (Yes you could use block cipher modes to transform larger inputs, but still for it to be one-to-one the output size would be the same length as the input). The fact that a hash function can take variable sized inputs and output a fixed size hash makes it ideal for many purposes. The fact that this requirement of hashes to map variable sized inputs taken from a very large input space into a smaller output space means that it will not be a injective by the pigeonhole principle is usually not a problem in practice.