HTML5 Data Bindings Formatter Support Product Page
In progress
Names/words with accent characters don't display correctly
Reported 18 Feb 2015 22:50:32
1
has this problem
18 Feb 2015 22:50:32 Steve Skinner posted:
I have a client site where words and names that have accented characters don't display correctly when dynamic data is displayed from the database using HTML5 Data Bindings. I know this is an issue with this extension because I hadn't run into this problem before with regular recordsets or static text. For example.... the name Ramón. The accented character (o acute) is entered into the CMS like this: Ramón. It looks weird to store it this way on the back end for my customer, but they've always understood that doing it this way will make it display correctly on the front end, and it always has. However, I'm not updating several aspects of their site and now since I've been using HTML5 Data Bindings, I can't get this name to display correctly.
I even typed the name in static on the same page where it isn't getting displayed correctly to test. and it works fine (Ramón in the code gets output as Ramón).
The page was originally created with:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
... and I also tried:
<!doctype html> <html>
Neither helped.
I'm hoping you have a suggestion on using HTML Formatter or something. I just couldn't figure out what would fix it. :-D
Replies
Replied 19 Feb 2015 09:06:27
19 Feb 2015 09:06:27 Teodor Kuduschiev replied:
Hi Steve,
The fact that until now you had to store "ó" as "&oa" in the database does not mean that there is a problem with our extension now, as it should not be stored like that by the user.
1. What method do you use to insert the data into your database?
2. What is your database encoding and what is your database table collation?
The fact that until now you had to store "ó" as "&oa" in the database does not mean that there is a problem with our extension now, as it should not be stored like that by the user.
1. What method do you use to insert the data into your database?
2. What is your database encoding and what is your database table collation?
Replied 19 Feb 2015 14:20:51
19 Feb 2015 14:20:51 Steve Skinner replied:
My mistake then. I only thought it might have something to do with the extension since before using it, I never had this problem, which is also why I have no idea about the database table collation. It's just not something I ever had to solve before.
Prior to using HTML5 DB to bring content to the screen from the database, I've used regular DW recordsets. Inserting data into the database has been done with a form that submits data to the db via DW insert and update behaviors.
How do I view db encoding and table collation info? I use Navicat to modify the database - would that software give me that information or should I just ask the web host?
Prior to using HTML5 DB to bring content to the screen from the database, I've used regular DW recordsets. Inserting data into the database has been done with a form that submits data to the db via DW insert and update behaviors.
How do I view db encoding and table collation info? I use Navicat to modify the database - would that software give me that information or should I just ask the web host?
Replied 19 Feb 2015 14:38:50
19 Feb 2015 14:38:50 Teodor Kuduschiev replied:
In order to display accented/unicode chars properly, you need to have the database table charset/collation set to utf8/utf8_general_ci
The most common problem with storing unicode chars is either your data in the DB is not stored as UTF-8 or
isn't transferred as that to your script. Or both.
With the DW server behaviors, this can be solved by setting this in the connection file:
SET NAMES 'utf8';
This sets the connection encoding between the DB and your script.
Screenshot:
Full size: prntscr.com/6748ex
This way you do not need to save "ó" as "&oa" ... but just like "ó", the script and the database will then display it properly.
Using HTML5 Data Bindings and DMXzone Database Updater, the script is sending the data as utf-8, so no such problems appear.
The most common problem with storing unicode chars is either your data in the DB is not stored as UTF-8 or
isn't transferred as that to your script. Or both.
With the DW server behaviors, this can be solved by setting this in the connection file:
SET NAMES 'utf8';
This sets the connection encoding between the DB and your script.
Screenshot:
Full size: prntscr.com/6748ex
This way you do not need to save "ó" as "&oa" ... but just like "ó", the script and the database will then display it properly.
Using HTML5 Data Bindings and DMXzone Database Updater, the script is sending the data as utf-8, so no such problems appear.
Replied 19 Feb 2015 15:15:06
19 Feb 2015 15:15:06 Steve Skinner replied:
The problem is that I cannot used your database updater to store the data to the db because the form includes a file upload and resize. So I have to do it old school until you come up with a new solution for upload and resize that works with your db updater. So, I guess I'll try the db connection file solution with the set names that you suggested.
The other solution that works is to not use HTML5 DB to display the data on the front end, but that wouldn't be my first choice. I thought I could use the formatter extension on the first name field to detect Ramon and replace it with the same name including the o acute character, but I couldn't figure out how to get that work either. It's just this one guy's name where this problem comes up, but he's mentioned in several places throughout the site.
The other solution that works is to not use HTML5 DB to display the data on the front end, but that wouldn't be my first choice. I thought I could use the formatter extension on the first name field to detect Ramon and replace it with the same name including the o acute character, but I couldn't figure out how to get that work either. It's just this one guy's name where this problem comes up, but he's mentioned in several places throughout the site.