No argument that the situation doesn't need a fix.

But you didn't answer my question:  *What* are you running when the problem
shows up?  Your own Java project?  If so, Ant, Maven or something else
(i.e. build system where this is settable/detectable or not?)?  Or some
application server or third party thing?

What I'm trying to nail down is, what is the point of minimal intervention
where this could either be detected or made settable.  External processes
in Java have binary output;  the IDE decides what character set to impose
over that.  That decision can be improved, but not without knowing what the
stream is coming from there's no place to start.  Without knowing what it
is you're looking at the output of when you see this problem, there's no
progress to be made.

I'm all for UTF-8 everywhere in theory, and on my own systems, but
defaulting to that is likely to break things for at least as many people as
it helps.  So, in the interest of solving it with a scalpel instead of a
sledgehammer, could you give a little detail on where the problematic
output is coming from and how it is generated?

Thanks,

-Tim

On Fri, Apr 20, 2018 at 8:33 PM, Victor Williams Stafusa da Silva <
[email protected]> wrote:

> In my case, I'm running in windows, with the dreaded and hated Windows-1252
> default encoding.
>
> Using default OS encoding is really bad for portability and causes a lot of
> encoding problems. See this JEP draft maybe for Java 11:
> http://openjdk.java.net/jeps/8187041 - There are three proposed
> alternatives: 1) Keep the status quo; 2) Deprecate all the methods that
> uses the platform default encoding; 3) Force UTF-8 deing the default
> regardless of anything.
>
> As a speaker of Portuguese, a language that is full of diacritics, I'm
> already very sick of years and years of being haunted by encoding problems
> in buggy software. But it could be much worse if my language was Chinese or
> Japanese.
>
> Since option 1 is unacceptable and 3 is too drastic and dangerous due to
> backwards-compatibility concerns, I think that this JEP, if it eventually
> gets delivered, will go to option 2.
>
> Anyway, regardless of this JEP or its future, Netbeans should either get
> the correct encoding in the console window or at least provide an easy and
> accessible way to et the user define it.
>
> Victor Williams Stafusa da Silva
>
>
> 2018-04-20 20:00 GMT-03:00 Tim Boudreau <[email protected]>:
>
> > Your problem is most likely your operating system's default file encoding
> > here (perhaps MacRoman?).  The IDE is assuming that process output is
> > whatever your operating system's default encoding is, which is the right
> > assumption, since that *is* what command-line utilities will output.  It
> > happens that the process you're running is outputting UTF-8 *rather than*
> > the
> > OS's default encoding.
> >
> > Setting that as a default would be assuming that every operating system
> > uses UTF-8 regardless of what it does - it would be wrong a lot of the
> > time.  It just happens to solve the case that whatever you're running is
> > outputting UTF-8 in spite of what the operating system provides.
> >
> > That's not that uncommon, but the right solution is to *detect* that the
> > output is UTF-8 when the IDE runs whatever it is you're running.
> >
> > So... what are you running?  Is this project output?  If so, what kind of
> > project?  Or server output of some kind?  A correct fix would be to (if
> > possible), detect what that is and that it will output UTF-8, and have
> the
> > IDE open the output of that process with the right encoding.
> >
> > -Tim
> >
> > On Fri, Apr 20, 2018 at 6:18 PM, Victor Williams Stafusa da Silva <
> > [email protected]> wrote:
> >
> > > I frequently had some long-standing problems with the console output
> > > encoding in Netbeans. Which always presented garbled non-ascii
> characters
> > > for me.
> > >
> > > After deciding that it was enough, I went to search for a solution and
> > did
> > > found a very simple one in StackOverflow. Just add
> > -J-Dfile.encoding=UTF-8
> > > into the netbeans_default_options line of netbeans.conf file and voilĂ ,
> > it
> > > works!
> > >
> > > However, this make me think about it:
> > >
> > > 1. Is there a reason to not add it there by default?
> > >
> > > 2. If it can't be added there by default for some reason, can it at
> least
> > > be something more user-friendly and less arcane to be configured by the
> > > normal user?
> > >
> > > Victor Williams Stafusa da Silva
> > >
> >
> >
> >
> > --
> > http://timboudreau.com
> >
>



-- 
http://timboudreau.com

Reply via email to