Forums Bug Reports mIRC 7.1 bug

i am french ^^

#infométéo (1 pseudo) mIRC 7.1 #infométéo

#infométéo (10 pseudo) mIRC 6.xx #infométéo

non bug é = é

bonne journée

[X] BUG F12 inviter => #xxxxx <= mIRC 7.1

é = é

Please see this thread. Any channels or servers that use only code page support and not UTF8 support will have issues until they start supporting UTF8. You will have to stick to 6.35 until support for UTF8 is added to those channels and/or servers. The main reason to upgrade to mIRC 7.1 is for unicode support and if you aren't going to use it, there's not much reason to upgrade anyhow.

Hi,

I would call the font-handling in mirc 7 a very big bug, too. I never thought that mirc would leave the beta status without handling code-pages in existing irc-networks correctly.

In european irc networks we use many channels that uses language specific characters. What mirc now does is receiving channel-names containing fonts like é or ö by the ircd, but it sends out this fonts coded in uft-8.

That could result in many problems and I am not sure if this is a security issue - sending out messages to wrong channels or nicknames.

In my opinion this is a very big mistake. Migrating to utf-8 should be the part of the ircd's, but not of a client. The client has to handle every input in a consistent way.

Think about a webbrowser that can only handle utf-8 and nothing else. Noone would use it!

That's the same what we can answer in our support-channels - do not use mirc 7.1 at the moment, there is no way to join channels that exists since 10yrs.

Khaled has been pretty specific that he is not going to support code pages any longer and that mIRC will be entirely unicode. Whether he adds an option to send text without encoding it, that's another issue. He might allow something like that which would make it easy to script your own code page support. In any event, unicode has been around for at least a decade. There is really no reason why people haven't made the effort to support it at this point, imo. Especially considering it gives you a *single* encoding that works for everyone in the world without needing to change code pages over and over to talk to different people in different channels on different networks... etc. Why wouldn't people want to go that route? Yes, it takes work, but Khaled pulled it off. Others can as well.

Hi Riamus2,

the problem is, that the users do not understand what happend! User (a) using 6.xx invites a user (b) using 7.xx into a channel and he joins a complete different. That's weird.

Using svsjoin (with a 6.xx-client) I can join myself using a 7.xx-client into a "codepage-channel". So I receive every privmsg, but are unable to answer.

Tha same thing happend with users who use a join-list with nickserv.

You see, mirc 7.xx is completly inconsistent. No normal user understands what happend. Thats the problem

problem mIRC 7.1


mIRC 6.35 => mIRC 7.1

http://a.imageshack.us/img576/5302/mirc2.png

----------------------------

mIRC 7.1 => mIRC 6.35

http://a.imageshack.us/img576/1227/mirc3.png

http://fr.wikipedia.org/wiki/UTF-8

http://fr.wikipedia.org/wiki/ISO_8859-15

firefox 3.6.8 version => UTF-8

UTF-8 => é

iso-8859-15 => é

very big !

windows vista SP2

This looks correct. mIRC v7.1 is displaying the Unicode representation of all of the characters. mIRC v6.35 could not do that because it was not a Unicode application.

This is one of the reasons why mIRC was converted to Unicode, so that the interface would correctly display characters from all languages, instead of displaying the literal UTF-8 encoded text, which is unreadable.

All text in mIRC is now stored as Unicode and is converted to UTF-8 when it is sent to the server. Likewise, when mIRC receives UTF-8 text from the server, it is converted to Unicode.

Hi,

ok, reading this and some other threads I can summerize:

1. mIRC v7.xx is unusable if the user is oper or admin in a network. Thats why the user has no chance to handle other users or attacts that uses channel-names containing codepage-characters. In this scenario I assume that nicknames must not containing other characters than the allowed ascii-characters.

It would work if mirc does not converts incoming channels to utf8.

2. mirc v7.xx is unusable for normal users. Using nickserv's autojoin-feature it is possible to have a situation like

TC on #ÖSF @#ÖSF (mIRC 6.35)
TC on #&#1363;F @#ÖSF (mIRC 7.1 ) (the special char seems to have the code 0x553)

Now I close the #ÖSF-Channel in v7 using the [x] button. In the channel-list no #ÖSF is listed, but in the whois I see

TC on #ÖSF

So I have joined a channel but mirc does not show me - this is evil.

mIRC v7.xx has no chance to handle this correctly, no user without knowlege of character encoding has a chance to understand what happens.

