---

Kære Allan

Jeg har problemer med læsning af beløb.

Eksempel:
jeg har et beløb på 13000, som jeg gerne vil have præsenteret på norsk.
Det bliver vist som 13 000 i et form-felt.
Men når jeg så genindlæser værdien, så får jeg 13

Præsentationskildetekst i en <form> i min JSP:
NumberFormat numberFormatter;
numberFormatter = NumberFormat.getNumberInstance(norsk);
<%=numberFormatter.format(price)%>
Og det går fint nok.

Indlæsningskildetekst i min servlet:
String p_price = request.getParameter("price");
double price = parseDouble(p_price, norsk);
Og det går ikke så godt.

Hvordan læser I beløb fra en form?

Med venlig hilsen
Allan

---

Allan Unnerup wrote:
> jeg har et beløb på 13000, som jeg gerne vil have præsenteret på norsk.
> Det bliver vist som 13 000 i et form-felt.
> Men når jeg så genindlæser værdien, så får jeg 13
>
> Præsentationskildetekst i en <form> i min JSP:
> NumberFormat numberFormatter;
> numberFormatter = NumberFormat.getNumberInstance(norsk);
> <%=numberFormatter.format(price)%>
> Og det går fint nok.
>
> Indlæsningskildetekst i min servlet:
> String p_price = request.getParameter("price");
> double price = parseDouble(p_price, norsk);
> Og det går ikke så godt.

parseDouble metoden i din servlet - hvad gør den ?

Arne

---

Den kommer her:

private double parseDouble(String s, Locale loc) {
if (s==null) return 0.0;
double res = 0;
try {
Number number = NumberFormat.getNumberInstance(loc).parse(s);
if (number instanceof Long) {
res = number.longValue(); // Long value
} else {
res = number.doubleValue(); // Double value
}
} catch (ParseException nfe) {
}
return res;
}


"Arne Vajhøj" <arne@vajhoej.dk> skrev i en meddelelse
news:cJQbg.31272$fG3.12140@dukeread09...
> Allan Unnerup wrote:
> > jeg har et beløb på 13000, som jeg gerne vil have præsenteret på norsk.
> > Det bliver vist som 13 000 i et form-felt.
> > Men når jeg så genindlæser værdien, så får jeg 13
> >
> > Præsentationskildetekst i en <form> i min JSP:
> > NumberFormat numberFormatter;
> > numberFormatter = NumberFormat.getNumberInstance(norsk);
> > <%=numberFormatter.format(price)%>
> > Og det går fint nok.
> >
> > Indlæsningskildetekst i min servlet:
> > String p_price = request.getParameter("price");
> > double price = parseDouble(p_price, norsk);
> > Og det går ikke så godt.
>
> parseDouble metoden i din servlet - hvad gør den ?
>
> Arne

---

Allan Unnerup wrote:
> private double parseDouble(String s, Locale loc) {
> if (s==null) return 0.0;
> double res = 0;
> try {
> Number number = NumberFormat.getNumberInstance(loc).parse(s);
> if (number instanceof Long) {
> res = number.longValue(); // Long value
> } else {
> res = number.doubleValue(); // Double value
> }
> } catch (ParseException nfe) {
> }
> return res;
> }

Prøv og udskriv/log noget ved exception.

Arne

---

"Arne Vajhøj" <arne@vajhoej.dk> skrev i en meddelelse
news:P1seg.33877$fG3.33836@dukeread09...
> Allan Unnerup wrote:
> > private double parseDouble(String s, Locale loc) {
> > if (s==null) return 0.0;
> > double res = 0;
> > try {
> > Number number = NumberFormat.getNumberInstance(loc).parse(s);
> > if (number instanceof Long) {
> > res = number.longValue(); // Long value
> > } else {
> > res = number.doubleValue(); // Double value
> > }
> > } catch (ParseException nfe) {
> > }
> > return res;
> > }
>
> Prøv og udskriv/log noget ved exception.
>
Hvis der er exception, så er res ved lig 0, og det er jo ikke tilfældet.
"12 345" bliver jo til 12

---

Allan Unnerup wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> skrev i en meddelelse
> news:P1seg.33877$fG3.33836@dukeread09...
>> Allan Unnerup wrote:
>>> private double parseDouble(String s, Locale loc) {
>>> if (s==null) return 0.0;
>>> double res = 0;
>>> try {
>>> Number number = NumberFormat.getNumberInstance(loc).parse(s);
>>> if (number instanceof Long) {
>>> res = number.longValue(); // Long value
>>> } else {
>>> res = number.doubleValue(); // Double value
>>> }
>>> } catch (ParseException nfe) {
>>> }
>>> return res;
>>> }

