By applying this pull request the above mentioned characters should get correctly decoded.
The current array entries were probably adopted from the Java version of this library, where one may specify characters by their octal code points using a "\[0-9]" notation. Thus, e.g., "\13" in Java equals, e.g., String.fromCharCode(0o13) or '\x0b' in JavaScript.
Thanks a lot for reviewing and maybe merging this pull request.
As described in #607 decoding Aztec codes in some cases gives wrong results, i.e.,
'\x01'
/'\x02'
/'\x03'
/'\x04'
/'\x05'
/'\x06'
/'\x07'
/'\x0b'
/'\x1b'
/'\x1c'
/'\x1d'
/'\x1e'
/'\x1f'
/'\x7f'
get decoded to'\\1'
/'\\2'
/'\\3'
/'\\4'
/'\\5'
/'\\6'
/'\\7'
/'\\13'
/'\\33'
/'\\34'
/'\\35'
/'\\36'
/'\\37'
/'\\177'
.By applying this pull request the above mentioned characters should get correctly decoded.
The current array entries were probably adopted from the Java version of this library, where one may specify characters by their octal code points using a
"\[0-9]"
notation. Thus, e.g.,"\13"
in Java equals, e.g.,String.fromCharCode(0o13)
or'\x0b'
in JavaScript.Thanks a lot for reviewing and maybe merging this pull request.