[
https://issues.apache.org/jira/browse/OFBIZ-13168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897690#comment-17897690
]
Jacques Le Roux commented on OFBIZ-13168:
-----------------------------------------
{quote}We may have a misunderstanding here, the initial issue is that all
digits after a NBSPs are ripped off the string, not that a space as thousand
separator is removed.
{quote}
Thanks for clarifying, and the link to "unicode text analyser" that was quite
helpful.
The confusion came from the title of
[https://github.com/apache/ofbiz-framework/pull/849]
{quote}Improved: Replace all non 'alnum'/non 'punct' chars by spaces in numeric
fields
{quote}
And the code itself replaces by space not by an empty string. Anyway I get it
now. As, for the sake of clarity, I believe we should rather replace by an
empty string, I'll do so.
So it works on Ubuntu and WIn7. I mean after entering "255 000" with a NBSP in,
I get "255000".
On WIn7 the test passes and I can see the NBSP (and NNBSP you put in a comment
above) in Notepad++. So I can copy from there, as here: {{"29 000" or "255
000"}}
So I'll now push that: [^845.patch]
I'll just change in comment "by normal spaces" by "by an empty string". Even if
I understant that later the space is removed (by NumberFormat I guess)
> String to numeric conversion does not support non-breaking spaces
> -----------------------------------------------------------------
>
> Key: OFBIZ-13168
> URL: https://issues.apache.org/jira/browse/OFBIZ-13168
> Project: OFBiz
> Issue Type: Bug
> Components: ALL COMPONENTS
> Affects Versions: 18.12.16, Upcoming Branch
> Reporter: Florian Motteau
> Assignee: Jacques Le Roux
> Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: 845.patch, Image 025.png, Image 026.png, Image 029.png,
> Image 030.png, Peek 05-11-2024 10-59.mp4, Peek 12-11-2024 12-16.mp4,
> image-2024-11-05-11-01-13-030.png, image-2024-11-12-09-55-16-578.png
>
>
> When submitting a form with numeric values, OFBiz uses a text input (`<input
> type="text"/>`), so all characters (entered by hand or pasted) are allowed in
> the input.
> On form's submission, for numeric fields, the string is parsed using
> `java.text.NumberFormat` class (parse method), using a number instance
> formatter.
> This formatter does not supports non-breaking spaces ('\u00A0', '\u202F',
> '\u2007'), and characters after a non-breaking space are ignored :
> !image-2024-11-05-11-01-13-030.png|width=337,height=153!
> This can lead to a situation where a visually correct form stores wrong
> values :
> [^Peek 05-11-2024 10-59.mp4]
> One of our client reported this situation while pasting values from external
> tools. Some values where truncated, because the external tool used
> non-breaking spaces when displaying values.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
