• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Migrations encoding
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Migrations encoding
      • From: Johann Werner <email@hidden>
References: 
 >Re: Migrations encoding (From: Johann Werner <email@hidden>)

  • Prev by Date: Re: Date formatter with support for ordinal date suffix?
  • Next by Date: Re: [Slightly OT] Classpath and JCE Unlimited Strength Jurisdiction Policy Files
  • Previous by thread: Re: Migrations encoding
  • Next by thread: Re: Migrations encoding
  • Index(es):
    • Date
    • Thread