>> Prøv og udskriv/log noget ved exception.

> Hvis der er exception, så er res ved lig 0, og det er jo ikke tilfældet.
> "12 345" bliver jo til 12

Jeg er en skeptisk type !

Men jeg har eksperimenteret lidt og jeg har fundet
ud af noget.

Norwegian format genererer ikke et space (kode 32) men
et non breaking space (kode 160). Logisk nok.

Norwegian parse virker med non breaking space.

Men norwegian parse giver den beskrevne fejl, hvis
det er en almindelig space eller hvis det non
breaking space er blevet til 2 bogstaver p.g.a.
ISO-8859-1 versus UTF-8 problemer.

Så prøv og udskriv/log koderne for alle tegn i
den streng som du parser.

Det skal være 48 49 160 50 51 52.

48 49 32 50 51 52 betyder at der er konverteret
fra non breaking space til almindelig space.

48 49 194 160 50 51 52 betyder tegnsæts problemer.

Arne

---

Arne Vajhøj wrote:
> Men jeg har eksperimenteret lidt og jeg har fundet
> ud af noget.
>
> Norwegian format genererer ikke et space (kode 32) men
> et non breaking space (kode 160). Logisk nok.
>
> Norwegian parse virker med non breaking space.
>
> Men norwegian parse giver den beskrevne fejl, hvis
> det er en almindelig space eller hvis det non
> breaking space er blevet til 2 bogstaver p.g.a.
> ISO-8859-1 versus UTF-8 problemer.
>
> Så prøv og udskriv/log koderne for alle tegn i
> den streng som du parser.
>
> Det skal være 48 49 160 50 51 52.
>
> 48 49 32 50 51 52 betyder at der er konverteret
> fra non breaking space til almindelig space.
>
> 48 49 194 160 50 51 52 betyder tegnsæts problemer.

Har du fået prøvet det ?

mvh/Arne

---

Hej Arne

> > Så prøv og udskriv/log koderne for alle tegn i
> > den streng som du parser.
> >
> > Det skal være 48 49 160 50 51 52.
> >
> > 48 49 32 50 51 52 betyder at der er konverteret
> > fra non breaking space til almindelig space.
> >
> > 48 49 194 160 50 51 52 betyder tegnsæts problemer.
>
> Har du fået prøvet det ?
>

Desværre ikke endnu, jeg har lige fået at par andre ting at tænke på.
Jeg skal nok vende tilbage.

Med venlig hilsen
Allan

---

> Norwegian format genererer ikke et space (kode 32) men
> et non breaking space (kode 160). Logisk nok.
>
> Norwegian parse virker med non breaking space.
>
> Men norwegian parse giver den beskrevne fejl, hvis
> det er en almindelig space eller hvis det non
> breaking space er blevet til 2 bogstaver p.g.a.
> ISO-8859-1 versus UTF-8 problemer.
>
> Så prøv og udskriv/log koderne for alle tegn i
> den streng som du parser.
>
> Det skal være 48 49 160 50 51 52.
>
> 48 49 32 50 51 52 betyder at der er konverteret
> fra non breaking space til almindelig space.
>
> 48 49 194 160 50 51 52 betyder tegnsæts problemer.
>
Så er det endelig lykkedes mig at forfølge dit forslag. Og du har ganske
ret!

12345 bliver - som i din test - konverteret til 48 49 160 50 51 52.
Det bliver præsenteret i min <form> som "12 345".

Når tallet "12 345" sendes til min servlet og hentes via
request.getParameter(), bliver det modtaget som 48 49 32 50 51 52

