Bug #15510

UTF-8 sites display garbled chars in select-fields (in BE)

Added by Ernesto Baschny almost 14 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2006-01-26
Due date:
% Done:

0%

TYPO3 Version:
4.1
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Steps to reproduce (TCEforms):

1) Set forceCharSet = utf-8.
2) Login to the backend, create a usergroup called "ÄÄÄ" (or any other non-ascii-char)
3) Create a user and add the group to the user (clicking on the right box). Upon adding, the group-name is add correctly to the left box.
4) Save the form and look at the result. Instead of "ÄÄÄ" you have a 6 bytes-string

Other place where it occurs (flexforms):

1) Set forceCharSet = utf-8.
2) Add tt_news extension
3) Create a News Category called "ÖÖÖ"
4) Add a News-Plugin as a content element, and tell it to display only elements in the category "ÖÖÖ".
5) Save and look at the displayed value in the left category box, its garbled again.

The attached minor patch (to latest 4.0-CVS) seems to solve it. But I think more thinking has to be done here.

The only change the patch does is that LANG->sL() won't try to convert from the encoding specified for the current users language (e.g. iso-latin-1) to UTF-8. In the case of values coming from the DB, they are already UTF-8, so this would cause double-encoding.

There might be side-effects, because sL() is also used for the "language-splitted" labels, but they are obsolete anyway. And I cannot imagine any latin-1 encoded string to enter this part of the function if the site is set to forceCharSet=utf8.

Non-forceCharSet-sites aren't affected by this change, because hscAndCharConv won't don anything other than htmlspecialchars, which I still do in my change.

Initially reported for TYPO3 4.0
(issue imported from #M2396)

utf8-forms-2006-01-26.diff View (792 Bytes) Administrator Admin, 2006-01-26 16:50

bug_2396_2006-01-30.diff View (1.99 KB) Administrator Admin, 2006-01-30 21:58


Related issues

Related to TYPO3 Core - Bug #14848: utf-8 data gets converted to utf-8 again under MySQL 4.1.11 Closed 2005-07-05

History

#1 Updated by Tomas Mrozek almost 14 years ago

The problem occurs even in older versions of Typo3 (I can confirm version 3.8.1). Manually applying changes from the attached patch utf8-forms-2006-01-26.diff solves the problem.

#2 Updated by Jorgo S. almost 14 years ago

Please check if there is a relation to this bug: http://bugs.typo3.org/view.php?id=1262

#3 Updated by Tomas Mrozek almost 14 years ago

Ernesto Baschny mentions 2 multiple select boxes in his bug description.
I just noticed that there is another (different though similar in nature) problem with "page browser" (browser used for choosing pages, for example for choosing "Single-view page" when editing tt_news categories).
When the page is clicked in the page browser, it is inserted into the input field with broken characters. As soon as the category is saved the text in the input filed becomes alright.

#4 Updated by Alexandre Bourget about 12 years ago

I'm still having this problem with Typo3 v4.1.2.

Every time I get one of those "category selection" forms, I get broken UTF-8 rendering. It happens in tt_news Category selection and in the 'cal' calendar category selection.

I have forceCharset = utf-8

Was this bug fixed at some point ?

#5 Updated by Markus Klein almost 8 years ago

  • Target version deleted (0)

Is this still valid?

#6 Updated by Stefan Galinski almost 8 years ago

  • Status changed from New to Needs Feedback

#7 Updated by Jigal van Hemert almost 7 years ago

  • Status changed from Needs Feedback to Closed

Can't be reproduced. Now that the complete core and BE are UTF-8 in all supported versions, this can't be a problem anymore. Closed.

Also available in: Atom PDF