/ Forside / Teknologi / Udvikling / Java / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Java
#NavnPoint
molokyle 3688
Klaudi 855
strarup 740
Forvirret 660
gøgeungen 500
Teil 373
Stouenberg 360
vnc 360
pmbruun 341
10  mccracken 320
Codepage understøttelse af Java
Fra : Casper


Dato : 29-06-05 10:19

Nationale codepage ASCII udvidelser (8-bit) skulle være understøttet af
"java.io" samt "java.lang" pakkerne inden i "charsets.jar".

Pudsigt nok, så findes der ingen support for disse codepages i java's
national I/O pakke "java.nio" som ellers indkapsler den meget handy
klasse "Charset". Dvs. man kan ikke teste om ens system understøtter
f.eks. den gamle danske codepage 865:

Charset.isSupported("Cp865"); // false.

Ifølge http://www.rgagnon.com/javadetails/encoding.html, er der support
for en hel suite af codepages incl. cp865 i "java.io" API'et og her kan
man sagtens indlæse en gammel Dos fil med codepage 865:

....new InputStreamReader(BufferedInputStream(new
FileInputStream("a.txt")), "Cp865");

Det virker frustrerende og rodet, at karaktersæt ikke alle er indkapslet
i et og samme objekt (Charset). Betyder dette, at der er ingen måde at
teste om et karaktersæt er understøttet, bortset fra en grim måde at
misbruge en InputStream til formålet?

Hvordan i alverden kan man i sin applikation, indkapsle support for
samtlige karaktersæt, hvis kun nogle af sidde er indeholdt i Charset
instanser (med deres streng identifier aliaser) og resten er gemt væk
som streng identifiers et eller andet sted i "java.io" pakken?

På forhånd tak,
Casper

 
 
Casper (29-06-2005)
Kommentar
Fra : Casper


Dato : 29-06-05 11:51

Nå, det viser sig at det er muligt at teste karaktersæt understøttelse
ved brug af sun.io.CharacterEncoding klassen:

sun.io.CharacterEncoding ce = new sun.io.CharacterEncoding();
System.out.println( ce.aliasName("Cp168")); // null :)
System.out.println( ce.aliasName("US-ASCII")); // "ASCII" :)
System.out.println( ce.aliasName("Cp865")); // "Cp865" :)

Jeg er dog ikke sikker på hvor pålideligt/korrekt dette er. Mit største
problem forbliver dog stadig, at samle samtlige karaktersæt (med
codepage's) under ét. Jeg kan ikke se nogle måder at enumerere codepage
support hverken i sun.io eller andre pakker.

Casper

Johnnie Hougaard Nie~ (29-06-2005)
Kommentar
Fra : Johnnie Hougaard Nie~


Dato : 29-06-05 16:33

Casper wrote:
> Jeg er dog ikke sikker på hvor pålideligt/korrekt dette er.

Du har ret i det med at holde sig fra at referere til sun.* pakkerne.

Forresten viser en hurtig test på Sun Java 1.5:
Charset.isSupported("Cp865") = true
Charset.forName("Cp865").name() = IBM865

Hvilken udgave kører du?

> Jeg kan ikke se nogle måder at enumerere codepage
> support hverken i sun.io eller andre pakker.

Hvad er der galt med Charset.availableCharsets() ?

En loop gennem den returnederede SortedMap indeholder giver som
forventet et Charset hvor name() = "IBM865", og aliases()
indeholder "cp865".

/Johnnie

Casper (30-06-2005)
Kommentar
Fra : Casper


Dato : 30-06-05 09:43

> Forresten viser en hurtig test på Sun Java 1.5:
> Charset.isSupported("Cp865") = true
> Charset.forName("Cp865").name() = IBM865

Ja det ville jo være dejligt hvis det virkede hos mig!

> Hvilken udgave kører du?

1.4.2_04, i et J2EE miljø. Kan ikke umiddelbart skifte til 1.5 pga.
applikationsserver og database (Oracle).

> Hvad er der galt med Charset.availableCharsets() ?
>
> En loop gennem den returnederede SortedMap indeholder giver som
> forventet et Charset hvor name() = "IBM865", og aliases()
> indeholder "cp865".

Intet IBM865 hos mig, charset canonial name + aliaser jeg får er:
-------------------------------------------------------------------
Big5 csBig5
Big5-HKSCS big5-hkscs Big5_HKSCS big5hkscs
EUC-JP eucjis x-eucjp csEUCPkdFmtjapanese eucjp
Extended_UNIX_Code_Packed_Format_for_Japanese x-euc-jp euc_jp
EUC-KR ksc5601 5601 ksc5601_1987 ksc_5601 ksc5601-1987 euc_kr
ks_c_5601-1987 euckr csEUCKR
GB18030 gb18030-2000
GBK windows-936 CP936
ISO-2022-JP jis jis_encoding csjisencoding csISO2022JP iso2022jp
ISO-2022-KR ISO2022KR csISO2022KR
ISO-8859-1 iso-ir-100 8859_1 ISO_8859-1 ISO8859_1 819 csISOLatin
IBM-819 ISO_8859-1:1987 latin1 cp819 ISO8859-1 IBM819 ISO_8859_1 l1
ISO-8859-13 iso8859_13
ISO-8859-15 8859_15 csISOlatin9 IBM923 cp923 923 L9 IBM-923 ISO8859-15
LATIN9 ISO_8859-15 LATIN0 csISOlatin0 ISO8859_15_FDIS ISO-8859-15
ISO-8859-2 l2 iso-ir-101 ISO_8859-2:1987 ISO_8859-2 latin2 csISOLatin2
iso8859_2
ISO-8859-3
ISO-8859-4 iso-ir-110 l4 latin4 csISOLatin4 iso8859_4 ISO_8859-4:1988
ISO_8859-4
ISO-8859-5 cyrillic iso8859_5 ISO_8859-5 iso-ir-144 csISOLatinCyrillic
ISO-8859-6
ISO-8859-7 greek8 ECMA-118 sun_eu_greek ELOT_928 ISO_8859-7:1987
iso-ir-126 ISO_8859-7 iso8859_7 greek csISOLatinGreek
ISO-8859-8
ISO-8859-9 iso-ir-148 latin5 l5 ISO_8859-9 ISO_8859-9:1989 csISOLatin5
iso8859_9
JIS_X0201 JIS_X0201 X0201 JIS0201 csHalfWidthKatakana
JIS_X0212-1990 jis_x0212-1990 iso-ir-159 x0212 JIS0212 csISO159JISX02121990
KOI8-R koi8 cskoi8r
Shift_JIS shift-jis x-sjis ms_kanji shift_jis csShiftJIS sjis pck
TIS-620
US-ASCII ISO646-US IBM367 ASCII cp367 ascii7 ANSI_X3.4-1986 iso-ir-6 us
646 iso_646.irv:1983 csASCII ANSI_X3.4-1968 ISO_646.irv:1991
UTF-16 UTF_16
UTF-16BE X-UTF-16BE UTF_16BE ISO-10646-UCS-2
UTF-16LE UTF_16LE X-UTF-16LE
UTF-8 UTF8
windows-1250 cp1250
windows-1251 cp1251
windows-1252 cp1252
windows-1253 cp1253
windows-1254 cp1254
windows-1255
windows-1256
windows-1257 cp1257
windows-1258
windows-31j csWindows31J windows-932 MS932
x-EUC-CN gb2312 EUC_CN euccn euc-cn gb2312-80 gb2312-1980
x-euc-jp-linux euc_jp_linux euc-jp-linux
x-EUC-TW cns11643 euc_tw EUC-TW euctw
x-ISCII91 iscii ST_SEV_358-88 iso-ir-153 csISO153GOST1976874 ISCII91
x-JIS0208 JIS_C6626-1983 JIS0208 csISO87JISX0208 x0208 JIS_X0208-1983
iso-ir-87
x-Johab johab ms1361 ksc5601-1992 ksc5601_1992
x-MS950-HKSCS MS950_HKSCS
x-mswin-936 ms936 ms_936
x-windows-949 windows949 ms_949 ms949
x-windows-950 windows-950 ms950
-------------------------------------------------------------------

Mads Bahrt (29-06-2005)
Kommentar
Fra : Mads Bahrt


Dato : 29-06-05 13:20

Casper wrote:
> Pudsigt nok, så findes der ingen support for disse codepages i java's
> national I/O pakke "java.nio" som ellers indkapsler den meget handy
> klasse "Charset". Dvs. man kan ikke teste om ens system understøtter
> f.eks. den gamle danske codepage 865:
nio står får "new I/O" - ikke National I/O hvis det er det du siger.
Målet med nio er primært at muliggøre bedre skalering i javasystemer.

Casper (29-06-2005)
Kommentar
Fra : Casper


Dato : 29-06-05 13:56

> nio står får "new I/O" - ikke National I/O hvis det er det du siger.
> Målet med nio er primært at muliggøre bedre skalering i javasystemer.

Ikke destro mindre kan jeg stadig ikke finde nogen måde på at enumerere
codepage dekodere fra java.io for at komplementere java.nio.Charset

Når jeg gransker den åbne Java implementation Kaffe ser det ud til at
jeg må skrive min egen, der kigger efter dekoder bytekode klasser i API'et.

Casper

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408914
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste