• 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
[Solved!] Re: Encoding in .java file [Solved!]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Solved!] Re: Encoding in .java file [Solved!]


  • Subject: [Solved!] Re: Encoding in .java file [Solved!]
  • From: Jacky Gagnon <email@hidden>
  • Date: Mon, 13 Sep 2004 10:51:54 -0400

Hi,

I found the source of the problem with source file encoding.

In Application server's target, you must select the good "Source file encoding" in "Java Compiler Settings". This settings is global (all your .java source files must have the same encoding). For the moment I will keep Western (Mac OS Roman) because the majority of my component use this encoding.

What I don't understand, is why XCode use UTF-8 by default for .java file (in preferences Mac OS Roman is selected?!?); I must change it manually when I create new component our new source file.

Thanks!

Jacky :-)


On 04-09-10, at 15:30, Jean-François Veillette wrote:

first, just a quick review ...

in Java, all internal string representation is done in UTF-8, so if in your .java you had 'String s = "école"; // "&eacute;cole"' and you told XCode that the .java file was encoded in UTF 8, then you should be ok once the code is bytecode.

in appendToResponse of a WOComponent, it use the encoding defined in the .woo under the 'encoding' key, before forcing it, try first to set that key and make sure it's correct.
Because it use transform bytes from disk (the file) and convert it to String, it has to know which encoding to use to map the bytes to chars.
In appendToResponse, at that point, all string representation should be in UTF-8, and so should be the WOResponse content in memory.
Before the content is return to the client (as binary stream), it is converted in the encoding defined in the .woo. So at that point, you should make sure the html encoding defined in one of the html tag correspond to the encoding you defined in your page-level .woo.


If you return that stream to the browser, it once again read as bytes, and so the browser has to know which encoding to use before display, that's where the html tags come in to play.

Possible Transformation :
1- from java file (encoding argument to javac) to byte code (utf-8).

2- from .wo/* ( binary stream) to memory (utf8 String representation) , the encoding to convert from is defined in the .woo

3- from memory (utf-8) to woadaptor (to browser), the encoding used to convert to is the one defined in the last page-level .woo

4- from binary stream (network) to web page (Safari), the encoding used is the one defined in the http header or in the page itself, in one of the html tags.

5*- you can add the convertion between database and wo-app, the encoding in which the database is defined, the encoding used for conversion will be driver dependent.

If all the transformation have the right informationi to convert 'to' and 'from', then you should be all good.

PS: I wonder why you need to force the encoding in appendToResponse


Reading on your problem, I understand that your .java files are encoded in utf-8.
I think that your wocomponent.wo/wocomponent.woo have the encoding in MacOS-Roman (or not set, which use the platform default encoding by default).


if you called super.appendToResponse() after forcing the encoding in utf-8, then I would think that it would read your .html template binary as utf-8, this transformation wouldn't work if in your page template you had 'école' for example.

if you called super.appendToResponse() before forcing the encoding in utf-8, then I would think that it would read your .html template binary as macos-roman, apply the templates and binding on a 'macos' encoded content, then you force the response encoding to utf-8 which it is not. so when it return the binary stream it return macos binary, but you tell the browser it's utf-8 encoded, so the browser doesn't display correctly.


Note: I just had such a problem today, so it's kind of fresh in memory ;-)


- jfv


Le 04-09-10, à 14:37, Jacky Gagnon a écrit :

Hi,

I have a WO application using UTF-8 encoding using these lines in appendToResponse :

aResponse.setContentEncoding(_NSUtilities.UTF8StringEncoding);
aResponse.setHeader("text/html; charset=UTF-8; encoding=UTF-8",
"content-type");


All works perfectly until XCode decide to create all new java source
file with the UTF-8 encoding (created directly or via the creation of
new component); the default encoding in my preferences, is Western Mac
Roman.


If I bind a java string (where the content is in the source code) to a
WOString, some characters don't display correctly in the web page : i,
h, ` etc. To resolve the problem, I must change the encoding to
MacOSRoman in appendToResponse or change the encoding of the source
file from UTF8 to Mac OS Roman.


Why XCode create Java source file in UTF-8 when the defautl encoding is
Western Mac Roman (I didn't have this problem in Project Builder)?


How I can display my string correctly without changing the encoding of
my source file (keep the UTF-8 encoding)?

Thanks!

Jacky
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.





_______________________________________________ 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
References: 
 >Encoding in .java file (From: Jacky Gagnon <email@hidden>)
 >Re: Encoding in .java file (From: Jean-François Veillette <email@hidden>)

  • Prev by Date: WebObjects to SQL Server 2000...best way ??
  • Next by Date: Re: WebObjects to SQL Server 2000...best way ??
  • Previous by thread: Re: Encoding in .java file
  • Next by thread: Assistant in Direct to Java
  • Index(es):
    • Date
    • Thread