I don't know if this is a bug or missing feature. As the decoding currently works, if there are any character with character-code above 128, mIRC falls back on displaying the whole line as non-unicode.

This has as a consequence that if the user uses some character with value above 128 in the timestamp he can't show unicode at all. If he instead encodes those characters as UTF-8, they will display as junk if he recieves a message which contains characters above 128.

If the decoding instead is done on a per-character basis, the user could much more easily mix unicode-character with non-unicode ones (128-255). If mIRC would encounter a character above 128, that is not part of a utf-character sequence, it could instead of reverting to non-unicode on the while line, just render that single character as non-unicode.

For example, without utf-8 timestamp:
«12:34:56» {Dennie} utf-8: åäö
«12:34:59» {Dennie} non-utf: åäö

With utf-8 timestamp:
«12:35:34» {Dennie} utf-8: åäö
«12:35:37» {Dennie} non-utf: åäö

One problem with this new approach would be if someone accidently sends a utf-sequence without utf-encoding enabled it will be displayed as a unicode-character. But this problem also exists in the current version.

Last edited by MizardX; 23/03/08 03:21 PM.