Ok. Nu er problemet lokaliseret (undskyld

Og for så at vende tilbage til det oprindelige spørgsmål: "Hvordan læser I
beløb fra en form?"

For at undgå tilsvarende problemer i en URL, så er tekmikken at
encode/decode sig ud af problemerne. Hvordan gør man i praksis med felter i
en form?

Hvis man skal gøre tilsvarende, så skal jeg jo escape en værdi INDEN det
vises i formen! Det lyder ikke sundt.

- Allan

---

"Allan Unnerup" <alu@udkik.dk> writes:

> For at undgå tilsvarende problemer i en URL, så er tekmikken at
> encode/decode sig ud af problemerne. Hvordan gør man i praksis med felter i
> en form?

Du giver hvert felt et navn, og når submit-JSPen er kaldt ligger den
tilsvarende værdi i ${param} så vidt jeg husker.

Check JSP/Servlet referencen fra Sun.

Min erfaring er at det skal ikke meget over det absolut trivielle før
det kan betale sig at sætte sig ind i et framework til formålet. Java
Servlet Faces er nok det bedste bud i dag.
--
Thorbjørn Ravn Andersen

---

"Thorbjørn Ravn Andersen" <nospam0000@gmail.com> skrev i en meddelelse
news:yu28xmnz3wn.fsf@luhmann.netc.dk...
> "Allan Unnerup" <alu@udkik.dk> writes:
>
> > For at undgå tilsvarende problemer i en URL, så er tekmikken at
> > encode/decode sig ud af problemerne. Hvordan gør man i praksis med
felter i
> > en form?
>
> Du giver hvert felt et navn, og når submit-JSPen er kaldt ligger den
> tilsvarende værdi i ${param} så vidt jeg husker.

Jeg er ikke helt med.
Når du skriver "submit-JSPen", mener du så den JSP, som form'en er placeret
i, eller er det den servlet, der refereres til i min <form action=*her*...>?

> Check JSP/Servlet referencen fra Sun.
>
> Min erfaring er at det skal ikke meget over det absolut trivielle før
> det kan betale sig at sætte sig ind i et framework til formålet. Java
> Servlet Faces er nok det bedste bud i dag.

Nu har jeg omkring 125 JSPer og 50 servlets samt et hjemmestrikket primitivt
framework, så hvis jeg skal ud i en konvertering, skal det resultere i en
*væsentlig* forbedring.

Med venlig hilsen
Allan

---

"Allan Unnerup" <alu@udkik.dk> writes:

> Når du skriver "submit-JSPen", mener du så den JSP, som form'en er placeret
> i, eller er det den servlet, der refereres til i min <form action=*her*...>?

Den servlet/JSP der sendes _til_ når der submittes.

Jeg submitter aldrig til en servlet, man får så meget foræret i JSP
2.0 at det slet ikke kan betale sig andet.

> Nu har jeg omkring 125 JSPer og 50 servlets samt et hjemmestrikket primitivt
> framework, så hvis jeg skal ud i en konvertering, skal det resultere i en
> *væsentlig* forbedring.

Been there done that

Overvej det til næste projekt

--
Thorbjørn Ravn Andersen

---

Allan Unnerup wrote:
> Så er det endelig lykkedes mig at forfølge dit forslag. Og du har ganske
> ret!
>
> 12345 bliver - som i din test - konverteret til 48 49 160 50 51 52.
> Det bliver præsenteret i min <form> som "12 345".
>
> Når tallet "12 345" sendes til min servlet og hentes via
> request.getParameter(), bliver det modtaget som 48 49 32 50 51 52
>
> Ok. Nu er problemet lokaliseret (undskyld
>
> Og for så at vende tilbage til det oprindelige spørgsmål: "Hvordan læser I
> beløb fra en form?"
>
> For at undgå tilsvarende problemer i en URL, så er tekmikken at
> encode/decode sig ud af problemerne. Hvordan gør man i praksis med felter i
> en form?
>
> Hvis man skal gøre tilsvarende, så skal jeg jo escape en værdi INDEN det
> vises i formen! Det lyder ikke sundt.

Form felter burde automatisk blive URL encoded.

Men vil det være et problem at lave en .replaceAll(" ","")
på data inden du parser ?

Arne

---

> >
> > Når tallet "12 345" sendes til min servlet og hentes via
> > request.getParameter(), bliver det modtaget som 48 49 32 50 51 52
> >
> Men vil det være et problem at lave en .replaceAll(" ","")
> på data inden du parser ?
>
Tanken har strejfet mig, og det er måske også den løsning jeg vælger, men
jeg synes, at det er en lappeløsning.

Jeg forsøger af finde "den rigtige løsning". Og jeg forestiller mig, at når
nu SUN nu har gjort så meget ud af I18N, så må der være en standardløsning
på dette problem. Det kan ikke være rigtigt, at jeg skal til at fjerne
blanktegn selv.

Det er ikke nogen principsag for mig, men jeg forestiller mig, at det ikke
kun er blanktegnet, der er problemet. Senere opdager jeg måske et andet
problem med en anden localisation, og så skal jeg også til at lave en
lappeløsning for dette problem.

Jeg vil hellere bruge noget ekstra tid nu og så - forbåbentlig - finde den
rigtige løsning.

Med venlig hilsen
Allan

---

Allan Unnerup wrote:
>> Men vil det være et problem at lave en .replaceAll(" ","")
>> på data inden du parser ?
>>
> Tanken har strejfet mig, og det er måske også den løsning jeg vælger, men
> jeg synes, at det er en lappeløsning.
>
> Jeg forsøger af finde "den rigtige løsning". Og jeg forestiller mig, at når
> nu SUN nu har gjort så meget ud af I18N, så må der være en standardløsning
> på dette problem. Det kan ikke være rigtigt, at jeg skal til at fjerne
> blanktegn selv.
>
> Det er ikke nogen principsag for mig, men jeg forestiller mig, at det ikke
> kun er blanktegnet, der er problemet. Senere opdager jeg måske et andet
> problem med en anden localisation, og så skal jeg også til at lave en
> lappeløsning for dette problem.
>
> Jeg vil hellere bruge noget ekstra tid nu og så - forbåbentlig - finde den
> rigtige løsning.

Jeg tror ikke at du kan lave en pæn løsning.

Fordi så vidt jeg kan se er det browser specifikt.

Jeg lavede en lille test.

<%
if(request.getMethod().equals("POST")) {
String f = request.getParameter("f");
out.println((int)f.charAt(1) + "<br>");
}
%>
<form method="POST">
<input type="TEXT" name="f" value="<%=new String(new char[] { 'X',
'\u00A0', 'X' })%>">
<br>
<input type="SUBMIT" value="Test">
</form>

