You emphasized the wrong thing. "raw server messages" does not imply how the data will be displayed (in fact, messages rather than data implies that it's not meant as a packet sniffer). Outputs is the keyword here. And there are a lot of different ways to output data. One of them is to display each byte separately in a hex editor fashion as I described above. You can say that a hex editor "outputs raw data in an exe file", but you won't expect to see a copy pasteable version of the bytes in the file.
How mIRC chooses to display debug output is up to it, and I don't really have any issue with how it outputs to windows right now. However, it makes no sense to UTF8-encode the data when saving it to a file. If mIRC is doing the displaying, then it can make whatever decisions it wants to regarding how it is displayed, but if it is leaving the "displaying" up to an external application, then it shouldn't be making those decisions -- leave it up to the external application to decide whether to open the file as ANSI, UTF-8, etc.
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?
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).
Except this is not true. Your assumption is that the raw data being dumped to a file is UTF-8, but this is not always the case. Many times, you will get ANSI encodings in the file, which will garble when /loadbuf'd back to mIRC, so it won't produce a correct result visually. Part of the reason /debug does not encode the data before displaying it in @debug is to allow users to visualize the raw results of different encodings:
You completely misunderstood me. Consider for a moment what happens when mIRC receives a message and then outputs it to a @debug window. It receives the data as raw bytes. It then takes those bytes and UTF *ENCODES* them (I did not say decode) before inserting it into the window buffer. Since the window automatically takes the content of the buffer and decodes it using UTF-8, the result is that you see "undecoded" ANSI text. Since the window would automatically decode anything in its buffer, mIRC actually encodes it before inserting it into the buffer -- cancelling each other out. That is what I'm referring to as the "workaround".
What I was saying is that mIRC should have a switch for /loadbuf that will ENCODE the text to UTF-8 before inserting it into the buffer, so that after the window display routine automatically DECODES the text, the printed result is essentially the same as displaying the text as ANSI. mIRC doesn't need to actually explain it that verbosely, and could just say "read file as ANSI instead of UTF-8" -- but I'm just describing what would actually be happening behind the scenes.
If you can name a specific use case for /debug file that requires the explicit raw data to be shown, I'm all ears-- but I can't think of anything "useful" besides staring at data.
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.)