Using mirc 7 I (in my position of a netadmin) have no chance to leave this channel, there is no way to use svspart, kick, nothing.

Khaled, do not misunderstand me. I am a friend of going forward, so utf-8 / unicode is the right way. But today it is out of the question to use a client that can handle only utf-8.

Agreed totaly. thats evil i cant even join my room lol thought it was dropped blah!
Well i rather back to older mirc or use another client but this is kinda annoys me ermm
Hope things will be sorted.

Hi xyzzy,

the most users who chat only in their few channels have no problem with mirc 7, because the parser understands privmsgs sent in iso-charset. So the user can read the normal special characters like é or ü.

But opers or admins like me must have the possibility to join every channel existing in their networks. We are not in the position to ban users that cannot use unicode.

But if they use clients with iso-charset, we cannot use mirc 7 that acts completly inconsistent with existing servers.

This is why mIRC has basic support for accessing these channels with /raw -n

As much as you'd probably like to see codepage support, you probably won't see it in 7.x and onwards. mIRC will get better at allowing scripters to implement their own codepage support, though-- /raw -n is the first step in this process.

have a problem with CYRILLIC support not read how to fix ?
and where is this speech support and how to use ?
and maybe in next version add video support ?
it`s time to evolution for mIRC with include audio and video support for astrix servers and other methods p2p or other
Thank You

On my keyboard is also Ä Ö Ü keep the 6.35. I am German and the ä ö ü are in our standard. Please I let it be takes ö me in again æ ü or wait until 4.X outside is unreal because man Yes can (...) scheme change the 7.1 unacceptable is me. My provider has yet self not moving to ipv6.

Sorry fpr my language

You do realize that Unicode does not mean international characters stop working, right?

In fact, the reason mIRC adopted unicode was for the exact opposite reason-- to improve support for multiple languages. Ä Ö Ü æ, and all characters continue to work in 7.x. The only difference is that when you type them, they are sent as UTF-8, pretty much a worldwide standard encoding to represent your text. 6.35 can display Unicode, so they should be able to see what you wrote (though it might require enable UTF-8 support).

If you tell your friends to also enable UTF-8 messaging, you will see what they are writing too.

Cyrillic still works. As for the other questions, this topic is not the right place to get help, try the mIRC Help forum for questions about new features.

This won't work. Since I have around of 10 different script that are programmed not to interfer each other, I have to change every of this script. And I think it would be the same with other users.

You are correct if you say, we can use raw -n to send iso-characters. But and event in any script must be catched and translated to own script that uses iso-characters. And in situations without user-interaction (i.e. the autojoin-list in many nickserv-implementations), I have no chance to detect the charset.

The only way to solve this would be a kind of low-level-events that cannot be overridden and used to translate between the charsets. But this translation should be the part of the client, not of any user-script.

As I said before, if it is possible to create an inconsistent state, the client has an error - not the user or the server. Nettalk for example hides any iso-channels when I enables utf-8-support. That's not what I excpect, but it's better than an inconsistent state and - that's the point - I have the choice to enable or disable it.

The fact that you will need to update your scripts does not mean "it will not work". Updating scripts to work with 7.1 was entirely expected and documented during the betas. I don't see having to update your scripts as a blocker in itself.



We're not talking about full compatibility for chatting purposes. Your concern was that an admin was unable to properly manage a server. /raw -n allows you to send commands to manage a server. As I already mentioned, improved scriptability will likely come in future versions, but this is a fine start.



I'm not too sure what you mean by this, or why this is the only solution. This also is starting to sound more like a feature suggestion than a bug report.



Define inconsistent state. I don't see mIRC introducing inconsistent state here. There is an inconsistency in the way mIRC data from the server, but the state itself is fine. mIRC joins a utf-8 encoded channel-- the problem is that it joins the wrong channel, not that the state is inconsistent. If you'd like, mIRC could hide these channels, but this is beside the OP's point. The issue is about getting mIRC to communicate with the ANSI-encoded channel, not about whether the channel should be listed.

Assume a user that has the channel #test_ä in his autojoin list in nickserv since one year. When he identified itself, nickserv uses a svsjoin to let the user join its channel #test_ä with an iso charset. The user has now a channel-window open and sees the other users in the channel.

But since mirc 7 sends only utf-8 charset, this user cannot

- send privmsgs to the channel
- cannot part the channel (the window closed, but since mirc sends a part #test_ä (utf-8), the user is still joined)
- cannot whois users in this channel if chmode +s is used

I would call this an inconsistent state. You can simulate this by /raw -n join #test_ä.

We have many users that asks us in the support-channels what has happend, because they do not understand they just updated a client. Using the autoupdate of mirc, the user has no warning. Thats a serious problem in my opinion.

Thanks for your comments mths.

I think it would probably make sense for mIRC to hide ISO channels in /list. It may even make sense to /part an auto-joined ISO channel and automatically /join the UTF-8 version. That would migrate many users to UTF-8 automatically.

As you know, my main hope is that this change will lead to a gradual change to UTF-8. I realize it will be frustrating initially but there does not seem to be another option - codepages will continue to be used, with all of their limitations and issues, without this change.

Regarding administrators: the only way to resolve this would be to add a UTF-8 enable/disable option. It is not quite that simple however - UTF-8 handling is embedded in a number of routines, such as file input/output, so it would have to be disabled in many places.

What? mIRC is not the one and only client, we have many users that uses other os' and other clients. Migrating an existing channel to utf8 means that all users have to do it. All webbased clients have to be updated, all java-clients. That's not easy for a normal user without experience in that.

I'd like a workaround like this. It's only an idea, maybe it could work:

if mIRC detects a source or destination that contains iso-characters this channel (or nickname maybe) must be enclosed with a special character that survives the translation to utf8 and back. Let it be ctrl-i (#29) for example.

Then you have only to change the part that receives the input and the part that send it to the server. Using ctrl-i had a nice side effect: it was displayed italic so the user could differ from utf8-names.

Any workaround will ultimately be a hack.

Ideally mIRC should NOT be encoding the TARGET portion of any IRC command, as this violates the IRC protocol (a target is a unique 8bit encoded space and comma delimited identifier and must be represented exactly in its original form). Of course, it's fairly difficult to differentiate what part of a command is a target and how it should be re-encoded given that the destination encoding is unknown unless the specific target was listed by the server. Basic joining/parting and messaging might work (because mIRC knows the original target's bytestring), but scripts would still not work. For instance, "/msg # hello" could not work because the # result will be encoded as utf-8 in the script. There's no real way to support this unless by re-adding codepage support, or a much more complex/comprehensive encoding layer, which Khaled has stated is extremely unlikely to happen. Without script support, the basic functionality isn't really worth supporting. Many users will still complain that "my script does not work in #CHANNELNAME", and the problem will continue to persist until they're on a utf-8 channel, so this isn't exactly a solution. All that work in supporting codepaged channels just to tell users to use utf-8 to get a proper IRC experience anyway? Doesn't seem worth it to me.

A much better long-term strategy is indeed to migrate people over to UTF-8, which is why, although subversive and sneaky, I think this might be a good idea. Khaled outlined this strategy in this post, and you should probably read it to understand where he stands on this issue. Most clients are already using utf-8 anyway, so mIRC is not really alone. I'd bet that a good 80% of the users in these codepaged channels are on some version of mIRC, so this is actually not an issue of there being other clients out there to deal with, but rather the fact that most other client already handle UTF-8 and mIRC 6.x was lagging behind. And indeed, the results on Undernet support this:



Frankly, servers can do a lot to help people in this process by redirecting them to utf-8, but server implementors tend to be uninterested in moving this process along. In fact, you can read the beta threads regarding unicode to find an exchange between a server implementor about how "encoding support" is meant to be the client's responsibility, not the server's. Note that this goes against your previous post that "encoding should be handled by the server", and therein lies the vicious cycle. Server developers think it's the client's responsibility, client developers think it's the server's responsibility. mIRC is taking the step in trying to settle the dispute once and for all by sticking to a specific implementation.

This is a bigger issue than it appears to be. Especially for languages with which an ANSI encoding has always been enough. Right now, I'm sure that at least one popular channel is having trouble with this in Undernet, where channel registration is not taken lightly.

In any case, at least Khaled is trying to take a step forward by adding full UTF-8 support, however, I'm not sure that it's a good idea to make mIRC so that it can no longer interact with ANSI-coded channels within an instance of an IRC server. I agree with mths: this can be a security issue. I hope Khaled can come up with a convenient solution for this.

What I'm sure about is that this is a bigger issue than many people think, and this transition is going to be very bothersome. Right now, I rather stick with 6.35, disabling and enabling UTF-8 display and encoding as I see fit.

I think you're making it into a bigger issue than it is. I've just been doing surveys of networks like Undernet and QuakeNet, and I'm seeing maybe 5% of the registered channels with UTF-8 incompatible channel names. It might be a really big deal to those 5%, and I completely understand why and sympathize, but those users can always stick to 6.35 if they need this support. The other 90+% of users will greatly benefit from UTF-8.

The security side of this is relatively bogus. Besides EFNet, there are really no networks without services support. More importantly, opers aren't drones. If a user registers a the unicode equivalent channel name of an existing codepage channel in order to gain control of a channel, an oper can quickly out whether the use is legitimate or not and decide whether to revoke the registration.

I dont know if that sounds like a good idea, this means alot of people need to rewrite/update there servers, and they need to do it for 1 program people use to chat with, it's many others out there, and i for one belive this will force many users to stick with a outdated program. (mirc v6.x)

And as argv0 said, "QuakeNet, and I'm seeing maybe 5% of the registered channels with UTF-8 incompatible channel names.", i using åäö in my language, and many channels im in using some of the letters, and QuakeNet is only one network. Think of all the other networks to, there you find many more channels and users joining channels with UTF-8 incompatible channel names.

Just as a note on those channels, the ops can easily join the UTF8 version of those channels and slowly work to move people to the UTF8 version of the channel. This would really be a good idea even if mIRC adds some easy way to continue using the non-UTF8 channels. It would be easy to set up the UTF8 channel and then ask people to move over there. The ops can then leave a "bot" in the channel that will tell anyone who joins the non-UTF8 channel to use the UTF8 channel instead and could even /invite the user to the correct channel. Eventually, more clients are likely to start using unicode and you'll start running into more problems with users unable to access the non-UTF8 channels. It would serve in everyone's best interests to start making the move.

Yes, changing the servers themselves takes more work, but changing a channel is fairly easy to do and considering you're keeping the same name (just encoded differently), you aren't sacrificing anything.

It was much more work for me to update the Invision script to support unicode/mIRC 7.1 than it would be for me to move everyone in one of my channels to a unicode version of the channel if I had such a channel. And I would have already made that move if I had that kind of channel. It would have been done before mIRC 7.1 was ever released because it was very well known to anyone following beta that this was coming.

sparta:

I did not only test one network. I understand there are probably "worse" choices in terms of network, however QuakeNet, being the largest network, has the widest random sample population. You need only take a stats 101 course to realize that 5% of a large enough random sample size means it's likely to be 5% in other places too (except for specialty networks or hyper-regional ones).

For comparison, I just tested RusNet, which I guessed would have a much higher percentage, but the numbers are closer to 10-12%, ie. high, but not as high as I thought. This is, of course, a biased sample, and probably one of the worst-case scenarios. I should also point out that RusNet has (experimental) server-side utf-8 support, so it's not as big a deal there either. Finally, putting this all in context, RusNet only has 5,000 users and 6,000 channels. 10% of that number is small change.

But again, even if there are more than 10%, the vast majority of this 5% (or 10%, or 15%?) is still mIRC clients. Of all the channels I polled, almost 95% were mIRC. Other clients I noticed were: kVIRC (once), x-chat (once), Miranda IM (once, and ironic because it was a "Unicode build"), and irssi 0.8.15 (latest version, maybe 15 times), and a handful of eggdrops. irssi was the second largest number, but still paled in comparison to the amount of mIRC clients that I counted.

The rejoin function Khaled proposed is to avoid rewriting servers. mIRC is unable to join these codepage encoded channels, so they already have to stick to 6.35 anyway. Migrating the users that *do* upgrade seems like the sane solution, rather than doing nothing.

On a sidenote, if you think 6.35 is outdated, you should see the clients these users use. One some channels, the average version was 6.2 (and went as low as 5.9). I don't think they will be complaining about having to continue using their version. Clearly, these aren't the users who will be upgrading to 7.1 any time soon.

uh, did I get this right? There is currently no way to join ISO channels using mIRC anymore?

To be honest, this is a reason for me to switch the client. It may very well be ideologically right to settle to UTF-8 in 2010 but also practically? I am using an irssi proxy in a Linux Latin-1 environment, and beside not being able to join ISO channels, I am also not able to receive query messages anymore.

Maybe one should add a note next to the mIRC download button: "Beware: Cannot handle ISO-8859-x anymore!"

The main reason to even use 7.1 versus 6.35 is for unicode support. If you don't want or need it, then 6.35 works just fine and you're not going to miss out on all that much... yet. As newer versions come out with additional features, you'll slowly start missing out on a lot by not using valid UTF8 channels.

I think mIRC really needs to keep exactly what the server sends. I.e. if there's an invite with a channel name that is not UTF8 encoded, it should join the non-utf8 channel. And whenever that channel name is used it should be used in the non-utf8 way so messages to the channel etc. actually arrive.

You cannot expect network admins to upgrade all their ircds quickly just due to you dropping non-utf8 support.
As you might know ircd upgrades require restarts (unless they are very modular, but some of the biggest networks like Quakenet, Undernet and Gamesurge use non-modular ircds) of the ircd which results in dropping users.
This usually means updates can't be done quickly because servers have to be removed from the DNS round-robins and then you have to wait a few days for the server to become less populated.
Assuming you have 15 servers and you want to wait 3 days after removing them from the RR before you upgrade them to keep the number of users quitting in a netsplit low.
Then, if you upgrade 3 servers at once, it will take you about 2 weeks until you've upgraded all servers.
Two weeks where mirc7 users will be pissed about not being able to join their channels (switching them to utf8 is not an option since then mirc6 users will not be able to join without an invite or by using copy&paste so they get into the utf8 channel).
And with irc being less popular thanks to all this social network crap etc.
I don't think any network wants to lose users due to this.

So I think mIRC should be smart. When joining a channel manually it should check if either the UTF8 or the non-UTF version exists. If the non-UTF version exists and the UTF8 version doesn't, it should use the non-UTF8 version. This would avoid issues with legacy channel names while actively promoting UTF8 as newly created channels would use UTF8 encoding.

It really isn't that simple. Both versions can exist for one. For another, if it did that, you could never choose to join the UTF8 version of the channel if the non-UTF8 version existed. That's just two examples why you can't do it the way you suggest. It would also be a pain to manage all of the events that need to track whether or not to use a UTF8 or non-UTF8 channel name.

There may be options available for IRCops that will let them manage the "outdated" channel names at some point. In the meantime, mIRC 6.35 works just fine. Almost the entire reason to upgrade to mIRC 7.1 is FOR Unicode support. If you don't want or need it, there's not much reason to upgrade from 6.35 at this time. IRCops can easily stick to that without any issues until either mIRC offers an option for them to handle those non-UTF8 channels/nicks or they update their servers to no longer use non-UTF8.

By the way, IRC protocol standard document clearly states what there is no character set defined, this particularly means payload text is raw octets (8 bits, sic!) and conversion to characters is up to clients. So, you cannot accuse any server in not supporting UTF-8 (or any other code pages).


For me, it was kind of race condition on losing focus under Windows 7 with Aero enabled. (mIRC 6.35 had more time on CPU than IE 8, heh)


Sorry to interrupt UTF-8 praises, but theoretical maximum of 491 bytes (:n!u@h PRIVMSG #c :<491 bytes of payload><CR><LF>) reduces by 2 times (or 3 times for eastern ircers) that's why people speaking unsupported languages do not hurry to make their IRC UTF-8 compliant.

You can accuse them all you want. You're misinterpreting the spec. The RFC states that the specification defines no specific encoding-- ie. it is undefined by the spec and can be left up to either implementation of the client and/or server. Just because the spec does not say "you must support encoding X", does not mean a server implementor cannot be accused of not supporting encoding X. The HTTP specification does not enforce user-agents to support the PUT method, for instance, but the lack of support for PUT in popular browsers has been a huge hindrance on REST adoption over the last few years. Even though they can cite the spec all they want, web browser developers are still to blame for this. It's their responsibility (just like it is with servers) to ensure that the spec is implemented in a way that is most useful to its users. Encoding is a large problem for all IRC clients. Supporting encodings on the server is the easiest way to solve this problem. It should be done. Clinging to the literal spec that was written when computers had less than a megabyte of RAM is stifling. And people wonder why IRC is declining in popularity. Hint: it has nothing to do with webcam support; the problem is much more basic than that.



SJIS, the popular encoding for those "eastern ircers" also uses 2 bytes, so you're reducing the byte count there too.

And again, you're taking the spec way too literally here. The 512 byte length has always been an arbitrary value imposed by implementations of the time; again, this was written in 1993, when 0.5kb was a lot of data. 512 is a common value supported by some servers since its listed in the spec, but not all servers follow this. If UTF-8 adoption increased (and it has), servers would adjust accordingly. It would be similar to the way mIRC adjusted its line length in scripts from 900 to 4096 recently.