Description
I think StringEscapeUtils needs a strong rewrite. For each escape method (and unescape) there tend to be three or four types of escaping happening. So not being able to define which set of three or four apply is a pain point (and cause of bug reports due to different desired features).
We should be offering basic functionality, but also allowing people to say "escape(Escapers.BASIC_XML, Escapers.LOW_UNICODE, Escapers.HIGH_UNICODE)".
Also should delete escapeSql; it's a bad one imo. Dangerous in that it will lead people to not use PreparedStatement and given it only escapes ', it's not much use. Especially as different dialects escape that in different ways.
Opening this ticket for discussion.
Attachments
Attachments
Issue Links
- is related to
-
LANG-66 [lang] StringEscaper.escapeXml() escapes characters > 0x7f
- Closed
-
LANG-339 StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanese, etc.
- Closed
-
LANG-439 StringEscapeUtils.escapeHTML() does not escape chars (0x00-0x20)
- Closed
-
LANG-448 Lower Ascii Characters don't get encoded by Entities.java
- Closed
-
LANG-506 Entities - missing final modifiers; thread-safety issues
- Closed
-
LANG-498 Add StringEscapeUtils.escapeText() methods
- Closed
-
LANG-293 StringEscapeUtils.unescape* can be faster
- Closed
-
LANG-204 [lang] org.apache.commons.lang.Entities multithreaded init.
- Closed
-
LANG-507 StringEscapeUtils.unescapeJava should support \u+ notation
- Closed
- relates to
-
LANG-515 Define standard escape/unescape behaviours
- Closed