Skip to main content
Participating Frequently
July 11, 2008
Question

CMFX 7, MYSQL5, and UTF8

  • July 11, 2008
  • 4 replies
  • 2262 views
I am running CFMX 7 Enterprise and MYSQL 5 with mysql-connector-java-5.0.7-bin.jar file.

My database,tables, and columns are defined as utf8.

I have this connection string on my datasource:
jdbc:mysql://swwdb4.unx.sas.com:7890/etst?zeroDateTimeBehavior=convertToNull&characterEncoding=UTF8&characterSetResults=UTF8

I have these lines in my index.cfm(I am using Fusebox):
<cfprocessingdirective pageencoding="UTF-8">
<cfset setEncoding("URL","UTF-8")>
<cfset setEncoding("FORM","UTF-8")>
<cfcontent type="text/html; charset=UTF-8">

finally I have this option on the form tag: enctype="multipart/form-data: charset=utf-8"

When Chinese or Cyrillic characters entered on the form, they are stored in the database as ????.

What else do I need to add for these characters to be stored and displayed correctly?

This topic has been closed for replies.

4 replies

Inspiring
July 21, 2008
PaulH wrote:
> i can't find any reference to using sql server-like unicode hinting
> w/mysql--so something's fishy w/that (though again i'm no mysql expert).

i take that back: http://dev.mysql.com/doc/refman/5.0/en/charset-national.html

bu if your database, columns, etc are utf-8, then you don't need the unicode
hinting. if i understand that page correctly, it could mean you db's not in utf-8??
kittybAuthor
Participating Frequently
July 21, 2008
yes the database, table, and column are defined as utf8_general_ci. the operating system is Windows XP.

I have the JDBC URL defined as: jdbc:mysql://swwdb4.unx.sas.com:7890/etst?zeroDateTimeBehavior=convertToNull&characterEncoding=UTF8

I removed enctype="multipart/form-data: charset=utf-8" from the <form tag.

Our Cf server was rebooted as well.

Inserting Chinese or Russian characters into the database via the form are still displaying as ??? in the database.
The 2 "interesting" tests from a previous post produce the same results.

I will add the test page.
kittybAuthor
Participating Frequently
July 21, 2008
I do not have a public place for the test files...I can email them to you.
Inspiring
July 21, 2008
...my reply seems to have gotten lost via the news forums...

first off i can assure unicode works w/mysql & cf.

i can't find any reference to using sql server-like unicode hinting w/mysql--so something's fishy w/that (though again i'm no mysql expert).

when you changed the JDBC url & added "useUnicode=true" and dropped the form's encoding type, what were the results? i'm not exactly sure if this is needed but when you made changes did you stop/restart the cf server service?

are you 100% sure the db, column datatypes, etc. support utf-8?

what OS?

finally can you put up a public test page that i can test? a page w/a form that dumps out the form values, inserts them into a utf-8 table, selects from them & dumps those out? the text is getting mangled in these forums & via NNTP (which actually tells me that the text maybe isn't actually utf-8 as the forums, etc use utf-8 encoding).

Inspiring
July 18, 2008
i suppose they could have worded that better "if you use", ie if you're uploading a file.
kittybAuthor
Participating Frequently
July 18, 2008
well, regardless of the doc..adding or removing has had no effect on my problem.

I cannot get Unicode to work with CFMX and mysql.
Inspiring
July 13, 2008
kittyb wrote:
> dbc:mysql://swwdb4.unx.sas.com:7860/etstest?zeroDateTimeBehavior=convertToNull&c
> haracterEncoding=UTF8&characterSetResults=UTF8

missing a "j" (jdbc)? have you tried " useUnicode=true&characterEncoding=utf8"?

what happens if you just post the form to a cf page & dump out the form values?
still garbaged?

> finally I have this option on the form tag: enctype="multipart/form-data:
> charset=utf-8"

are you uploading something w/this form? otherwise maybe drop this.
kittybAuthor
Participating Frequently
July 14, 2008
sorry, the cut 'n past dropped the j from jdbc.

I had useUnicode=true on the string but I read that CFMX uses UniCode by default and that it is not necessary to specify that.