Handle NUL-terminated ASCII strings. #40
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi @remvee
I admit I have no real idea of what I'm doing here as I did not read any EXIF specs or anything so far. Just came across a few JPEG files created by the GoPro HD2 where the
make
,model
, andsoftware
tags returned some garbage after the actual value (as returned by other exif readers / exiv2). I assume GoPro is using the remaining bytes internally somehow since it does not look like a valid string in any encoding to me, and also not like encoding information.The easy fix is to strip the strings after the
NUL
terminator, sounpack('Z*')
. The change feels a bit dangerous, but all tests still pass and who am I to say this. Happy to come up with a "proper" solution if you point me to in the right direction.Malte