On Mon, Apr 30, 2018 at 4:40 PM, Matthew Hall <[email protected]> wrote: > On Mon, Apr 30, 2018 at 4:34 PM, Tatu Saloranta <[email protected]> wrote: >> >> >> Right, these are not really defined as extension points. >> >> What might work better is defining `InputDecorator`, which you can >> register with `JsonFactory`. >> It will allow dynamic wrapping of passed-in `Reader` or `InputStream`. >> And then you don't have to worry about internal details of actually >> constructing parser instance. >> Approach may also work with other formats, whereas extending of >> factory directly would not. >> >> I hope this helps, >> >> -+ Tatu +- > > > I'd love to do it that way for sure, but I believe that this input JSON is > too broken to employ that sort of approach. > > Each String variable value inside the JSON can have a different encoding! > Imagine something truly impressively awful, like this: > > { "utf8": "SOME_UTF8_STRING", "ascii": "SOME_ASCII_STRING", "shift-jis": > "SOME_SHIFT_JIS_STRING", "latin1": "SOME_LATIN1_STRING", ... } > > Therefore trying to fix the encoding of this whole input at the Reader or > InputStream level isn't enough. I have to check it each time a new > String-valued field is created in the parser itself, I think. > > I have a class which should be close to doing this, but I need to understand > how to construct the inputs to this parser so I can test it and see what is > going to happen, I mean how my code is going to crash first. ;)
Ok then you are unfortunately on your own. You can try sub-classing and it may work (or may break at some point). Good luck! -+ Tatu +- -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
