Gå til innhold

[Løst] Java misliker stor Å


Anbefalte innlegg

Heisann

 

Sitter og har problemer med et Java-program. Det har kokt ned til at Java nekter å lese inn bokstaven Å under Linux. Den leser Æ, Ø, æ, ø og å uten problemer, men altså ikke Å. Videre skal det nevnes at verre tegn som f.eks. Ų̀ eller И́ virker helt fint. Jeg har ikke dette problemet under Mac OS X.

 

Jeg bruker denne koden til å lese inn kommandolinja og gi samme tekst ut igjen:

import java.util.Scanner;

public class Test {
public static void main(String[] args) {
	Scanner scanner = new Scanner(System.in);
	while (scanner.hasNextLine()) {
		System.out.println(scanner.nextLine());
	}
}
}

 

Verdt å nevne er det at jeg kan bruke "\u00c5".getBytes("UTF-8") til å skrive ut en Å. Videre har jeg prøvd å sette inn følgende kode for å skrive ut bytene i hvert tegn:

 

try {
  for (byte c : scanner.nextLine().getBytes()) {
  System.out.println(Integer.toString(c));
  }
} catch (Exception e) {
  return;
}

 

For alle andre tegn enn Å kommer alle bytene ut (som tallverdier), men med Å-en kommer bare den ene byten ut. Æ gir -61 og -122, Ø gir -61 og -104, men å gir bare -61 (-123 mangler).

 

PS. Har prøvd å kjøre echo ÆØÅæøå > test.txt for å dobbeltsjekke at det ikke er terminalvinduet i Linux som skaper problemet – dette gikk uten problemer.

 

Er det noen som har peiling på hva dette skyldes?

Endret av 9E2
Lenke til kommentar
Videoannonse
Annonse

Både input og output foregår i MacRoman i Terminalen med OS X, men jeg konverterer fra standard tegnsett (MacRoman) til UTF-8 før jeg behandler teksten (i det egentlige programmet, ikke i testekoden over). Etterpå konverterer jeg tilbake fra UTF-8 til standardtegnsettet og sender ksten tilbake til terminalen. Dette virker helt fint. Skulle anta at det samme skulle virke på Linux (standardtegnsettet mener jeg er ISO-8859-1), men det blir som sagt problemer med Å. De andre tegneksemplene jeg gav i første post er typiske «problemtegn», men de virker fint her.

 

Litt lenge siden jeg var borti java selv, men tror du kan bruke:

 

use utf8;

use Unicode::Collate;

Hvor skal dette oppgis i så fall?

Endret av 9E2
Lenke til kommentar

Litt lenge siden jeg var borti java selv, men tror du kan bruke:

use utf8;

use Unicode::Collate;

Dette er jo for perl...?

Takker for oppklaring, det så litt ukjent ut.

 

To be able to type Swedish characters in Terminal, add the following lines to your ~/.inputrc (most likely you must create this file):

set input-meta on

set output-meta on

set convert-meta off

 

Dette er på OS X-maskinen.

Takk for tipset, men jeg fikk ikke dette til å virke. Derimot satte det meg på sporet av noe. Det viser seg at terminalen i Linux var satt til UTF-8, mens Java tydeligvis antar at det som kommer inn er ISO-8859-15. Videre viser det seg at det som er andre byte av Å i UTF-8 tilsvarer U+0085 (NEXT LINE). Det ser ut til at et eller annet sted tolkes halve Å som et tegn, mens andre halvdelen tolkes som ny linje.

 

Ser ut til at problemet løste seg ved at jeg bruker "UTF-8" som argument når jeg oppretter Scanner-objektet:

Scanner scanner = new Scanner(System.in, "UTF-8");

 

Jeg antok at dette var unødvendig på Linux ettersom UTF-8 var terminalens kodesett, men der tok jeg visst skammelig feil …

Lenke til kommentar

Assumption is the mother of all fuckups. ;)

 

Når det gjelder tegnkoding så må man aldri anta noe som helst. Aldri bruk default-koding når du oppretter objekter som lar seg påvirke av det, angi det eksplisitt. Som du selv har erfart, hva som er default varierer fra plattform til plattform. Jeg har selv i lag med kolleger sniffet ut hauger av skikkelig stygge bugs som kommer av nettopp slik. MD5 implementasjonen i Java bruker plattformens default tegnkoding når den hasher hvis ikke du eksplisitt ber den om noe annet, så en passordhash av et passord som inneholder norske tegn vil se annerledes ut på Linux og Windows. Noe som lager en del krøll for brukerne når applikasjonen flyttes fra Windows til nettopp Linux.

 

Vær eksplisitt! :)

Endret av henrikwl
Lenke til kommentar

Assumption is the mother of all fuckups. ;)

 

Når det gjelder tegnkoding så må man aldri anta noe som helst. Aldri bruk default-koding når du oppretter objekter som lar seg påvirke av det, angi det eksplisitt. Som du selv har erfart, hva som er default varierer fra plattform til plattform. Jeg har selv i lag med kolleger sniffet ut hauger av skikkelig stygge bugs som kommer av nettopp slik. MD5 implementasjonen i Java bruker plattformens default tegnkoding når den hasher hvis ikke du eksplisitt ber den om noe annet, så en passordhash av et passord som inneholder norske tegn vil se annerledes ut på Linux og Windows. Noe som lager en del krøll for brukerne når applikasjonen flyttes fra Windows til nettopp Linux.

 

Vær eksplisitt! :)

Dette er problemer jeg har vært borti alle steder jeg har vært. Spesifikt at det brukes implisitt culture-info. Siden jeg bor i norge, pleier jeg å sette til Norsk oppsett. Men flere steder har dette fått unit-tester til å feile fordi kode benyttet seg av eksplisitt format, men implisitt kultur, som mellom Norsk og US Amerikansk system vil få tall-parsing til å feile (USA bruker punktum som desimalskilletegn, Norge bruker komma)

 

Så jeg er utrolig enig i det du sier.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...