mIRC Homepage
Posted By: Thels Parsing characters - 25/08/10 03:09 PM
Hi,

For certain reasons, I want to replace certain characters like $, % and " by different characters the moment I receive them, and only convert them back at the very last moment. Now I know how I can script this, but the question is which replacement characters to use.

I'd prefer if $len and similar identifiers don't change due to these characters, but it's ok if they change for characters that are not likely to to appear.

Now I was wondering if characters in the 1-31 range would be suitable for this. Obviously, 2, 3, 15, 22, 29 and 31 are control codes, and thus likely to appear, but what about the others? Though I don't expect line feeds and carriage returns in a single line of text, I'm not touching those just to be sure.

Any other characters in the 1-31 range that can be considered safe/unsafe?
Posted By: Riamus2 Re: Parsing characters - 25/08/10 04:37 PM
One you could use would be TAB if you're not needing that elsewhere. Not sure about others.

Since I don't talk in channels that use non-English characters, whenever I need to replace text, I will just use a character that isn't going to be used normally. Something like × or Ø or Þ or something similar. If I'm replacing something that others may use in channels that use these types of characters, then I typically pick some "random" combination of 3 of those kinds of characters or else just 3 symbols that are unlikely to be used together. This works well, but it does mess up $len/$right/$left/$mid/etc if you need to use those. Of course, that can also be worked around if needed. If those really aren't needed, then this is usually a "safe" way to handle such temporary replacements.
Posted By: hixxy Re: Parsing characters - 25/08/10 05:01 PM
Use $crlf. A $crlf *cannot* appear in a single line of text. Problem solved laugh
Posted By: Thels Re: Parsing characters - 25/08/10 05:06 PM
I'm currently replacing characters 20, 21, 23, 24, 25, 26, 27, 28 and 30 into a combination of $chr(30) and a number, and the { [ ] " # $ % and } characters by characters 20, 21, 23, 24, 25, 26, 27, 28.

So no characters are getting lost, and $len doesn't change on the presence of { [ ] " # $ % and } characters, but it does on the 20, 21, 23, 24, 25, 26, 27, 28 and 30 characters. Keeping the correct length is not crucial, but I'd like to keep it if possible.
Posted By: Thels Re: Parsing characters - 25/08/10 05:07 PM
Originally Posted By: hixxy
Use $crlf. A $crlf *cannot* appear in a single line of text. Problem solved laugh


But those are two characters, right? That beats the purpose of keeping it to a single character for $len purposes.
Posted By: Riamus2 Re: Parsing characters - 25/08/10 06:48 PM
Originally Posted By: Thels
and $len doesn't change on the presence of { [ ] " # $ % and } characters


Keep in mind however, that it does change if you have 2 or more of those characters side-by-side.
Posted By: Thels Re: Parsing characters - 25/08/10 07:14 PM
Originally Posted By: Riamus2
Originally Posted By: Thels
and $len doesn't change on the presence of { [ ] " # $ % and } characters


Keep in mind however, that it does change if you have 2 or more of those characters side-by-side.


It does? You mean normally, or in this parsed case?

Either way, the size should not chance, since I'm parsing them by different 1 character values.

Those placeholder characters are also parsed themselves just to be sure, and they are parsed in 2 character values, and thus would increase the value of $len.
Posted By: jaytea Re: Parsing characters - 25/08/10 09:07 PM
typically you would use $encode( , m) to transform an arbitrary string of text into a (nearly) alphanumeric string that's safe to pass around mIRC without worrying about undesired evaluations. then $decode( , m) can be used to perform the reverse operation

however, all this might be unnecessary. what reason do you have to want to replace all these characters? are you, by any chance, storing lines in a text file then later retrieving them with $read(), only to find that it's being treated as a line of code? if so, you should include the 'n' switch in $read(). there might exist other similarly easy workarounds depending on the nature of your problem
Posted By: Thels Re: Parsing characters - 26/08/10 09:32 AM
I'm not familiar with $encode. Does it retain length? My guess is it wouldn't. But it doesn't really matter as I do want to alter the contents along the way.

I'm not loading or saving. I'm actually displaying the text again right after I'm done with it. Problem is that I'm loading the text into another line that can be customized by the end user. Since I want to allow identifiers to work for the other line and on the text for the message, but keep the message itself as is (save for where outside identifiers affect it), I decided to temporary replace those 8 characters.

Code:
alias -l parse return $replacex($replace($+($chr(32), $1-), $+($chr(32), $chr(32)), $+($chr(32), $chr(160)), $+($chr(160), $chr(32)), $+($chr(160), $chr(160))), $&
$chr(30), $+($chr(30), 9), $chr(20), $+($chr(30), 0), $chr(21), $+($chr(30), 1), $chr(23), $+($chr(30), 3), $chr(24), $+($chr(30), 4), $chr(25), $+($chr(30), 5), $&
$chr(26), $+($chr(30), 6), $chr(27), $+($chr(30), 7), $chr(28), $+($chr(30), 8), $chr(123), $chr(20), $chr(91), $chr(21), $chr(93), $chr(23), $chr(34), $chr(24), $&
$chr(35), $chr(25), $chr(36), $chr(26), $chr(37), $chr(27), $chr(125), $chr(28))

alias -l unparse return $replacex($1-, $chr(28), $chr(125), $chr(27), $chr(37), $chr(26), $chr(36), $chr(25), $chr(35), $chr(24), $chr(34), $chr(23), $chr(93), $&
$chr(21), $chr(91), $chr(20), $chr(123), $+($chr(30), 8), $chr(28), $+($chr(30), 7), $chr(27), $+($chr(30), 6), $chr(26), $+($chr(30), 5), $chr(25), $&
$+($chr(30), 4), $chr(24), $+($chr(30), 3), $chr(23), $+($chr(30), 1), $chr(21), $+($chr(30), 0), $chr(20), $+($chr(30), 9), $chr(30))


The above code seems to work just fine, as far as I could have noticed. I'm just wondering where adding characters in the 20-30 range (skipping 22/29) could cause problems.
© mIRC Discussion Forums