IE 6 giver 160

FF 1.5 giver 32

Det kan JSP altså ikke løse.

Så jeg tror at du skal følge det gamle råd for internet:

"Be liberal in what you accept, and conservative in what you send"

Arne

---

> > Jeg vil hellere bruge noget ekstra tid nu og så - forbåbentlig - finde
den
> > rigtige løsning.
>
> Jeg tror ikke at du kan lave en pæn løsning.
>
> Fordi så vidt jeg kan se er det browser specifikt.

Dette er den "pæneste" løsning jeg kunne finde på.

<snip>
numberFormatter.setGroupingUsed(false);
</snip>

12345,67 bliver på norsk vist som 12345,67 og ikke som 12 345,67
Og så er jeg ude over browserinkompatibiliteter.

Jeg vil benytte setGroupingUsed(false) i felter, hvor brugeren har mulighed
for at opdatere værdien og setGroupingUsed(true) ved rene
præsentationsfelter.

Med venlig hilsen
Allan

---

"Allan Unnerup" <alu@udkik.dk> writes:

> > > private double parseDouble(String s, Locale loc) {
> > > if (s==null) return 0.0;
> > > double res = 0;
> > > try {
> > > Number number = NumberFormat.getNumberInstance(loc).parse(s);
> > > if (number instanceof Long) {
> > > res = number.longValue(); // Long value
> > > } else {
> > > res = number.doubleValue(); // Double value
> > > }
> > > } catch (ParseException nfe) {
> > > }
> > > return res;
> > > }
> >
> > Prøv og udskriv/log noget ved exception.
> >
> Hvis der er exception, så er res ved lig 0, og det er jo ikke tilfældet.
> "12 345" bliver jo til 12

Koden ligner grangiveligt noget du har sakset et sted. Det jeg nu
kunne tænke mig at vide er hvilket Locale du sender ned, og om det
forstår det format du gerne vil spise.

--
Thorbjørn Ravn Andersen

---

"Thorbjørn Ravn Andersen" <nospam0000@gmail.com> skrev i en meddelelse
news:yu2k684s33u.fsf@luhmann.netc.dk...
> "Allan Unnerup" <alu@udkik.dk> writes:
>
> > > > private double parseDouble(String s, Locale loc) {
> > > > if (s==null) return 0.0;
> > > > double res = 0;
> > > > try {
> > > > Number number = NumberFormat.getNumberInstance(loc).parse(s);
> > > > if (number instanceof Long) {
> > > > res = number.longValue(); // Long value
> > > > } else {
> > > > res = number.doubleValue(); // Double value
> > > > }
> > > > } catch (ParseException nfe) {
> > > > }
> > > > return res;
> > > > }
> > >
> > > Prøv og udskriv/log noget ved exception.
> > >
> > Hvis der er exception, så er res ved lig 0, og det er jo ikke tilfældet.
> > "12 345" bliver jo til 12
>
> Koden ligner grangiveligt noget du har sakset et sted. Det jeg nu
> kunne tænke mig at vide er hvilket Locale du sender ned, og om det
> forstår det format du gerne vil spise.
>

