Source Encoding Example neglects messages with leading/trailing zeroes

[sworthiness]

I'm unsure if this is intentional or not. The supporting text does not mention what is supposed to happen to zeroes.

Assuming the purpose of the source encoding is to just replace strings of 1s with a number representing the length of said strings, then the zero preceding the string is erroneously removed from the encoded message (in reality that zero's position is used for the string length value). As a result, a binary message starting "01101110..." and a binary message starting "1101110..." both encode to decimal message "2,3,...".

Given that source encoding is meant to be a unique mapping from one domain to another, the example code gives rise to a non-unique mapping, where by "2,3" is not uniquely decode-able back to the original binary message.

I would have assumed that the zeroes have to be left well alone(?) and therefore the above messages should encode to "0, 2, 0, 3,..." and "2, 0, 3, 0,..." respectively.
If that assumption is correct, then adding:

if (enc_msg1(end) == 0)
     enc_msg1 = [enc_msg1 0];
endif

between lines 81 and 82, and 90 and 91 should resolve the issue; preserving all zeroes in the encoded message EDIT: remembering to ammend the variables numbers accordingly....

Example code is Code 4.2, in file chapter4.m