You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently CharacterEscapes allows for specifying custom escapes in general, as well as optimized checks for ASCII range of characters (as performance optimization).
But one internal optimization is not exposed via this interface: ability to indicate that "any character codes beyond N" (for example, above 7-bit ASCII range) are to be escaped using standard character escapes.
The reason this would be useful addition is that it would be more efficient for relatively common case of, say, escaping additional HTML characters AND non-ASCII or non-Latin1 characters as well.
Addition could be made in 2.10: but instead of adding this to CharacterEscapes, it makes more sense to use new builder-based factory configuration, I think: mostly because it will be easier to keep pathway optimized -- behavior in much of code being that setting of non-null CharacterEscapes will trigger different encoding pathway.
The text was updated successfully, but these errors were encountered:
cowtowncoder
changed the title
Add "maximum unescaped char" limit option in CharacterEscapes
Add "maximum unescaped char" configuration option for JsonFactory via builder
Jan 15, 2019
Ok, so this is doable. The only (?) unfortunate part is that with 2.10, type erasure, configuration is somewhat cumbersome for regular JsonFactory (casts needed). Will not be a problem with 3.0, fortunately.
Currently
CharacterEscapes
allows for specifying custom escapes in general, as well as optimized checks for ASCII range of characters (as performance optimization).But one internal optimization is not exposed via this interface: ability to indicate that "any character codes beyond N" (for example, above 7-bit ASCII range) are to be escaped using standard character escapes.
The reason this would be useful addition is that it would be more efficient for relatively common case of, say, escaping additional HTML characters AND non-ASCII or non-Latin1 characters as well.
Addition could be made in 2.10: but instead of adding this to
CharacterEscapes
, it makes more sense to use new builder-based factory configuration, I think: mostly because it will be easier to keep pathway optimized -- behavior in much of code being that setting of non-nullCharacterEscapes
will trigger different encoding pathway.The text was updated successfully, but these errors were encountered: