Citat:
Vet inte om du tycker att detta klarnat via de svar du fått, då de ibland varit otydliga och delvis missvisande.
Javas fundamentala datatyp för detta, char, representerar alltid Unicode. Ingenting annat. Javas String likaså. Glöm encodingformat helt här. (*1)
När man av något skäl vill hantera tecken utanför dessa typers runtimelagring, i ex en fil, en nätverksström eller annat, så behöver man omvandla dessa till ett transportformat. Först här kommer encoding och olika format in i bilden.
De metoder som omvandlar tecken till ett transportformat eller tvärtom omvandlar alltså från Unicode till ett encodingformat eller tillbaka. Vissa där man anger format via metodparametrar och vissa med defaultformat. Detta är väl dokumenterat i javadoc:en för Java Core API och väl värt att kolla upp. Typen Charset används för encodingformat.
Encodingformatet UTF-16 är förvisso väldigt nära Unicode i sin lagring, men det är fortfarande 2 olika saker.
Med detta som grund så kan vi gå igenom dina exempel steg för steg:
Nej, den använder alltid Unicode. (*1)
Din myString är Unicode.
Anropet getBytes() ovan omvandlar från Unicode till angivet format.
Din iso88591bytes är en array av bytes (inte tecken längre) i encondingformatet "ISO-8859-1". (*2)
Konstruktorn ovan för String omvandlar indata från dess encodingformat till Unicode.
Din newMyString är Unicode.
DIn newString3 är Unicode.
(*1): De är specificerat i Javas språkdefinition att det är Unicode som representeras i char och String. Även om det är teoretiskt möjligt att enl specifikationen fullfölja definitionen och ändå lagra tecken internt i en String i något annat format, så spelar det ingen roll. Alla metoder som jobbar med typen char i String, jobbar med Unicode i sitt gränsssnitt.
(*2): Detta förutsatt att plattformen accepterade det format du angav. Vissa format måste stödjas enl standarden, bland annat ISO-8859-1.
Javas fundamentala datatyp för detta, char, representerar alltid Unicode. Ingenting annat. Javas String likaså. Glöm encodingformat helt här. (*1)
När man av något skäl vill hantera tecken utanför dessa typers runtimelagring, i ex en fil, en nätverksström eller annat, så behöver man omvandla dessa till ett transportformat. Först här kommer encoding och olika format in i bilden.
De metoder som omvandlar tecken till ett transportformat eller tvärtom omvandlar alltså från Unicode till ett encodingformat eller tillbaka. Vissa där man anger format via metodparametrar och vissa med defaultformat. Detta är väl dokumenterat i javadoc:en för Java Core API och väl värt att kolla upp. Typen Charset används för encodingformat.
Encodingformatet UTF-16 är förvisso väldigt nära Unicode i sin lagring, men det är fortfarande 2 olika saker.
Med detta som grund så kan vi gå igenom dina exempel steg för steg:
Nej, den använder alltid Unicode. (*1)
Din myString är Unicode.
Anropet getBytes() ovan omvandlar från Unicode till angivet format.
Din iso88591bytes är en array av bytes (inte tecken längre) i encondingformatet "ISO-8859-1". (*2)
Konstruktorn ovan för String omvandlar indata från dess encodingformat till Unicode.
Din newMyString är Unicode.
DIn newString3 är Unicode.
(*1): De är specificerat i Javas språkdefinition att det är Unicode som representeras i char och String. Även om det är teoretiskt möjligt att enl specifikationen fullfölja definitionen och ändå lagra tecken internt i en String i något annat format, så spelar det ingen roll. Alla metoder som jobbar med typen char i String, jobbar med Unicode i sitt gränsssnitt.
(*2): Detta förutsatt att plattformen accepterade det format du angav. Vissa format måste stödjas enl standarden, bland annat ISO-8859-1.
Tack för ett bra svar.
Har gjort en workaround som tycks fungera, så case closed och tack till alla som har gett input till mig i denna tråd.
Om någon undrar vad min workaround är så har jag lagt till en extra codepage-converter process som säkerställer att jag får ut min önskade encoding.
