タグ付けされた質問 「stax」

私は過去48時間、この非常に腹立たしいバグに頭を殴っていたので、ラップトップを窓から投げ出す前に、ようやくタオルを投げ入れて、ここで聞いてみようと思いました。 AWS SimpleDBに対して行った呼び出しからの応答XMLを解析しようとしています。応答は問題なく戻ってきます。たとえば、次のようになります。 <?xml version="1.0" encoding="utf-8"?> <ListDomainsResponse xmlns="http://sdb.amazonaws.com/doc/2009-04-15/"> <ListDomainsResult> <DomainName>Audio</DomainName> <DomainName>Course</DomainName> <DomainName>DocumentContents</DomainName> <DomainName>LectureSet</DomainName> <DomainName>MetaData</DomainName> <DomainName>Professors</DomainName> <DomainName>Tag</DomainName> </ListDomainsResult> <ResponseMetadata> <RequestId>42330b4a-e134-6aec-e62a-5869ac2b4575</RequestId> <BoxUsage>0.0000071759</BoxUsage> </ResponseMetadata> </ListDomainsResponse> このXMLをパーサーに渡します XMLEventReader eventReader = xmlInputFactory.createXMLEventReader(response.getContent()); eventReader.nextEvent();何度も呼び出して、必要なデータを取得します。 ここに奇妙な部分があります-ローカルサーバー内でうまく機能します。返事が来て、私はそれを解析して、みんな幸せです。問題は、コードをGoogle App Engineにデプロイしても、送信リクエストは引き続き機能し、応答XMLは100％同一で正しいように見えますが、応答は次の例外で解析に失敗します。 com.amazonaws.http.HttpClient handleResponse: Unable to unmarshall response (ParseError at [row,col]:[1,1] Message: Content is not allowed in prolog.): <?xml version="1.0" encoding="utf-8"?> …

109 java  xml  google-app-engine  parsing  stax 

SAXやStAXのようなストリーミングxmlパーサーは、DOMパーサーのようなツリー構造を構築するパーサーよりも高速でメモリ効率が高くなります。SAXはプッシュパーサーです。つまり、オブザーバーパターン（リスナーパターンとも呼ばれます）のインスタンスです。SAXが最初にありましたが、次にStAX（プルパーサー）が登場しました。これは、基本的にイテレーターのように機能することを意味します。 どこでもSAXよりもStAXを好む理由を見つけることができますが、それは通常、「使いやすい」ということになります。 JAXPに関するJavaチュートリアルでは、StAXはDOMとSAXの中間として漠然と示されています。「SAXよりも簡単で、DOMよりも効率的です」。ただし、StAXがSAXよりも低速またはメモリ効率が低いという手がかりは見つかりませんでした。 このすべてが私に不思議に思いました：StAXの代わりにSAXを選ぶ理由はありますか？

81 java  xml  xml-parsing  sax  stax