Jeg skal ikke afvise, at det ligner en sakset kode (jeg er ikke bekendt med,
at der er specielle kendetegn ved sakset kode), men jeg kan forsikre dig, at
den er hjemmelavet fra ende til anden.

Den benyttede lokale er "no_NO", og den konverterer jo fint nok fra 12345
til "12 345" (Se andetsteds i tråden)

---

"Allan Unnerup" <alu@udkik.dk> writes:

> Den benyttede lokale er "no_NO", og den konverterer jo fint nok fra 12345
> til "12 345" (Se andetsteds i tråden)

Det er jo den anden vej rundt.

Det foresvævede mig at der andetsteds i tråden var et løsningsforslag.

Personligt ville jeg i din situation sætte Eclipse op til at afvikle
dit program i en JDK (fordi så kan den hitte kildeteksten) og så se på
den præcise implementation af den parse(s) du kører med dit Locale.
Det kan tit give en aha oplevelse.

Det kræver naturligvis at du må kigge i Suns kode (licensbetingelser
mv). Her er det måske en fordel at bruge Java 1.6.

--
Thorbjørn Ravn Andersen

---

"Thorbjørn Ravn Andersen" <nospam0000@gmail.com> skrev i en meddelelse
news:yu2u0772ni8.fsf@luhmann.netc.dk...
> "Allan Unnerup" <alu@udkik.dk> writes:
>
> > Den benyttede lokale er "no_NO", og den konverterer jo fint nok fra
12345
> > til "12 345" (Se andetsteds i tråden)
>
> Det er jo den anden vej rundt.

1. Du insinuerede, at jeg havde stjålet koden.
2. Du ville gerne vide, hvilken lokale jeg benyttede.
3. Du ville vide om formatet blev forstået.

Det var det jeg svarede på..

> Det foresvævede mig at der andetsteds i tråden var et løsningsforslag.

Jeg kan bekræfte din foresvævelse.

> Personligt ville jeg i din situation sætte Eclipse op til at afvikle
> dit program i en JDK (fordi så kan den hitte kildeteksten) og så se på
> den præcise implementation af den parse(s) du kører med dit Locale.
> Det kan tit give en aha oplevelse.

Det vil jeg gøre. Indtil nu har jeg bare benyttet en almindelig teksteditor.

> Det kræver naturligvis at du må kigge i Suns kode (licensbetingelser
> mv). Her er det måske en fordel at bruge Java 1.6.

Jeg er desværre nødt til at benytte den version, som min udbyder (Levonline)
benytter.

Med venlig hilsen
Allan

---

Allan Unnerup skrev den 05-06-2006 11:17

> 1. Du insinuerede, at jeg havde stjålet koden.

Næ, jeg sagde det lignede klippe-klistre kode - hvilket i min verden er
helt ok, man skal jo have noget til at virke[1] - og sådan kode kan der
være skjulte fejlmuligheder i da man ikke er 100% klar over hvad den gør.

Du kan derfor godt pakke den småfornærmede tone væk, tak.

--
Thorbjørn

[1] http://javaalmanac.com/ har mange gode ting.

---

"Thorbjørn Ravn Andersen" <nospam0000@gmail.com> skrev i en meddelelse
news:44841079$0$15782$14726298@news.sunsite.dk...
Allan Unnerup skrev den 05-06-2006 11:17

>> 1. Du insinuerede, at jeg havde stjålet koden.

>Næ, jeg sagde det lignede klippe-klistre kode

Du kan kalde det, hvad du vil. Det er stadig at stjæle!

> - hvilket i min verden er helt ok,

Det kan jeg forstå. Det er ikke ok i min verden.

> Du kan derfor godt pakke den småfornærmede tone væk, tak.

Jeg svarer i den tone, det passer mig.

Med venlig hilsen
Allan

---

"Allan Unnerup" <alu@udkik.dk> writes:

> >> 1. Du insinuerede, at jeg havde stjålet koden.
>
> >Næ, jeg sagde det lignede klippe-klistre kode
>
> Du kan kalde det, hvad du vil. Det er stadig at stjæle!

Det afhænger da så sandelig af den oprindelige kodes licens.

Er det ok med licensen (fx for X11 licensen) så er det da ligefrem
dumt ikke at bruge kode der allerede er lavet, testet og som løser
problemet.

> > Du kan derfor godt pakke den småfornærmede tone væk, tak.
>
> Jeg svarer i den tone, det passer mig.

Det er bare i orden.

Håber du får løst dine problemer tilfredsstillende.
--
Thorbjørn Ravn Andersen