Dear forum,
I experienced kind of strange behaviour. By creating a password with “§” I can only access from winbox, neither form web nor from android app. As soon as I remove § from the password it works like charm. May beacuse § is not part of the inital ASCII table?
Non-ascii characters have multiple diferent encodings and if both parties don’t (actively) agree about which encoding is used, then there are problems. Winbox quite likely (implicitly) uses encoding associated to your windows language settings while webfig (and TikApp) uses some kind of http-encoded UTF-8.
Quite likely you set password via winbox. If you set the password via webfix, that password would likely work via webfig (and TikApp) but not via winbox.
Maybe $ as element of a script language is excluded from acceptable set of chars for passwords?
OP is writing about “paragraph” sign, not about “dollar” sign.
Thanks for the quick answers. It’s not an issue at all, just wanted to give it a post in case somebody else is falling into the same issue. Took me quite a while to get this catched, cause first I’d checked all the other possible reasons for not getting a connection…
@BartozP
It is not the $ sign it’s the paragraph/section sign §
https://en.wikipedia.org/wiki/Section_sign
@mkx
Yes I think that is the reason for the behaviour. Although it is strange cause the sign is an offical unicode sign U+00A7.
As I wrote: there are nany character encodings out there. Nowdays there’s no reason not to use UTF-8 everywhere, but for historical reason many different encodings are used in various places and inter-working is not always smooth. The most frequent problem is assumption that applucation’s “native” encoding is used. One would expect that all software from same vendor (i.e. Mikrotik) will explicitly use single encoding every time even if that meant recoding data being exchanged. But often that’s not the case.