What encoding do you have on your local development host?
I think the root of the evil is not UTF-8, but the difference of encodings between local and remote hosts.

RemoteCommandSupport.run() should be patched to create InputStreamReader with remote host charset, not with local host
charset.

LANG=ru_RU.UTF-8

So, UTF-8 on both local and remote hosts?

on windows CP1251 (used as base host)
on linux LANG=ru_RU.UTF-8 (used as remote host)

OK, I see. Thank you for info.

Alexander, I have checked remote development from en_US.UTF-8 Solaris 
to ru_RU.UTF-8 Linux 
and now it works fine.
Could you, please, check as well.

Thanks,
Vladimir.

Copying project files to /home/tester/.netbeans/remote/Welcome_13 at tester@*****
/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .clean-conf
make[1]: Вход в каталог `/home/tester/.netbeans/remote/Welcome_13'
rm -f -r build/Debug
rm -f dist/Debug/GNU-Linux-x86/welcome_13
make[1]: Выход из каталога `/home/tester/.netbeans/remote/Welcome_13'
CLEAN SUCCESSFUL (total time: 336ms)

/usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf
make[1]: Вход в каталог `/home/tester/.netbeans/remote/Welcome_13'
/usr/bin/make  -f nbproject/Makefile-Debug.mk dist/Debug/GNU-Linux-x86/welcome_13
make[2]: Вход в каталог `/home/tester/.netbeans/remote/Welcome_13'
mkdir -p build/Debug/GNU-Linux-x86
rm -f build/Debug/GNU-Linux-x86/welcome.o.d
g++    -c -g -MMD -MP -MF build/Debug/GNU-Linux-x86/welcome.o.d -o build/Debug/GNU-Linux-x86/welcome.o welcome.cc
mkdir -p dist/Debug/GNU-Linux-x86
g++     -o dist/Debug/GNU-Linux-x86/welcome_13 build/Debug/GNU-Linux-x86/welcome.o  
make[2]: Выход из каталога `/home/tester/.netbeans/remote/Welcome_13'
make[1]: Выход из каталога `/home/tester/.netbeans/remote/Welcome_13'
BUILD SUCCESSFUL (total time: 1s)

Vladimir, encoding problems happen when local and remote machines use different encodings. You checked the case when
encodings are the same. Try to build on UTF-8 Linux from Windows (CP1251).

Thanks, will check from Windows

After some investigation of the problem my understanding is as follows:

- we have at least two "sources" of localized strings:
   1 - the program that we develop from within the IDE
   2 - tools that we use to compile/debug/etc...

- In case when user uses encoding for his sources that is differ from the one that IDE was started with - we just do
nothing. It's not what we should solve, I believe.
  Example:
  1) LC_ALL=ru_RU.UTF-8 netbeans
  2) in editor switch to cp1251
  3) start program that has 'cout << "Русский текст"'
  4) output will be mangled and this is OK

  This is an example of wrongly localized application - it writes in CP1251 just because it's source uses this locale.

So let's assume that all involved applications can correctly work in specified locale => which one should  we use? The
one that is used on "developer's" side or the one that is set on a remote host?
I think that the answer is "it depends"... So, looks like we need a way to have a control on "execution locale"..

This could be solved with the "IZ#167294 - bashrc analog for remote connection". I.e. user may adjust locale in some
file that will be executed when connection is established.
Another option is to setup remote locale based on local one (and use encoding that is used for the project)
Third option is to find out the remote locale and try to convert output from that locale. But in this case we may break
user's application output.

Seems not to be a P3

*** This bug has been marked as a duplicate of bug 177286 ***