You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The original issue that StripNick aimed to fix is incorrect interpretation as rich text markup. This usually involves Markdown, BBCode and autolinking. A wide range of characters could still be considered safe in most contexts. Underscores are a bit trickier to handle but would also come in handy.
If the nick contains accented characters, spaces (or for example is all lower case and only underscores or dots delimit the name parts) the current result of concatenation will become unreadable.
It would be a simple, but effective improvement to insert a placeholder character in place of every group removed. Using an underscore or hyphen is a popular choice.
An alternative would be to preserve the full information contained within the nick using a bidirectional mapping. A common choice is to escape problematic characters via either the percentile or the equals sign and 2 hex digits per input byte for this. IDN punycode would be another alternative, but it's both more complicated to implement and I personally wouldn't prefer that.
Just as a reference, here is the original regexp implementation:
The original issue that StripNick aimed to fix is incorrect interpretation as rich text markup. This usually involves Markdown, BBCode and autolinking. A wide range of characters could still be considered safe in most contexts. Underscores are a bit trickier to handle but would also come in handy.
If the nick contains accented characters, spaces (or for example is all lower case and only underscores or dots delimit the name parts) the current result of concatenation will become unreadable.
It would be a simple, but effective improvement to insert a placeholder character in place of every group removed. Using an underscore or hyphen is a popular choice.
An alternative would be to preserve the full information contained within the nick using a bidirectional mapping. A common choice is to escape problematic characters via either the percentile or the equals sign and 2 hex digits per input byte for this. IDN punycode would be another alternative, but it's both more complicated to implement and I personally wouldn't prefer that.
Just as a reference, here is the original regexp implementation:
matterbridge/gateway/gateway.go
Line 327 in 4ab72ac
Documented here:
The text was updated successfully, but these errors were encountered: