Bug #17226: JS escape/unescape functions are differently than PHPs urlencode functions when using utf8 in mysql DB - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #17226

closed

JS escape/unescape functions are differently than PHPs urlencode functions when using utf8 in mysql DB

Added by Guido Hinz over 17 years ago. Updated about 11 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Target version:

Start date:

2007-04-20

Due date:

% Done:

Estimated time:

TYPO3 Version:

4.1

PHP Version:

5.0

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

i think i have a bug like: http://bugs.typo3.org/view.php?id=277
i have created a formular and when i press the button "Absenden" then a validation bring f.i. a message where the name of the field is not correct.
when the field "error is here -> Straße, Hausnummer:" is enpty but required then the message box has problems with umlaut
for instance: the one character "ß" will display as the character "Ã" and a reverse "?".
my website with the formular is:
http://www.s15225426.onlinehome-server.info/index.php?id=71&no_cache=1

i have a configuration like http://lists.typo3.org/pipermail/typo3-german/2006-August/022170.html
but as operation system suse 9.3 (virtual host) and typo3 4.1.1

(issue imported from #M5468)

Files

bug_5468.diff (541 Bytes) bug_5468.diff

Administrator Admin, 2008-11-13 11:14

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Martin Kutschker over 17 years ago

JS escape() and unescape() are not fit for UTF8. In the old days they used to be character set ignorant (ie all bytes were escaped as-is), but nowadays a the data is converted from or to latin1 (iso-8859-1) before being escaped.

The safe way in modern browsers is to use encodeURIcomponent/decodeURIcomponent which operates on UTF8 data.

Actions

Copy link

Updated by Guido Hinz over 17 years ago

After i had replaced "unescape" with "decodeURIcomponent" in the file jsfunc.validateform.js the problem is solved (on my suse linux 10.1 system) while using the browser mozilla firefox or seamonkey. When using the browser Konqueror then the problem is not solved. other browser like ie i will test tomorrow.

I think the Problem is solved.

Actions

Copy link

Updated by Michael Stucki about 16 years ago

Important: It's not "decodeURIcomponent" but "decodeURIComponent" (upper-case "C"), otherwise it will fail at least on Firefox 3.

Attached is a patch that seems to solve the problem. However I would like Martin to give a feedback about it, as he is more familar with the topic.

How to reproduce/test:
1. Create a form that has form fields containing umlauts
2. Make the field required and don't fill it in

- michael

Actions

Copy link

Updated by Michael Stucki about 16 years ago

Masi, can you please take a look at this solution?
Thanks in advance!
- michael

Actions

Copy link

Updated by Steffen Kamper about 16 years ago

i can confirm that using decodeURIComponent solves the problem.

I think all "unescape" calls in core should be replaced by "decodeURIComponent" ("escape" as well)

Actions

Copy link

Updated by Michael Stucki about 16 years ago

Steffen, that is not the way I want this to be solved.
As far as I know, "decodeURIComponent" is not a successor of the "unescape" function, but provides a different way of encoding data which probably seems to work in this case. However, it may also introduce new problems at many places.

That's why I asked Masi for some feedback as he seems to be more familar with it already...

Actions

Copy link