The editor is (naively) interpreting the bytes (octets) of the file as some character encoding, but from your excerpt is is very hard to tell which one. Indeed, it looks like it may be switching between multiple ones.
It might have been easier to figure out exactly what it was doing if you had shown the representation from the start. A PNG file (and many standardized binary file formats) starts with a "magic number" which means "if you are paying attention, o program, this file has PNG data". The magic number for PNG files is the five characters \x89 P N G \r \n
where \x89 is a character which doesn't appear in ASCII but might be shown as ‰ in the Windows-1252 code page and "\r" and "\n" are an ASCII carriage return and linefeed, respectively.
The thing that is puzzling me is that there are too many different symbols in your excerpt which makes it seem unlikely that only one character table is being used. If - for example - the 1252 code page was being used, some of the 'latin' characters "æ™Ã" would make sense. Unfortunately, your example also include various Greek characters "∆∏Ω" and you just can't pack that many different characters into one byte.
It isn't completely meaningless, that is, you probably see the same sequence of glyphs for the same file and those could - in principle - be back-translated into the original PNG if you knew what the coding scheme was, but I can't puzzle it out from what you've given. (That's almost true, your sample has strings like "˙X˘ ˝…˚" in it and glyphs that show as spaces are a little bit difficult to visually decrypt to a known byte.)