🚀 go-pugleaf

Ok, I will let you know if I get some more insights related to these
character encoding issues.

BTW, during our discussion I remembered that I once had build a little
character map helper OT. So I searched through my backup archives and found
it amoung my older personal created OTs. This character map OT can be used
as a little helper  for such character related things from inside JB. - I've
updated it yesterday slightly for JB4 and placed it now also onto
CodeCentral, just in case others also have a need for such an OT.


Greetings Valentino


"Torsten Welches" <torsten.welches@who.cares.netcologne.de> schrieb im
Newsbeitrag news:3acee46c_2@dnews...
> Valentino,
>
> As I understand it there are three different "encoding forms"
(UTF-8/16/32)
> that can be converted without a problem - '&' will be Unicode 0x26 in all
> encoding forms.
> But you might want to delve into the details:
> http://www.unicode.org/unicode/standard/principles.html
>
> Let us know what you find!
>
> Torsten
>
>
>
> Valentino Kyriakides schrieb in Nachricht <3acddcb6_2@dnews>...
> >I thought about foreign people (from other countries or which may use for
> >example IE, Netscape etc. with other default language settings - russian,
> >greek etc.- or keyboard character mappings...). AFAIK, there are also
> >different Unicode pages available and If people type something into text
> >fields of our customers online shop and the characters from their
mappings
> >aren't recognized by our Java serverside input validation classes, they
> >would never pass the server side validation and so they can't place any
> >orders or even login into the shop system.
> >
> >I must be sure that the above scenario can't happen! - Otherwise we have
to
> >take other approaches.
>
>
>