I see, Kalle. I thought you were talking about the ability to read unicode. I was the one being amateurish and not reading you clearly. I am very interested in what you are doing. Please keep me updated. Looks like a one person job, but if you would like some assistance, please let me know.
On 5/3/05, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: Michael McGrady [mailto:[EMAIL PROTECTED] > > Subject: Re: UTF-8 support > > I did not understand what you were saying about property > > files. I assume that you are merely saying that MyFaces does > > not have the files set properly to get UTF-8? Anyway, I > > cannot imagine not having support for UTF-8 property files. > > That would really be amateur. > > Amateurish or not, the standard Java Properties class assumes Latin-1 > encoding of property files. There are ways to get by that, by encoding all > the double byte characters with unicode escapes. From Java API doc: "When > saving properties to a stream or loading them from a stream, the ISO 8859-1 > character encoding is used. For characters that cannot be directly > represented in this encoding, Unicode escapes are used; however, only a > single 'u' character is allowed in an escape sequence. The native2ascii tool > can be used to convert property files to and from other character encodings.". > > MyFaces uses the standard Java classes. What I'm saying, is that I could > patch it so that UTF-8 encoded property files could be used, without first > running them through native2ascii and making them Latin-1 encoded with > unicode escapes. > > Kalle > > > On 5/2/05, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > > > Interestingly, I didn't get any responses to my original > > mail on the topic. Since we need UTF-8 support and because > > part of our application is in Struts (which doesn't have a > > problem with UTF-8 encoded property files) we'd like to avoid > > encoding the property files in Latin-1. I made a quick hack > > for supporting UTF-8 encoded property files as outlined here > > (http://www.thoughtsabout.net/blog/archives/000044.html), > > added the class and made a few changes to take it into use in > > our build of MyFaces. Another benefit of the wrapper is that > > you could easily implement caching � la Struts > > MessageResources. I tested it and it seems to work fine. I > > could easily create a patch for it; Does anybody else in > > MyFaces community think it'd be useful to add support for > > UTF-8 encoded Property files? > > > > > > Kalle > > > > > > > -----Original Message----- > > > > From: Korhonen, Kalle > > > > Sent: Wednesday, April 20, 2005 11:12 AM > > > > To: 'MyFaces Discussion' > > > > Subject: UTF-8 support > > > > > > > > Looks like the default MyFaces implementation uses the standard > > > > PropertyResourceBundle, which uses the standard Properties class > > > > that in turn assumes only Latin-1 as encoding of the > > property file. > > > > That naturally breaks all the > > > > UTF-8 encoded double-byte characters in the properties file. > > > > I definitely don't want to use native2ascii, which is > > just too much > > > > hassle, but just simply encode my Properties files as UTF-8. > > > > > > > > I'm surprised that I seem to be the first person hitting this > > > > problem. I search the mail archives for "utf*" but got nothing on > > > > this. I assume and recall reading from some place that you could > > > > replace the default ResourceBundle implementation, similarly to > > > > overriding other configuration in JSF's pluggable architecture. > > > > Anybody done this and care to share any samples? > > > > > > > > Struts implements its own resource classes that deal with > > > > UTF-8 encoded files properly. In fact, those classes are not even > > > > inherited or using any of the ResourceBundle/Properties base > > > > classes. Anybody done an adaptation of that code as a > > > > ResourceBundle? A few months ago, I looked around quickly but > > > > couldn't find any easily available, does anyone know if > > there are any? > > > > > > > > Also, looks like HtmlResponseWriterImpl is encoding all > > characters > > > > out of latin-1 as unicode character references. > > > > For performance reasons, I don't think we should do that if the > > > > response stream specifies UTF-8 as encoding. There might be other > > > > complications that need to be considered, but I might > > file a bug on > > > > it later and patch it once I get the > > > > UTF-8 properties file working. > > > > > > > > (A little off-topic) Finally, I could also consider 1.5 Java > > > > Properties.loadFromXml(), but I'm a little hesitant to use it > > > > because of possible performance penalties and because I > > don't really > > > > need xml format. Don't really understand why Sun wouldn't > > just add > > > > support for UTF-8 for Properties.load() and > > > > store() since it shouldn't break anything. Anyway, > > anybody have any > > > > experience on loadFromXml and an opinion on pros and cons > > of it? The > > > > technical writers have barely wrapped their heads around > > the concept > > > > of parametrized resources, so I'm afraid introducing xml into the > > > > soup is just more confusing. > > > > > > > > Kalle > > > > > >

