kan ikke bruge æ ø og å

Du skal url-encode/decode med de respektive funktioner.
http://java.sun.com/j2se/1.3/docs/api/java/net/URLDecoder.html
http://java.sun.com/j2se/1.3/docs/api/java/net/URLEncoder.html

Så jeg skal altså inden jeg lægger i databasen dekode HTML-formatet, og inden jeg viser det på siden igen jeg lave det om til HTML-format igen?

Hvad så hvis data ikke er blevet lagt ind via websiden, men direkte via prompten i mysql?

Kender ikke myskel. Men det BURDE ikke være et problem hvis de overholder standarderne. Ellers må du lave et interface i Java til at lægge data ind i din dB. Det har jeg gjort.

Hmmm ok. Jeg synes bare det er ret lamt at jsp ikke kan finde ud af det selv. Det er da et kæmpe minus i forhold til andre serverscript-sprog.

det vil jeg medgive dig. jeg er heller ikke 100% sikker på om der er andre smartere måder at gøre det på. Alt andet lige er de to funktioner erklæret static så de skal ikke kaldes som instanser
URLDecoder.decode(resultSet.getString(2)); og
myQuery = "insert into varelager values '"+halnr+"', '"+URLEncoder.encode(varebeskr)+"';";

For en stød tid siden var der en der lavede en ganske fiks metode til at omsætte æ,ø,å til HTML entities.

og lad mig lige tilføje at et serverside sprog kan ikke umiddelbart bedømmes ud fra hvor let det er at gøre enkelte ting. I dette tilfælde er det givetvis lettere i andre sprog, men i takt med at opgavens omfang vokser bliver det objekt orienterede programmeringssprog altid overlegent i længden da der er større kodegenbrug.

Det har du ganske ret i, men jeg synes bare det er underligt at SUN ik har fået ordnet noget så simpelt som det problem, når jsp ellers er et så skidegodt sprog. Hmm....jeg lader lige spørgsmålet stå åbent en tid endnu for at se om der evt. er andre forslag :)

Det synes jeg faktisk er en bravo ide.
Personligt sætter jeg æ,ø,å osv ind som HTML entities. Frit fra hoften ser det vist sådan ud (er for doven til at finde koden frem)

public String toEntities(String input) {
  StringBuffer read = new StringBuffer(input.length()+input.length()/10); giver den 10% extra
  char[] inToArr = input.toCharArray();
  char current;
  for (int i=0; i!=inToArr.length: i++) {
  current = inToArr[i];
  switch (current) {
    case (current=='æ'):
      read.append("æ");
    break;
    case (current=='Æ'):
      read.append("Æ");
    break;
    case (current=='ø'):
      read.append("ø");
    break;
    case (current=='Ø'):
      read.append("Ø");
    break;
    case (current=='å'):
      read.append("å");
    break;
    case (current=='Å'):
      read.append("Å");
    break;
    case (current=='<'):
      read.append("&lt;");
    break;
    case (current=='>'):
      read.append("&gt;");
    break;
    case (current=='&'):
      read.append("&amp;");
    break;
    defualt:
      read.append(current);
    break;
  }
  return read.toString();
}

Det er frit fra hoften og 100% sikkert fuld af fejl.

Min erfaring med MySQL er, at når du sætter ind via web (dvs. via windows-browser) - så bliver der gemt i forhold til den encoding, som browseren bruger ... f.eks. ISO-1281 eller Unicode...

går du ud i MySQL's kommandoprompt(KP), derimod, så arbejder du udfra den encoding som (KP)/DOS bruger - dvs. normalt CodePage850...

Så derfor, hvis der indsættes tekst via KP så gemmes den i en anden encoding end når den så læses af windows igen :-)

Personligt mener jeg ikke, under alle omstændigheder, at det er godt at gemme i URLEncoding - da man derved tvinger de gemte data til kun at blive brugt i forbindelse med web ---

Men for at summere op : jeg har gemt et æ ø og å uden problemer i MySQL fra JSP - men haft lignende 'underlige tegn' når jeg har indsat testdata direkte fra kommandoprompten

/Søren Munk Skrøder

Ok ... takker for points... Men... URLEncoder du, eller gør du ikke ?

/Søren