[Quote from: https://forums.mirc.com/ubbthreads.php?ubb=showflat&Number=223676&page=1#Post223676]:
As some of you may have noticed, the new version of mIRC no longer supports codepages. This is because mIRC is now a Unicode application and will only send and receive UTF-8 encoded text. Ideally, the aim is to make IRC as a whole non-reliant on codepages, so that everyone will be able to view all characters in all languages.
In older versions of mIRC, every user had to manually configure each of their status/channel/query windows with a specific font and codepage to display one particular language, and this only worked for that language. If someone new joined the channel, or someone joined that channel and spoke a different language, text would appear as garbage to them and to others. The use of UTF-8 means that none of that is necessary any more. Everyone on IRC will be able to read everyone else's text, regardless of language, without any fiddling or configuring of codepages.
The issue with codepages is most obvious in the channels list window. The channels list window lists thousands of channel names and topics, many of which use codepage-specific encodings. However the window can only display text using one codepage. This means that channel names or topics not using that codepage will be displayed as garbage. The same issue applies to all channel and query windows where users chat in multiple languages.
While it may seem that mIRC v6.35 handles codepages correctly, there are a large number of situations where it cannot do so due to a lack of context, just like in the channels list window, and many users have reported issues, such as corrupted text and incorrect encodings, over the years. It would not be possible to add codepage support to mIRC v7.1 without leading to the same issues that were present in all previous versions of mIRC.
Some IRC clients support "hybrid" encodings that combine both UTF-8 and a specific codepage. Unfortunately if mIRC had done that it would have created even more confusion since the result would not have been valid UTF-8 and the codepage issues would have continued.
During the development of the Unicode version of mIRC, the choice was either to continue to support codepages, along with all the encoding issues that come with them that affect all users, and to perpetuate these problems for many years to come, or to try to resolve the issue once and for all, for IRC as a whole, by moving fully to UTF-8.
I realize this is going to be an issue for some users - there are many networks/servers/channels that use codepage-specific encodings. I am hoping that the benefit of UTF-8, which has been supported by mIRC since 2006, will be enough of an incentive to convince users to move away from codepages.
Dear Khaled,
I'm not trying to sound rude, but I think it is important to understand two things:
1. Clients are supposed to conform with servers, and not the other way around.
2. mIRC is very popular without doubt, but it is not the only client there is.
I really welcome your step, but unfortunately it came too early.
Before mentioning future development and progress of the rest of IRC world, let me please remind the current situation.
About servers:IRCds don't have (and probably will never have) UTF support for nicknames and channel names, or config directives.
Let's take a case of a user with mIRC 7.*, that connects to some local country server that allows nicks in the local charset, for example Greek or Turkish.
This user won't be able to enter this kind of nick, although other will, since IRCds support only codepages in nicks. He just will be forced to use an English nick.
Same thing with channels, if there're already existing channels created by others, he just won't be able to join them.
Bottom line: IRC commands should be sent in codepages.
About clients:Latest mIRC is whole Unicode, other clients still have also codepages support.
It will take a lot of time and work for developers of other clients to catch up with mIRC, and for meanwhile, communities should force all of other client users to switch to UTF, if they want mIRC users to be part of the conversation.
More than that, there're still considerable clients which don't have UTF support at all. That mainly includes bots (PHP\perl\etc.), browser-based clients (PJIRC, flash clients) or built-in client windows inside other applications (like SMIRC in eMule).
So even if we demand from users to switch to Unicode, some of them just won't be able, and obviously, no one can force the whole world to use mIRC.
Please, consider seriously the return of codepages support as an option in mIRC, along with Unicode support.
Each channel, community or network, will choose to how conduct themselves with character encoding, preferred language, and client recommendation for their users.I truly assume that many mIRC users, including me, and of course server admins, will thank you and appreciate it.
As I said above, I believe that your idea is important, but Kahled, please let the free choice to decide for meanwhile.
Thanks a lot in advance,
Meir.
