In the previous implementation, both AttributeType and AttributeValue only supported values in the range 0-9 a-z A-Z, which was not enough, in fact its value could be almost any character that does not involve a filter operator, which also contains parts of non-ASCII characters, such as CJK and Cyrillic, etc. (they can all be represented in Unicode which occupies 3byte space, so using HEX can represent them, like \xx\xx\xx), this PR changes the status quo and starts matching from the characters, it supports those characters themselves and their HEX forms. This PR does not substantially modify the original filter test cases and uses test-driven development on the new features; these changes are fully backward compatible.
BTW, it has not been added yet for testing in real search case, because we cannot currently send some special requests to change the data in OpenLDAP, next I will implement and export a special operation function on the client called _unknown, which allows the user to send a HEX-encoded data body directly without understanding the essence of the protocol, it will be used for testing, such as modifying an item to add a new attribute. At the moment we can't implement it because _send_receive is not exported (and it shouldn't be). A test with Chinese values passed locally, so I think this PR modification is working fine.
In the previous implementation, both AttributeType and AttributeValue only supported values in the range
0-9 a-z A-Z, which was not enough, in fact its value could be almost any character that does not involve a filter operator, which also contains parts of non-ASCII characters, such as CJK and Cyrillic, etc. (they can all be represented in Unicode which occupies 3byte space, so using HEX can represent them, like\xx\xx\xx), this PR changes the status quo and starts matching from the characters, it supports those characters themselves and their HEX forms. This PR does not substantially modify the original filter test cases and uses test-driven development on the new features; these changes are fully backward compatible.BTW, it has not been added yet for testing in real search case, because we cannot currently send some special requests to change the data in OpenLDAP, next I will implement and export a special operation function on the client called
_unknown, which allows the user to send a HEX-encoded data body directly without understanding the essence of the protocol, it will be used for testing, such as modifying an item to add a new attribute. At the moment we can't implement it because_send_receiveis not exported (and it shouldn't be). A test with Chinese values passed locally, so I think this PR modification is working fine.Update: test cases here: https://github.com/api7/lua-resty-ldap/pull/9