To put it another way, can you give a good logical reason why mIRC should output debug.log differently in 6.35 than in 7.0? The client is sending and receiving identical byte-for-byte data in either version. Why should mIRC be saving that data to a debug.log file differently in each version?
Yes. The logical reason was discussed in my first response. It provides different output in a file for the same reason it provides it in the window; because the output is meant to visualize the data, not to accurately log the exact bytes sent over the wire. Again, this may not be
your interpretation, but it's perfectly logical and reasonable to other users. I find it perfectly reasonable. And again, allowing for an extra switch in /debug to produce byte for byte raw output would be an option to make both scenarios work.
Ironically enough, you keep talking about how mIRC's debug command works similar to a hex editor -- and yet, because of how mIRC stores debug.log files, they can't be opened directly in an actual hex editor (without first decoding it yourself).
This is neither ironic nor odd. If you copy pasted the output of a hex editor into another hex editor you would have the same problem. The point of mIRC's debug.log acting the way it does is to avoid the extra dependency of forcing users to use a hex editor to view what was sent over the IRC server. Instead it can be easily visualized (the point of a
debug log) for users to view.
Like I said before, opening the file in a hex editor, which gives more information than outputting to a debug window (i.e., seeing if lines terminate with both CR and LF, seeing if nonprintable characters are present, etc.)
Double encoding utf-8 doesn't stop you from doing the above. You could still see CRLFs and non printable chars in a hex editor, you'll just see oddities for UTF-8 encoded text, but since you're only using the hex editor to *view* the data, there isn't much of a harm here.
