I had the same chr(160) bug as reported before.
To avoid this bug go to settings > "IRC" > "Messages" and turn off the "SJIS/JIS conversion".

Please fix


TimeFX

Well this solution solved my problem, but its weird tho.

When I was writing normal text, no colours, in a Channel with +c turned on I often got the message: Can not send to Channel.

Well I don't know excactly for what $chr(160) stands but I think it shouldn't be on normal text

160 is the ASCII number for a no break space.

quite untrue, chr 160 is not a "defined" key, its different on many fonts and shouldnt be trusted as a reliable 'nbsp'

It would appear that 160 (0xA0) is the start marker for one of the ranges of double-byte symbols in (S?)JIS.

I would hazard a guess that if you then put an 'invalid' second byte after it, something in the code is throwing a wobbly. This, of course, is a _lot_ of assumption. I don't know what Khaled's code does with input multibyte chars; how it handles them. I also only have a passing awareness of how double-byte CJK (SJIS, BIG5, etc) actually encode the characters.

i can confirm that with the option enabled, my mirc crashes with a $chr(160) in an ame, but with it disabled, it works fine.

I've read a few threads about the $chr(160) bug, but i still don't know what you ppl are talking about :P

What do you mean by no break space? Where this $chr has to be so mIRC crashes?

Thanks

Zyzzyx.

go to alt-o IRC->messages, enable SJIS/JIS conversion

now :



(you need to be connected to a server)

Oh, i see But what's the difference between the $chr(160) and $chr(32)?

Thanks for the help

Zyzzyx.

160 and 32 are different ascii characters!

32 (0x20) is SPC - a normal, common or garden space.
160 (0xA0) is often a "non-breaking" space (one which wouldn't be the 'breaking point' of a line wrap). In other fonts it isn't - so sometimes you'll get the 'no chatacter to see here' back box. In SJIS, it is used as the start marker for one 'series' of two-byte characters.

SJIS is a form of Japanese encoding based on JIS (ISO 2022) which uses a mix of single and double-byte sequences to represent normal ascii, and Japanese (or CJK: Chinese-Japanese-Korean) characters. Particular escape sequences define the transition between normal ascii and Japanese encoding.

It's amazing how i learn a new thing everyday Thanks for the lesson!

Zyzzy.

Could someone confirm that the following *doesn't* cause the hang problem:

/say ああ

or equivalently (and to prove it contains a 160 char):

//bset &t 1 130 160 130 160 | say $bvar(&t,1-).text

For those who cannot see/read the Japanese, this is two hiragana characters for the syllable 'a'.

It doesn't appear to hang my system - I'm assuming that is because it is "valid" as an input; or perhaps because it is the second byte of the sequence.

I'm looking for a (valid) example with 160 as the first byte - not found one yet. If anyone knows of an exampple, please post.

(It would appear that the characters in the /say line didn't come out correctly in the HTML...)

Well...

I wrote this little code to look for a bouble-bytes char that would use $chr(160) as it's first byte.
//var %i 0 | while (%i < 256) { bset &t 1 160 %i | echo $bvar(&t,1-).text | inc %i }

All those "combinations" seem not to match double-bytes chars. Most of them show a "middle dot" character followed by some other char. (tested with MS Gothic, jap script).

Reversing the order of bytes (bset &t 1 %i 160) indeed shows much more *real* double-bytes chars!

I'll have to review my sources of information, then

I'm thinking perhaps I misread, and the 0xA0 term was the mask for the start of a set, not the real first byte....erg...I think I know what I mean

Thanks for the input, though. It's difficult on a non-CJK system to be confident that your tests are actually working.