[
https://issues.apache.org/jira/browse/LANG-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717203#action_12717203
]
Henri Yandell commented on LANG-505:
------------------------------------
unescapeJava was quite implementable - though I'm changing behaviour from
passing on a last char being an escaping \ without a value to escape to it
being removed (and in fact I think the correct behaviour would be an exception).
unescapeCsv + escapeCsv were hugely easy. Same for escapeJavaScript.
HTML and XML left, while I'm left wondering if all I'm doing is writing a very
dumb Regexp engine and it would be better to replace the entire
StringEscapeUtils with a RegexUtils that defines various standard Regexs and
lets you build your own. While huge numbers of non-grouping alternation might
be considered poor performance in a regex, I doubt it's any worse than my own
code.
Will attach code for people's perusal.
> Rewrite StringEscapeUtils
> -------------------------
>
> Key: LANG-505
> URL: https://issues.apache.org/jira/browse/LANG-505
> Project: Commons Lang
> Issue Type: Task
> Reporter: Henri Yandell
> Fix For: 3.0
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
