Your distribution uses UTF-8 character encoding. This is normal for most current distributions.
What you see is the effect of UTF-8 coded characters displayed as another encoding.
Many GNU utilities try to use different quotation marks for opening and closing quotes. With some fonts this looks good, with others not so good.
Let's look at the output produced by
$ find /x 2>&1 | hexdump -C
00000000 66 69 6e 64 3a 20 e2 80 98 2f 78 e2 80 99 3a 20 |find: .../x...: |
Before and after the
/x we have the sequences
e2 80 98 and
e2 80 99.
Your console is configured for UTF-8 and is able to display the UTF-8 sequence correctly. The
cat program doesn't recognize or care about this sequence, so it doesn't matter.
On the other hand, your
vi is interpreting the file as latin1. This is at least unusual on a modern distribution. In latin1, the first byte,
e2, is interpreted as
99 are invalid in latin1 and displayed as
<80> and so on. This results in
How to avoid that? You can configure your
vi to display files as UTF-8, or you can avoid the UTF-8 sequences in your output.
$ LC_CTYPE=C find /x 2>&1 | hexdump -C
00000000 66 69 6e 64 3a 20 27 2f 78 27 3a 20 |find: '/x': |
find doesn't generate UTF-8 sequences and instead uses the single quote
' for opening and closing quote.
Note that disabling UTF8 might change how programs process their input, although it shouldn't matter in your example.