Bug #4155
closed[3.3.4] Binding UTF8 Strings
0%
Description
After updating from 3.3.3 to 3.3.4 all of the following do not work anymore:
bindString( "title", Wt::WString::tr( "some-key" ) );
bindString( "title", "äöüß@[]{}¹²³¢¥" );
bindString( "title", Wt::WString( "äöüß@[]{}¹²³¢¥", Wt::UTF8 ) );
bindString( "title", Wt::WString::fromUTF8( "äöüß@[]{}¹²³¢¥" ) );
Instead I get this message and a lot of "?" in my output: "WString: narrow(): loss of detail: @[]{}?"
Using a WText or specifying a string in a xml-template with {tr:key} works fine (but should not be required).
bindWidget( "title", new Wt::WText( Wt::WString::fromUTF8("äöüß@[]{}¹²³¢¥") ) );
I know that there can be issues with using UTF8 encoded strings in C itself (like in the 3 examples above), but even the first example does not display the value for "some-key" correctly (it's just the same string in an xml resource file).
(Already asked here - no answer so far: http://redmine.webtoolkit.eu/boards/2/topics/10764)
Files
Updated by Stefan Arndt over 9 years ago
- File main.cpp main.cpp added
- File content.xml content.xml added
Some updates from my side.
Today I wrote a small test app to reproduces the issue. See the attached files.
The app has then tested been tested on a Mac and it worked like expected. I decided to downgraded my own system to wt 3.3.3 and see if it works - and it did.
On my Arch Linux setup I had to downgrade the following packages to get wt working again:
wt from 3.3.4-4 to 3.3.3-6
boost and boost-lib from 1.58-2 to 1.57-3
icu from 55.1-1 to 54.1-1
The Mac runs the following:
custom build (21.11.2014) Wt. 3.3.4-rc1
boost 1.54
(icu4c maybe at most 54.1)
I will start digging around and see if I can find anything.
PS: test output on my Arch Linux:
??? : directly from code
??? : from UTF8
??? : translate()
äöü : WText(fromUTF8)
??? : L""
äöü : xml {tr}
äöü : xml
Updated by Stefan Arndt over 9 years ago
I just cloned the master branch and tested the current state. And it seems to work just fine. Maybe you already fixed the bug for 3.3.5. Let's just wait for the official package now.
Updated by Koen Deforche over 9 years ago
- Status changed from New to Resolved
- Assignee set to Koen Deforche
- Target version set to 3.3.5
Indeed we fixed something related to binding of strings in templates which may explain this bug too.
Updated by Koen Deforche about 9 years ago
- Status changed from Resolved to Closed