🚀 go-pugleaf

> gelieve niet te antwoorden met
> 'omdat windows brol is'.

Ik heb een artikel over dit probleem gevonden, het lost echter
mijn probleem niet op. Expliciete vermelding van de 'encoding name'
geeft nog steeds verschillen tussen het gedrag op windows en op UNIX.

=======================================================================
                   DATA TRANSFER PROBLEMS ON WINDOWS
=======================================================================

A bug in the data transfer API (4032895) prevents most objects from
being copied to the Win32 clipboard. A common workaround is to convert
objects to a String representation, since String objects are not
affected by this bug.

One popular technique for converting an object to a string is to write
the object into a ByteArrayOutputStream and convert the stream to a
String with toString(). String.getBytes() reverses the process.

There is a potential problem with this kind of byte/character
conversion. Both toString() and getBytes() rely on a locale-specific
character encoder to translate byte values to and from Unicode
character values. Not all encoders assume a one-to-one relationship
between byte values and character values. To ensure a reliable
translation, do not rely on the default locale encoder. Explicitly
specify an encoder that uses a reversible translation, such as
ISO8859_1. Do this by passing the encoder name to toString() and
getBytes():

    aString = aStream.toString("ISO8859_1");
    aByteArray = aString.getBytes("ISO8859_1");

In previous releases, the need to use a reversible encoding was not
apparent to most programmers. ISO8859_1 was the default encoder for
western locales on both Solaris and Win32. A program's dependence on
ISO8859_1 might not be apparent if the program was not tested under a
non-western locale. 

JDK software running on Win32 machines uses Cp1252 (Windows Latin-1) as 
the default encoding for western locales. Cp1252 does not implement a 
reversible byte/character translation. It may appear to some 
programmers that 1.1.7 introduces an incompatibiity. The real problem 
is a programming technique that unintentionally relies on the features 
of specific locales.