Re: Migrations encoding
Re: Migrations encoding
- Subject: Re: Migrations encoding
- From: Chuck Hill <email@hidden>
- Date: Mon, 20 Jul 2009 10:59:09 -0700
On Jul 20, 2009, at 3:02 AM, Johann Werner wrote:
Hi,
I just came across the same problem. I have an UTF-8 encoded file
that should be executed during migrations. On my development machine
everything works as expected but on the deployment machine unicode
characters get garbled. After some debugging I found the difference
between both machines (development is 10.5.7 Client, deployment
10.5.7 Server): the java system property file.encoding is UTF-8 on
my development machine and on the server it is set to MacRoman. I
don't know why this setting is different nor how I can change this
default.
By adding a -Dfile.encoding=UTF-8 to the JVM arguments everything is
ok but this means that either I have to add this in JavaMonitor or
add it to the generated WOA-startup script. Both things you can
easily forget and screw up your migrations. So another solution I
tried is to add
System.setProperty("file.encoding", "UTF-8"); (1)
Does it work if you add that to your main method? I do that for
another property:
public static void main(String argv[])
{
ERXDatabaseContextMulticastingDelegate.addDefaultDelegate(new
ERXEntityDependencyOrderingDelegate());
// Ensure that we get proper error pages when an exception
happens in a direct action.
// This must go here and not in the constructor or it won't
work.
System.setProperty("WODisplayExceptionPages", "true");
WOApplication.main(argv, Application.class);
}
Chuck
to the application constructor. This seems to remedy the situation
but unfortunately the server showed the same garbled string :( By
stepping through the code the line
return new String(ERXFileUtilities.bytesFromInputStream(in)); (2)
in ERXStringUtilities.stringFromInputStream calls
String->StringCoding.decode->Converters.getDefaultEncodingName
which returns again MacRoman. Could it be that setting the system
property (1) does not alter the value globally? How are you assuring
that the file encoding defaults to UTF-8 in your WO applications? Is
there a special trick? Is changing the startup script in the ant
build the way to go (so should it possibly be made the default in
WOLips)?
A temporary patch would be to change the line (2) to
return new String(ERXFileUtilities.bytesFromInputStream(in),
Charset.defaultCharset());
jw
Am 15.06.2009 um 20:45 schrieb Tusker:
Yup. I made sure it was using bbedit. I read in the sql file
manually(using FileInputStream with UTF-16 encoding) and inserted
it into the database via editingcontext with no problem at all.
How else can I make sure it's encoded properly?
On Jun 14, 2009, at 12:20 PM, Chuck Hill wrote:
On Jun 12, 2009, at 10:59 AM, Tusker wrote:
Hi,
Same problem. I'm actually using a *.sql file within the
Resources folder. It's been working great until I got to unicode
characters.
I'm using this to call the *.sql. I've made sure that it is
encoded (UTF-16). Also tried (UTF-8)
You made sure it was encoded in UTF-16 or you just told Eclipse
that it was? I don't think that Eclipse will re-encode the file
if you do that.
Chuck
ERXJDBCUtilities.executeUpdateScriptFromResourceNamed(channel,
"mysqltest.sql", null);
I tried changing the name to "name". Works fine until I
introduce unicode characters.
Somewhere between reading the file to execution, the encoding is
not right.
This is what ends up in the database:
Belgium/België/Belgique
Thanks
On Jun 12, 2009, at 10:34 AM, Jon Nolan wrote:
Tusker wrote:
I changed the file to be UTF-16 but I get an error now. I use
the same sql file and manually run it in frontbase, it works.
Example of the statement:
update Country set name = 'Belgium/België/Belgique' where
country_id = 2;
"name" is a reserved word in Frontbase although FBManager (not
sure about sql92) can often/usually/always handle non-quoted
reserved words depending on how you're using them. I've always
had to double-quote reserved words when working in Migrations
though. i.e.
ERXJDBCUtilities.executeUpdate(database.adaptorChannel(),
"update SITE set \"TYPE\" = 1 where \"TYPE\" = 10");
Of course it might still be an encoding issue but let's rule out
this potential problem first. Try..
update Country set "name" = 'Belgium/België/Belgique' where
country_id = 2;
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC'09 in San Fran this June!
http://www.wocommunity.org/wowodc09/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Learn WO at WOWODC'09 East in Montréal this August!
http://www.wocommunity.org/wowodc09/east
http://arstechnica.com/apple/news/2009/07/webobjects-sliced-from-106but-prognosis-of-death-premature.ars
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden