web-dev-qa-db-ja.com

ジャクソンを入力JSONに対してよりフレンドリーにする

ジャクソンの入力JSONに対する厳密さを軽減する方法はありますか？例えば。 JSONObjectは、次の許容値を提供します。

コンストラクターは、受け入れるテキストでより寛容です。

  1. 余分な（コンマ）は、閉じ中括弧の直前に表示される場合があります。
  2. 文字列は '（一重引用符）で引用できます。
  3. 文字列が引用符または一重引用符で始まらない場合、および先頭または末尾のスペースが含まれていない場合、およびこれらの文字が含まれていない場合、文字列を引用符で囲む必要はありません。{} []/\： 、=; ＃そしてそれらが数字のように見えない場合、そしてそれらが予約語true、false、またはnullでない場合。*
  4. キーの後には、=または=>、および：を続けることができます。
  5. 値の後に;を続けることができます。 （セミコロン）および、（コンマ）。
  6. 番号には0x-（16進数）プレフィックスを付けることができます。

私にとって最も興味深いのは3番目のポイントです。それは次の変換を可能にします：

new JSONObject("{A : 1}");

...しかし、jacksonの場合、同じ入力jsonでエラーが発生します。

new ObjectMapper().readTree("{ A : 1}"); // throws an exception

例外：

org.codehaus.jackson.JsonParseException: Unexpected character ('A' (code 65)): was expecting double-quote to start field name
   at [Source: Java.io.StringReader@26d4f1; line: 1, column: 4]
at org.codehaus.jackson.JsonParser._constructError(JsonParser.Java:943)
at org.codehaus.jackson.impl.JsonParserBase._reportError(JsonParserBase.Java:636)
at org.codehaus.jackson.impl.JsonParserBase._reportUnexpectedChar(JsonParserBase.Java:569)
at org.codehaus.jackson.impl.ReaderBasedParser._handleUnusualFieldName(ReaderBasedParser.Java:342)
at org.codehaus.jackson.impl.ReaderBasedParser._parseFieldName(ReaderBasedParser.Java:235)
at org.codehaus.jackson.impl.ReaderBasedParser.nextToken(ReaderBasedParser.Java:125)
at org.codehaus.jackson.map.deser.BaseNodeDeserializer.deserializeObject(JsonNodeDeserializer.Java:180)
at org.codehaus.jackson.map.deser.BaseNodeDeserializer.deserializeAny(JsonNodeDeserializer.Java:210)
at org.codehaus.jackson.map.deser.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.Java:52)
at org.codehaus.jackson.map.deser.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.Java:13)
at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.Java:1588)
at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.Java:1130)
javajsonjacksondeserialization
14
Raman

非標準のJSON（つまり、JSONではないが、サポートできるほど近いもの）の拡張機能のリストは、次の場所にあります。 http://wiki.fasterxml.com/JacksonFeaturesNonStandard

あなたのリストから、（2）と（3）を行うことができます（さらに、commnetのようなリストされていない他のいくつかのこと）。その他はサポートされていません。プロジェクトでは、一般的に使用されるいくつかの拡張機能のサポートが追加されていますが、考慮されるものには制限があります。もちろん、新しい機能を要求することはいつでも可能です。機能は、リクエスト、ユースケースに基づいて追加されます。

私の個人的な意見では、標準に従うか、新しいフォーマットを定義する必要があります。HTMLは、「ほとんどではあるが完全ではない」ものをサポートしようとするときに遭遇するネズミの穴の良い例です。微調整に終わりはなく、相互運用性にも問題があります。標準がないため、すべての実装は、互換性のない機能と構造のサブセットをサポートしています。

12
StaxMan

this 関連の質問をチェックしてください。 ObjectMapperを構成して必要なことを実行する方法を示し、それを実行したくない理由についても説明します:)

4
overthink