Ok, I have finally found some time to convert over our apps to use Eclipse and
I have something to report, which I hope will spark someone to have another
idea on what could be causing this problem.
Firstly, I was having this problem with all apps. Now, I have converted them
over into Eclipse (was using Xcode) so that I can use 5.4.3 version of WO. I
am using this same version on my development and deployment. I am embedding
all libraries as well.
It turns out that the problem is no longer occurring in any of the apps except
one. When I was converting them over into Eclipse I did my best to make sure
everything was set to UTF-8, I've even used Eclipse's sweet little Search
feature to replace any reference to NSRoman encoding in the .woo files etc. I
don't believe there is any where in any of the apps where UTF-8 is not
specified now.
So, as I said, it seems that they are all working with the exception of one.
This is driving me nuts so I've been trying everything I can to nail down
exactly where the problem is occurring (even if I haven't yet figured out the
WHY.) This is what I have found, using simple output to the console:
If I override the takeValuesFromRequest() method of the Application class, I
have found that right up until I call super.takeValuesFromRequest, everything
is fine. However, immediately AFTER calling super, the values are garbled.
i.e. they are no longer displaying as they should.
Before calling super, I get the € symbol displayed fine in the console (by
showing the contents of formValues()).
After I call super, I get the € symbol showing up as "€".
Clearly the takeValuesFromRequest() method is doing something to change it. I
don't understand at what point this could be happening or how to track it down
further. Anyone any thoughts? I'd like to sleep tonight :)
formValues before super: {0.1.13.0.5.9.1.17 = (""); 0.1.13.0.5.9.1.29 =
("10.00"); 0.1.13.0.5.9.1.1 = ("1960"); 0.1.13.0.5.9.1.5 =
("0.1.13.0.5.9.1.5"); 0.1.13.0.5.9.1.27 = ("0"); 0.1.13.0.5.9.1.39 = ("84");
0.1.13.0.5.9.1.37 = ("30"); 0.1.13.0.5.9.1.61 = ("Save"); 0.1.13.0.5.9.1.35 =
("0"); 0.1.13.0.5.9.1.41 = ("0"); 0.1.13.0.5.9.1.31 = ("40.00");
0.1.13.0.5.9.1.3 = ("Movi"); 0.1.13.0.5.9.1.11 = ("Movistar Prepaid SIM Card
€12 Credit"); 0.1.13.0.5.9.1.23 = ("200"); 0.1.13.0.5.9.1.13 = ("D7S3");
0.1.13.0.5.9.1.25 = ("1"); 0.1.13.0.5.9.1.15 = (""); 0.1.13.0.5.9.1.9 =
("0.1.13.0.5.9.1.9"); }
formValues after super: {0.1.13.0.5.9.1.17 = (""); 0.1.13.0.5.9.1.29 =
("10.00"); 0.1.13.0.5.9.1.1 = ("1960"); 0.1.13.0.5.9.1.5 =
("0.1.13.0.5.9.1.5"); 0.1.13.0.5.9.1.27 = ("0"); 0.1.13.0.5.9.1.39 = ("84");
0.1.13.0.5.9.1.37 = ("30"); 0.1.13.0.5.9.1.61 = ("Save"); 0.1.13.0.5.9.1.35 =
("0"); 0.1.13.0.5.9.1.41 = ("0"); 0.1.13.0.5.9.1.31 = ("40.00");
0.1.13.0.5.9.1.3 = ("Movi"); 0.1.13.0.5.9.1.11 = ("Movistar Prepaid SIM Card
€12 Credit"); 0.1.13.0.5.9.1.23 = ("200"); 0.1.13.0.5.9.1.13 = ("D7S3");
0.1.13.0.5.9.1.25 = ("1"); 0.1.13.0.5.9.1.15 = (""); 0.1.13.0.5.9.1.9 =
("0.1.13.0.5.9.1.9"); }
On Nov 16, 2009, at 5:55 PM, David Griffith wrote:
Yep, I have that in the header and still the same problem. It's one thing or
the other. Either the values from the database display correctly on the page,
but values added from forms do not display correctly on the page but as â¬, or
values from the database display as '?' and values added from the forms DISPLAY
correctly on the page, but get added to the database as â¬. Depends on
whether I override the dispatchRequest() or not, and neither of the above
situations are useful. If anyone fancies having a look at the page online to
see what I mean, please let me know and I'll send you a link. It's driving me
absolutely crazy.
Regards,
David.
On 15 Nov 2009, at 08:39, Elim PDT wrote:
> If you don't have the following line in your html head, it definitely a
> source of problem:
>
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
>
> I never tried wo5* with other languages. Wondering who have any experiences
> with utf-8, say Chinese or Russian?
>
>
> From: David
> To: WebObjects-Dev Mailing List List
> Sent: Wednesday, November 11, 2009 5:17 AM
> Subject: UTF8 and ContentEncoding
>
> Hi all,
>
> I have the following situation:
>
> A database with all tables specified to default to UTF8 encoding.
> Adaptor URL containing useUnicode=true&setContentEncoding=UTF8
> A record in one table that holds the € currency symbol.
>
> I am loading a WOComponent page to edit values etc., using a form.
>
> Everything was fine and one day all the € symbols started appearing as '?'.
> Clearly something changed somewhere on the server but I don't know what.
> Anyway, the €msymbols that are appearing this way are displayed by using a
> WOString. The value it displays is from defaultCountry which is a variable
> of type COUNTRY loaded from the database and stored in the Session class.
>
> € symbols that were entered on the form, when added to a display group for
> example, would appear as â¬.
>
> I've had a look around and what I found was this suggestion:
>
> Put this in Application class:
>
> public void takeValuesFromRequest(WORequest r, WOContext c) {
> r.setDefaultFormValueEncoding("UTF8");
> super.takeValuesFromRequest(r,c);
> }
>
> public void appendToResponse(WOResponse r, WOContext c) {
> r.setContentEncoding("UTF8");
> super.appendToResponse(r,c);
> r.setHeader("text/html;charset=utf-8", "Content-Type");
> }
>
> Which I did. It helped to a certain extent. It seemed to fix the problem
> with the form values, which now displayed correctly, but the '?' still
> appears where the value is displayed with WOString. Then I found another
> suggestion:
>
> Put this in Application class:
>
> public WOResponse dispatchRequest(WORequest aRequest) {
> aRequest.setContentEncoding("UTF-8");
> WOResponse aResponse = super.dispatchRequest(aRequest);
> aResponse.setContentEncoding("UTF-8");
> return aResponse;
>
> Doing this solved the problem of the '?' but reverted the form values to
> display as â¬.
>
> No matter what I do, there doesn't seem to be a way to get them both to
> display correctly. Any ideas?
>
> Regards,
> David.
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/elim%40pdtnetworks.net
>
> This email sent to [email protected]
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.707 / Virus Database: 270.14.65/2502 - Release Date: 11/14/09
> 00:43:00
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/david%40infinityspain.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
