Re: [Thanks] Pb saving strings with accentuated characters (MySQL 5)
Jean Pierre Malrieu <[email protected]>
| Newsgroups | gmane.comp.web.webobjects.devel |
|---|---|
| Message-ID | <[email protected]> |
Thanks a lot for your help. I did follow your advices and switched to
UTF_8 encoding. This seems to solve my problem.
And I am much less scared by the whole encoding stuff now.
JPM
Le 24 mai 06 à 21:28, Dev WO a écrit :
>> Thanks for the reply. And pardon my ignorance.
> no problem, making mistake is an expected way to success;)
>>
>> I have done some research in my database, and I discovered that as
>> far as character encoding is concerned, it is a mess.
>> The default server encoding is latin1.
> not that much important
>> My database is default-encoded with latin1.
> this is important
>> But my tables are InnoDB, and seems to use utf-8. (ENGINE=InnoDB
>> DEFAULT CHARSET=utf8)
> that's right which is "unexpected" but might be due to EOModeler
> generating the table (with the useUnicode=true dictionary)
>> And finally, the columns for my text and varchar columns use
>> collation utf8_general_ci, which seems to imply that their
>> character set is utf8.
> no, you can have pretty much whatever you want as collation and
> something different for the encoding. The collation is mainly the
> sorting behavior, could lead to differences when sorting string
> with accentuated characters for example.
>>
>> So, I suppose I should do some cleaning up and either restore
>> latin1 encoding or move to utf8.
> You are already UTF-8 for the tables, so it's OK for this, but you
> should put everything UTF-8, or at least set that as the default so
> new database will be UTF-8.
> You should take a lot of care when moving an already existing
> database (with data in it) to another encoding...And you should
> warn other that will use the database that new database will be
> UTF-8 as it could be difficult to handle.
> But if you're using WO, it's not a big deal.
>> As you suggest me to move to utf8 (and my textual data already
>> seems to be utf8 encoded), what would it involve? Let me try to
>> guess.
>>
>> 1/ specify utf8 as the charset for all my pages (what tool is the
>> most appropriate to do so? I suppose I need to CONVERT the html to
>> utf8 in order to get static strings right.
> no, usually you can even type an accentuated character inside the
> HTML source code, as long as the editor is set as unicode (like
> WOBuilder 5.3.1). So not much things in it.
>> Is there a tool that can automate the process? Can WOBuilder be
>> used for that purpose?)
> You are probably already OK on the WOBuilder side without knowing
> it, check the Preferences. Just check a .woo, you should see
> something like NSUTF8StringEncoding.
>> 2/ modify the connection dictionnary (something like useUnicode=
>> true and characterEncoding=utf8)
> the connection dictionary should be ?
> useUnicode=true&characterEncoding=UTF-8, but unicode is the default
> with JDBC, so even without it it should work. The jdbc
> documentation mention the use of utf8 instead of UTF-8 I think, but
> I had more success with the later (maybe I'm just dreaming about
> this, way UTF-8 works OK).
>> 3/ something else?
> yes just below
>>
>> But what do you mean by "both in the <head> section and in the web
>> server". Do I have to tell apache to use utf8?
> you'll need:
> <meta http-equiv="content-type" content="text/html;charset=UTF-8">
> in the <head> section of your HTML page and
> public void appendToResponse(WOResponse response, WOContext
> wocontext) {
> super.appendToResponse(response, wocontext);
> // This must be done after the page generation to override the
> default header created by WO during the page generation.
> if (_NSUtilities.UTF8StringEncoding.equals
> (response.contentEncoding()))
> response.setHeader("text/html; charset=UTF-8", "content-type");
> }
>
> public WOResponse createResponseInContext(WOContext wocontext) {
> WOResponse woresponse = super.createResponseInContext(wocontext);
> woresponse.setContentEncoding(_NSUtilities.UTF8StringEncoding);
> return woresponse;
> }
> in the Application.java and finally
> public void takeValuesFromRequest(WORequest aRequest, WOContext
> aContext){
> aRequest.setDefaultFormValueEncoding
> (_NSUtilities.UTF8StringEncoding);
> super.takeValuesFromRequest(aRequest, aContext);
> }
> in Session.java to make sure the form gets acquired using UTF-8 too.
>
> You should have a look at Chuck's and Sacha's book Practical
> WebObjects;)
>
> That should set you up.
>
> Xavier
>>
>> JPM
>>
>> Le 24 mai 06 à 16:48, Dev WO a écrit :
>>
>>> Hello Jean Pierre,
>>> just a quick suggestion: you should move to UTF-8;)
>>> despite that, you should check the following:
>>> -an HTML form send the text back to the server using the same
>>> encoding of the web page so you've got to make sure your HTML
>>> declares ISO-8859-1 (both in the <head> section and in the web
>>> server)
>>> -you've got to check the encoding of your SQL database to make
>>> sur it also uses ISO-8859-1
>>> -you've got a wrong connection dictionary, you are saying to use
>>> unicode but specify a non-unicode encoding...removing it doesn't
>>> change anything as java default to unicode (UTF-8)
>>> so your connection dictionary might be
>>> useUnicode=false&characterEncoding=ISO-8859-1
>>> -finally just make sur the woresponse get the right header
>>> concerning the encoding (ISO-8859-1 in your case)
>>>
>>> Hope this help, I think the connection dictionary is in fault,
>>> but checking the other part is worth it;)
>>>
>>> Xavier
>>>
>>>
>>>> Hi,
>>>>
>>>> I am having a problem with saving a String to a MySQL 5 database.
>>>> If I type the text within a WOText and save it, no problem.
>>>> But if I paste the text from MS Word, let's say, and save it,
>>>> then the string is trimmed after the first accentuated
>>>> character. The only characters that get saved are the characters
>>>> before the first accentuated character.
>>>>
>>>> This happens with different browsers and generated SQL looks fine.
>>>>
>>>> I used to pass parameters
>>>> (useUnicode=true&characterEncoding=ISO-8859-1) to the jdbc
>>>> connector (version 3.1.12). I have tried removing those
>>>> parameters, thinking they might be irrelevant for MySQL 5. But
>>>> the problem remains.
>>>>
>>>> Do you guys have any ideas of what could be going on?
>>>>
>>>> Thanks.
>>>>
>>>> JPM
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> WebObjects-dev mailing list
>>>> [email protected]
>>>> http://www.omnigroup.com/mailman/listinfo/webobjects-dev
>>>>
>>>
>>>
>>
>>
>
>