[Schmitzm-commits] r1426 - in trunk/schmitzm-core/src/main/java/de/schmitzm: . i18n
scm-commit@wald.intevation.org
scm-commit at wald.intevation.org
Thu Jan 27 12:58:25 CET 2011
Author: alfonx
Date: 2011-01-27 12:58:24 +0100 (Thu, 27 Jan 2011)
New Revision: 1426
Removed:
trunk/schmitzm-core/src/main/java/de/schmitzm/i8n/
Modified:
trunk/schmitzm-core/src/main/java/de/schmitzm/i18n/Utf8ResourceBundle.java
Log:
Modified: trunk/schmitzm-core/src/main/java/de/schmitzm/i18n/Utf8ResourceBundle.java
===================================================================
--- trunk/schmitzm-core/src/main/java/de/schmitzm/i18n/Utf8ResourceBundle.java 2011-01-27 11:52:53 UTC (rev 1425)
+++ trunk/schmitzm-core/src/main/java/de/schmitzm/i18n/Utf8ResourceBundle.java 2011-01-27 11:58:24 UTC (rev 1426)
@@ -1,115 +1,117 @@
-// Stefan meint, das war ein Hack und wird nicht mehr benötigt.
-// package de.schmitzm.i18n;
-//
-//import java.io.UnsupportedEncodingException;
-//import java.util.Enumeration;
-//import java.util.Locale;
-//import java.util.PropertyResourceBundle;
-//import java.util.ResourceBundle;
-//
-///**
-// * Credits to http://www.thoughtsabout.net/blog/archives/000044.html
-// *
-// * May 02, 2005 Quick and Dirty Hack for UTF-8 Support in ResourceBundle
-// *
-// * I just don't get why Sun folks didn't fix this in J2SE 1.5. By specification,
-// * PropertyResourceBundles, or more exactly, the Properties files are Latin-1
-// * (i.e. ISO 8859-1) encoded:"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. "
-// * . However, since all Latin-1 characters are in the same position in UTF-8
-// * encoding, I don't see a reason why they couldn't have just added support for
-// * UTF-8 into the Properties class.
-// *
-// * While PropertyResourceBundle only has an implicit reference to the Properties
-// * class, the problem is an overall bad design of ResourceBundle class
-// * hierarchy. The super class ResourceBundle has two responsibilities: it acts
-// * both as a super class and as a factory for loading ResourceBundles. The
-// * ResourceBundle handles loading of PropertyResourceBundles that inherit from
-// * ResourceBundle, and you can already smell a problem with this suspicous
-// * implementation. Generally, the superclass should never need to know anything
-// * about child classes implementing it. The getBundle() methods in it are
-// * defined as final so there's no way to replace the the default implementation
-// * of PropertyResourceBundle. Sun has two answer to this problem: either use
-// * native2ascii tool to encode all double-byte characters in your Properties
-// * file or implement your own ResourceBundle class.
-// *
-// * Using native2ascii by hooking it up with your Ant build as a task is fine,
-// * but when you are developing and adding UTF-8 strings into your Properties
-// * file, it's just an extra burden to run native2ascii after every change. On
-// * Sun's forums, Craig McClanahan discusses how you could use your own
-// * ResourceBundle class instead of Properties files to resolve the encoding
-// * problem. But the issue with custom ResourceBundle classes is that they are
-// * inherently different from PropertiesResourceBundle; you would need a custom
-// * class per each locale you are supporting. Since ResourceBundle class handles
-// * loading of the PropertyResourceBundles and the methods are marked final, you
-// * are stuck with the Latin-1 encoding if you want to use Property files.
-// *
-// * The whole problem is stupid. Properties files should have supported UTF-8 in
-// * the first place, but the change to support them could have been made at any
-// * time after. Assuming UTF-8 as encoding when reading Latin-1 encoded file
-// * wouldn't have broken anything: this backwards compatibility is the basic
-// * reason why UTF-8 is so popular. All is not lost though; you could just use
-// * your own ResourceBundle factory class for loading ResourceBundles and then
-// * implement a UTF-8 PropertyResourceBundle class wrapper for UTF-8 support.
-// * Here's a quick and dirty hack to do just that:
-// */
-//public abstract class Utf8ResourceBundle {
-//
-// public static final ResourceBundle getBundle(String baseName) {
-// ResourceBundle bundle = ResourceBundle.getBundle(baseName);
-// return createUtf8PropertyResourceBundle(bundle);
-// }
-//
-// public static final ResourceBundle getBundle(String baseName, Locale locale) {
-// ResourceBundle bundle = ResourceBundle.getBundle(baseName, locale);
-// return createUtf8PropertyResourceBundle(bundle);
-// }
-//
-// public static ResourceBundle getBundle(String baseName, Locale locale,
-// ClassLoader loader) {
-// ResourceBundle bundle = ResourceBundle.getBundle(baseName, locale);
-// return createUtf8PropertyResourceBundle(bundle);
-// }
-//
-// private static ResourceBundle createUtf8PropertyResourceBundle(
-// ResourceBundle bundle) {
-// if (!(bundle instanceof PropertyResourceBundle))
-// return bundle;
-//
-// return new Utf8PropertyResourceBundle((PropertyResourceBundle) bundle);
-// }
-//
-// private static class Utf8PropertyResourceBundle extends ResourceBundle {
-// PropertyResourceBundle bundle;
-//
-// private Utf8PropertyResourceBundle(PropertyResourceBundle bundle) {
-// this.bundle = bundle;
-// }
-//
-// /*
-// * (non-Javadoc)
-// *
-// * @see java.util.ResourceBundle#getKeys()
-// */
-// public Enumeration getKeys() {
-// return bundle.getKeys();
-// }
-//
-// /*
-// * (non-Javadoc)
-// *
-// * @see java.util.ResourceBundle#handleGetObject(java.lang.String)
-// */
-// protected Object handleGetObject(String key) {
-// String value = (String) bundle.handleGetObject(key);
-// if (value == null)
-// return null;
-// try {
-// return new String(value.getBytes("ISO-8859-1"), "UTF-8");
-// } catch (UnsupportedEncodingException e) {
-// // Shouldn't fail - but should we still add logging message?
-// return null;
-// }
-// }
-//
-// }
-//}
\ No newline at end of file
+ package de.schmitzm.i18n;
+
+
+import java.io.UnsupportedEncodingException;
+import java.util.Enumeration;
+import java.util.Locale;
+import java.util.PropertyResourceBundle;
+import java.util.ResourceBundle;
+
+/**
+ * Credits to http://www.thoughtsabout.net/blog/archives/000044.html
+ *
+ * May 02, 2005 Quick and Dirty Hack for UTF-8 Support in ResourceBundle
+ *
+ * I just don't get why Sun folks didn't fix this in J2SE 1.5. By specification,
+ * PropertyResourceBundles, or more exactly, the Properties files are Latin-1
+ * (i.e. ISO 8859-1) encoded:"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. "
+ * . However, since all Latin-1 characters are in the same position in UTF-8
+ * encoding, I don't see a reason why they couldn't have just added support for
+ * UTF-8 into the Properties class.
+ *
+ * While PropertyResourceBundle only has an implicit reference to the Properties
+ * class, the problem is an overall bad design of ResourceBundle class
+ * hierarchy. The super class ResourceBundle has two responsibilities: it acts
+ * both as a super class and as a factory for loading ResourceBundles. The
+ * ResourceBundle handles loading of PropertyResourceBundles that inherit from
+ * ResourceBundle, and you can already smell a problem with this suspicous
+ * implementation. Generally, the superclass should never need to know anything
+ * about child classes implementing it. The getBundle() methods in it are
+ * defined as final so there's no way to replace the the default implementation
+ * of PropertyResourceBundle. Sun has two answer to this problem: either use
+ * native2ascii tool to encode all double-byte characters in your Properties
+ * file or implement your own ResourceBundle class.
+ *
+ * Using native2ascii by hooking it up with your Ant build as a task is fine,
+ * but when you are developing and adding UTF-8 strings into your Properties
+ * file, it's just an extra burden to run native2ascii after every change. On
+ * Sun's forums, Craig McClanahan discusses how you could use your own
+ * ResourceBundle class instead of Properties files to resolve the encoding
+ * problem. But the issue with custom ResourceBundle classes is that they are
+ * inherently different from PropertiesResourceBundle; you would need a custom
+ * class per each locale you are supporting. Since ResourceBundle class handles
+ * loading of the PropertyResourceBundles and the methods are marked final, you
+ * are stuck with the Latin-1 encoding if you want to use Property files.
+ *
+ * The whole problem is stupid. Properties files should have supported UTF-8 in
+ * the first place, but the change to support them could have been made at any
+ * time after. Assuming UTF-8 as encoding when reading Latin-1 encoded file
+ * wouldn't have broken anything: this backwards compatibility is the basic
+ * reason why UTF-8 is so popular. All is not lost though; you could just use
+ * your own ResourceBundle factory class for loading ResourceBundles and then
+ * implement a UTF-8 PropertyResourceBundle class wrapper for UTF-8 support.
+ * Here's a quick and dirty hack to do just that:
+ *
+ * @deprecated Das wird in immodb benutzt, kann aber irgendwie auch ersetzt werden.. mal
+ */
+public abstract class Utf8ResourceBundle {
+
+ public static final ResourceBundle getBundle(String baseName) {
+ ResourceBundle bundle = ResourceBundle.getBundle(baseName);
+ return createUtf8PropertyResourceBundle(bundle);
+ }
+
+ public static final ResourceBundle getBundle(String baseName, Locale locale) {
+ ResourceBundle bundle = ResourceBundle.getBundle(baseName, locale);
+ return createUtf8PropertyResourceBundle(bundle);
+ }
+
+ public static ResourceBundle getBundle(String baseName, Locale locale,
+ ClassLoader loader) {
+ ResourceBundle bundle = ResourceBundle.getBundle(baseName, locale);
+ return createUtf8PropertyResourceBundle(bundle);
+ }
+
+ private static ResourceBundle createUtf8PropertyResourceBundle(
+ ResourceBundle bundle) {
+ if (!(bundle instanceof PropertyResourceBundle))
+ return bundle;
+
+ return new Utf8PropertyResourceBundle((PropertyResourceBundle) bundle);
+ }
+
+ private static class Utf8PropertyResourceBundle extends ResourceBundle {
+ PropertyResourceBundle bundle;
+
+ private Utf8PropertyResourceBundle(PropertyResourceBundle bundle) {
+ this.bundle = bundle;
+ }
+
+ /*
+ * (non-Javadoc)
+ *
+ * @see java.util.ResourceBundle#getKeys()
+ */
+ public Enumeration getKeys() {
+ return bundle.getKeys();
+ }
+
+ /*
+ * (non-Javadoc)
+ *
+ * @see java.util.ResourceBundle#handleGetObject(java.lang.String)
+ */
+ protected Object handleGetObject(String key) {
+ String value = (String) bundle.handleGetObject(key);
+ if (value == null)
+ return null;
+ try {
+ return new String(value.getBytes("ISO-8859-1"), "UTF-8");
+ } catch (UnsupportedEncodingException e) {
+ // Shouldn't fail - but should we still add logging message?
+ return null;
+ }
+ }
+
+ }
+}
\ No newline at end of file
More information about the Schmitzm-commits
mailing list