Parsing "Microsoft encoding" is very lenient

[Carrotman42]

I was reading through the code for Parse and I noticed that there is no validation on the first and last characters of the uuid-to-parse when the length of the input is 38 characters:

https://github.com/google/uuid/blob/16ca3eab7d2086fd5a82993a291cbf3b87fe38b7/uuid.go#L38-L61

I would expect there to be a check that s[0] == '{' && s[37] == '}' rather than simply ignoring those two characters. I am happy to send a PR if requested, it's a simple change. I am just verifying that this loose behavior is not actually desired.

(fwiw, it means that parsing something like a01234567-abcd-cdef-abcd-012345678901a would be parsed without an error, even though it has extra characters at the beginning and end. That's quite unexpected IMO.)

[pborman]

Thank you for pointing this out. Yes, this is a bug and should be fixed. Would be happy to have you send in a PR for this.

[sazzer]

I've just come across this by virtue of the fact that:

• "921ef402-cd4c-4be6-8483-a00566a43f60" -> Correctly succeeds
• " 921ef402-cd4c-4be6-8483-a00566a43f60" -> Correctly fails to parse
• "921ef402-cd4c-4be6-8483-a00566a43f60 " -> Correctly fails to parse
• " 921ef402-cd4c-4be6-8483-a00566a43f60 " -> Unexpectedly succeeds!

Turns out it's not that it ignores whitespace if present at both ends, but it's just another version of this bug.