I'd endorse this. UTF-8 or UTF-16 (depending on what languages you're expecting most of your data to be in) will handle anything. If you have Oracle it will also handle anything, it had NLS support before unicode, but your database must be set up with a suitable character set. It is completely a non-issue. But do cache the resources. If the resource access is encapsulated then you can try with and without caching, you'll notice a difference.
Brett Quoting Guillaume Cottenceau <[EMAIL PROTECTED]>: > Michael Klaene <mklaene 'at' yahoo.com> writes: > > > 3.)I know that some databases, Oracle, and I hear the newest version > > of MySQL support UTF-8. I've no experience in this area. Does anyone > > have experience with storing text in UTF-8 in the database? This > > *seems* like it could be an ideal approach, eliminating alot of > > on-going work. Obviously, the app would be less portable. > > If you want to go with full i18n, even if you don't store > localized messages in database, you will hit the wall sooner or > later if the database is not able to store any string > representing text in any language, because you will want sooner > or later that your users be able to enter localized data in forms > that will end up in the database (their first/last name, etc). > > Because of that reason, you need that the database be able to > store and retrieve localized text; a good approach can be to > specify that data is stored in a unicode character encoding; > UTF-8 is typically a good candidate when you have a lot of > latin-based text. > > And this is really an issue at the database end. In java, the > Strings can correctly and transparently handle any language. You > just have to make sure that the database driver will correctly > store and retrieve data. > > In the application at my company, the (postgres) database is > using UTF-8 and there is really nothing to say here: it works, > there is no problem. > > In my opinion, the only issue is really the communication between > the end-user (browser) and your application. Sending data to the > end-user should be ok by using UTF-8 in your webpages, if your > users are not using netscape 2.0 or something. Retrieving data > should be ok by using UTF-8 in your webpages and possibly > specifying accept-charset="UTF-8" in your forms, and filtering > the input to force the CharacterEncoding to UTF-8 (because > browsers usually don't say that the data they send is UTF-8 > encoded - there are been many discussions on that topic on this > list). > > > Please keep us updated about your project; I would be curious to > know about the performance, if you really go to using the > database for localized messages. > > -- > Guillaume Cottenceau > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
