Fix #14 by encoding non-alpha characters in attribute keys

[cdhowie]

No description provided.

[cludden]

@cdhowie what's the status on this fix?

[cdhowie]

Status is "should work" but OP of #14 hasn't reported any results using it.

[cludden]

@cdhowie thanks for the follow up. @javatask can you confirm this fixes your issue so we can get this merged. We too have this issue and would like to see it merged as soon as possible.

[cdhowie]

This was fixed incorrectly by 7222db6. I am rebasing my patch against v7.1.0 and replacing the changes introduced by this commit.

[cludden]

@cdhowie will you be updating this PR with your changes?

[cdhowie]

@cludden I plan to but have not had time lately to work on it, and the issue doesn't affect us so it's not a priority ATM.

[C45tr0]

What was wrong with the 7222db6 change? Just wondering if it is preference or a situation that is not being handled.

This change looks to be doing the same thing, except it is replacing the characters with a 4 digit equivalent where the 7222db6 is just removing them.

Also, this change looks like it would break expression document paths.

[cdhowie]

@C45tr0 The problem arises when you strip out special characters, leaving two attributes with the same cleaned key. Encoding each non-ASCII character as a number prevents this, as every possible attribute key is guaranteed a distinct representation as a cleaned key.

For example, consider the keys abcd and abcdé. If you just strip non-ASCII characters, these two attribute keys have the same cleaned representation (abcd).

[C45tr0]

@cdhowie Fair point. I took the liberty to make these changes after the Document paths changes. I will be submitting a PR with that shortly.

[cdhowie]

Superseded by #115.