org.xml.sax.SAXParseException: Inhalt ist in Prolog nicht zulässig

Ich habe einen Java-basierten Webdienst-Client, der mit dem Java-Webdienst verbunden ist (implementiert auf dem Axis1-Framework).

Ich erhalte folgende Ausnahme in meiner Protokolldatei:

Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
    at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
    at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
    at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
    at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
    at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
    at javax.xml.parsers.SAXParser.parse(Unknown Source)
    at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
    at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
    at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
    at org.apache.ws.axis.security.WSDoAllReceiver.invoke(WSDoAllReceiver.java:114)
    at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
    at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
    at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
    at org.apache.axis.client.AxisClient.invoke(AxisClient.java:198)
    at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
    at org.apache.axis.client.Call.invoke(Call.java:2767)
    at org.apache.axis.client.Call.invoke(Call.java:2443)
    at org.apache.axis.client.Call.invoke(Call.java:2366)
    at org.apache.axis.client.Call.invoke(Call.java:1812)

Dies wird häufig durch ein Leerzeichen vor der XML-Deklaration verursacht, es kann sich jedoch um einen beliebigen Text wie einen Bindestrich oder ein beliebiges Zeichen handeln. Ich sage oft durch Leerzeichen verursacht, weil die Leute annehmen, dass Leerzeichen immer ignorierbar sind, aber das ist hier nicht der Fall.

Eine andere Sache , die oft passiert , ist ein UTF-8 BOM (Bytereihenfolgemarkierung), die sich vor der XML - Deklaration erlaubt als Leerzeichen behandelt werden , wenn das Dokument als ein Strom von Zeichen an einen XML - Parser übergeben wird und nicht als ein Strom von Bytes .

Das gleiche kann passieren, wenn Schemadateien (.xsd) zum Überprüfen der XML-Datei verwendet werden und eine der Schemadateien eine UTF-8-Stückliste enthält .

Eigentlich zusätzlich zu Yuriy Zubarevs Post

Wenn Sie eine nicht vorhandene XML-Datei an den Parser übergeben. Zum Beispiel passierst du

new File("C:/temp/abc")

wenn nur die Datei C: /temp/abc.xml in Ihrem Dateisystem vorhanden ist

In beiden Fällen

builder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
document = builder.parse(new File("C:/temp/abc"));

oder

DOMParser parser = new DOMParser();
parser.parse("file:C:/temp/abc");

Alle geben die gleiche Fehlermeldung aus.

Sehr enttäuschender Fehler, da die folgende Spur

javax.servlet.ServletException
    at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
...
Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
... 40 more

sagt nichts über die Tatsache aus, dass der Dateiname falsch ist oder dass eine solche Datei nicht existiert. In meinem Fall hatte ich eine absolut korrekte XML-Datei und musste 2 Tage damit verbringen, das eigentliche Problem zu ermitteln.

Versuchen Sie, ein Leerzeichen zwischen dem encoding="UTF-8" Zeichenfolge im Prolog und dem Abschluss ein ?>. In XML bezeichnet der Prolog dieses durch Klammern getrennte Element am Anfang des Dokuments (während sich das Tag-Prolog im Stapelüberlauf auf die Programmiersprache bezieht).

Hinzugefügt: Ist dieser Bindestrich vor Ihrem Prolog Teil des Dokuments? Das wäre der Fehler dort, Daten vor dem Prolog zu haben -<?xml version="1.0" encoding="UTF-8"?>.

Ich hatte das gleiche Problem (und löste es), als ich versuchte, ein XML-Dokument mit Freemarker zu analysieren.

Ich hatte keine Leerzeichen vor dem Header der XML-Datei.

Das Problem tritt nur dann auf, wenn sich die Dateicodierung und das XML-Codierungsattribut unterscheiden. (Beispiel: UTF-8-Datei mit UTF-16-Attribut im Header).

Ich hatte also zwei Möglichkeiten, das Problem zu lösen:

1. Ändern der Codierung der Datei selbst
2. Ändern des Headers UTF-16 in UTF-8

Dies bedeutet, dass XML fehlerhaft ist oder der Antworttext überhaupt kein XML-Dokument ist.

Ich habe gerade 4 Stunden damit verbracht, ein ähnliches Problem in einer WSDL aufzuspüren. Es stellte sich heraus, dass die WSDL eine XSD verwendet hat, die einen anderen Namespace XSD importiert. Diese importierte XSD enthielt Folgendes:

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://www.xyz.com/Services/CommonTypes" elementFormDefault="qualified"
    xmlns="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:CommonTypes="http://www.xyz.com/Services/CommonTypes">

 <include schemaLocation=""></include>  
    <complexType name="RequestType">
        <....

Beachten Sie das leere includeElement! Dies war die Wurzel meines Leidens. Ich denke, dies ist eine Variation von Egors Datei, die oben kein Problem gefunden hat.

+1 auf enttäuschende Fehlerberichterstattung.

In meinem Fall hat das Entfernen des Attributs 'encoding = "UTF-8" insgesamt funktioniert.

Es sieht aus wie ein Problem mit der Zeichensatzcodierung, möglicherweise weil Ihre Datei nicht wirklich in UTF-8 enthalten ist.

Meine Antwort würde Ihnen wahrscheinlich nicht helfen, aber sie hilft bei diesem Problem im Allgemeinen.

Wenn Sie diese Art von Ausnahme sehen, sollten Sie versuchen, Ihre XML-Datei in einem beliebigen Hex-Editor zu öffnen. Manchmal werden am Anfang der Datei zusätzliche Bytes angezeigt, die der Texteditor nicht anzeigt.

Löschen Sie sie und Ihre XML wird analysiert.

Manchmal ist es der Code, nicht das XML

Der folgende Code:

Document doc = dBuilder.parse(new InputSource(new StringReader("file.xml")));

wird auch zu diesem Fehler führen,

[Schwerwiegender Fehler]: 1: 1: Inhalt in prolog.org.xml.sax.SAXParseException ist nicht zulässig. lineNumber: 1; columnNumber: 1; Im Prolog ist kein Inhalt erlaubt.

weil versucht wird, das String-Literal "file.xml"(nicht den Inhalt der file.xmlDatei) zu analysieren, und weil dies fehlschlägt"file.xml" bei einem String nicht um wohlgeformtes XML handelt.

Fix: Entfernen StringReader():

Document doc = dBuilder.parse(new InputSource("file.xml"));

In ähnlicher Weise können Probleme mit verschmutztem Puffer Restmüll vor dem eigentlichen XML hinterlassen. Wenn Sie Ihr XML sorgfältig überprüft haben und dieser Fehler weiterhin angezeigt wird, protokollieren Sie den genauen Inhalt, der an den Parser übergeben wird. Manchmal ist es überraschend, was tatsächlich analysiert wird.

Erst das Projekt bereinigen, dann das Projekt neu erstellen. Ich stand auch vor dem gleichen Problem. Danach war alles in Ordnung.

Wenn alles andere fehlschlägt, öffnen Sie die Datei in Binärform, um sicherzustellen, dass am Anfang der Datei keine lustigen Zeichen [3 nicht druckbare Zeichen am Anfang der Datei, die die Datei als utf-8 identifizieren] vorhanden sind. Wir haben das gemacht und welche gefunden. Also haben wir die Datei von utf-8 nach ascii konvertiert und es hat funktioniert.

Für die gleichen Probleme habe ich die folgende Zeile entfernt:

  File file = new File("c:\\file.xml");
  InputStream inputStream= new FileInputStream(file);
  Reader reader = new InputStreamReader(inputStream,"UTF-8");
  InputSource is = new InputSource(reader);
  is.setEncoding("UTF-8");

Es funktioniert gut. Ich bin mir nicht sicher, warum UTF-8 ein Problem darstellt. Um mich unter Schock zu halten, funktioniert es auch für UTF-8.

Ich verwende Windows-7 32-Bit und Netbeans IDE mit Java * jdk1.6.0_13 *. Keine Ahnung wie es funktioniert.

Wie Mike Sokolov bereits darauf hingewiesen hat, ist einer der möglichen Gründe das Vorhandensein einiger Zeichen (z. B. Leerzeichen) vor dem Tag.

Wenn Ihre Eingabe-XML als Zeichenfolge gelesen wird (im Gegensatz zum Byte-Array), können Sie Ihre Eingabezeichenfolge durch den folgenden Code ersetzen, um sicherzustellen, dass alle nicht benötigten Zeichen vor dem XML-Tag gelöscht werden.

inputXML=inputXML.substring(inputXML.indexOf("<?xml"));

Sie müssen jedoch sicherstellen, dass die Eingabe-XML mit dem XML-Tag beginnt.

In meinem Fall hat die web.xml in meiner Anwendung zusätzlichen Speicherplatz, auch nachdem ich gelöscht habe, hat nicht funktioniert. Ich musste Chages und ihre Korrekturen zurücksetzen und ja, ich habe mit logging.properties und web.xml in meinem Tomcat gespielt, aber selbst nachdem ich die zurückgesetzt habe Fehler immer wieder angezeigt, so dass dies behoben wurde)).

Um genau zu sein, habe ich versucht, org.apache.catalina.filters.ExpiresFilter.level = FINE Stack over Flow etwas über logging.properties hinzuzufügen

Ich habe die Anweisungen hier befolgt und den gleichen Fehler erhalten.

Ich habe verschiedene Dinge versucht, um es zu lösen (dh die Codierung zu ändern, die XML-Datei einzugeben, anstatt sie zu kopieren usw.) in Notepad und XML Notepad, aber nichts hat funktioniert.

Das Problem wurde behoben, als ich meine XML-Datei in Notepad ++ bearbeitete und speicherte (Codierung -> utf-8 ohne Stückliste).

Für alle, die diesen Fehler erhalten: WARNUNG: Catalina.start using conf / server.xml: Inhalt ist in Prolog nicht zulässig.

Nicht sehr informativ. Aber was dies tatsächlich bedeutet, ist, dass Ihre Datei conf / server.xml Müll enthält.

Ich habe diesen genauen Fehler in anderen XML-Dateien gesehen. Dieser Fehler kann durch Änderungen mit einem Texteditor verursacht werden, der den Müll einführt.

Sie können überprüfen, ob die Datei Müll enthält oder nicht, indem Sie sie mit einem "HEX-Editor" öffnen, wenn Sie vor dieser Zeichenfolge ein Zeichen sehen

     "<?xml version="1.0" encoding="UTF-8"?>"

so wäre Müll

     "‰ŠŒ<?xml version="1.0" encoding="UTF-8"?>"

Das ist Ihr Problem. Die Lösung besteht darin, einen guten HEX-Editor zu verwenden. Mit diesem können Sie Dateien mit unterschiedlichen Codierungsarten speichern.

Dann speichern Sie es einfach als UTF-8. Bei einigen Systemen, die XML-Dateien verwenden, muss diese möglicherweise als UTF NO BOM gespeichert werden. Dies bedeutet "NO Byte Order Mark".

Hoffe das hilft jemandem da draußen !!

Für mich hat ein Build-> Clean alles repariert !

So beheben Sie das Stücklistenproblem auf Unix / Linux-Systemen:

1. Überprüfen Sie, ob ein unerwünschtes Stücklistenzeichen vorhanden ist: hexdump -C myfile.xml | more Ein unerwünschtes Stücklistenzeichen wird am Anfang der Datei als angezeigt...<?xml>

2. Alternativ tun file myfile.xml. Eine Datei mit einem Stücklistenzeichen wird wie folgt angezeigt:myfile.xml: XML 1.0 document text, UTF-8 Unicode (with BOM) text

3. Korrigieren Sie eine einzelne Datei mit: tail -c +4 myfile.xml > temp.xml && mv temp.xml myfile.xml

4. Wiederholen Sie 1 oder 2, um zu überprüfen, ob die Datei bereinigt wurde. Wahrscheinlich auch sinnvoll view myfile.xml, um den Inhalt zu überprüfen, sind geblieben.

Hier ist ein Bash-Skript zum Bereinigen eines ganzen Ordners mit XML-Dateien:

#!/usr/bin/env bash

# This script is to sanitise XML files to remove any BOM characters

has_bom() { head -c3 "$1" | LC_ALL=C grep -qe '\xef\xbb\xbf'; }

for filename in *.xml ; do
  if has_bom ${filename}; then
    tail -c +4 ${filename} > temp.xml
    mv temp.xml ${filename}
  fi
done

Nur ein zusätzlicher Gedanke für die Zukunft. Das Erhalten dieses Fehlers kann der Fall sein, dass man einfach zufällig die Löschtaste oder eine andere Taste drückt, wenn sie ein XML-Fenster als aktive Anzeige haben und nicht darauf achten. Dies ist mir bereits mit der Datei struts.xml in meiner Webanwendung passiert. Unbeholfene Ellbogen ...

Ich bekam auch das gleiche

XML reader error: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,2] Message: Reference is not allowed in prolog.

, als meine Anwendung eine XML-Antwort für einen RestFull Webservice-Aufruf erstellte. Beim Erstellen des XML-Format-Strings habe ich & lt und & gt durch <und> ersetzt, dann ging der Fehler aus und ich erhielt die richtige Antwort. Ich bin mir nicht sicher, wie es funktioniert hat, aber es hat funktioniert.

Beispiel :

String body = "<ns:addNumbersResponse xmlns:ns=\"http://java.duke.org\"><ns:return>"
            +sum
            +"</ns:return></ns:addNumbersResponse>";

Ich hatte das gleiche Problem.

Zuerst habe ich die XML-Datei auf den lokalen Desktop heruntergeladen und sie bekommen Content is not allowed in prolog beim Importieren der Datei auf den Portalserver erhalten. Sogar die visuelle Datei sah für mich gut aus, aber irgendwie war sie beschädigt.

Also habe ich die gleiche Datei erneut heruntergeladen und es versucht und es hat funktioniert.

Wir hatten kürzlich das gleiche Problem und es stellte sich heraus, dass es sich um eine schlechte URL und folglich um eine Standard-403-HTTP-Antwort handelte (was offensichtlich nicht das gültige XML ist, nach dem der Client gesucht hat). Ich werde das Detail teilen, falls jemand im selben Kontext auf dieses Problem stößt:

Dies war eine Spring-basierte Webanwendung, in der eine "JaxWsPortProxyFactoryBean" -Bohne konfiguriert wurde, um einen Proxy für einen Remote-Port verfügbar zu machen.

<bean id="ourPortJaxProxyService"
    class="org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean"
    p:serviceInterface="com.amir.OurServiceSoapPortWs"
    p:wsdlDocumentUrl="${END_POINT_BASE_URL}/OurService?wsdl"
    p:namespaceUri="http://amir.com/jaxws" p:serviceName="OurService"
    p:portName="OurSoapPort" />

"END_POINT_BASE_URL" ist eine Umgebungsvariable, die in "setenv.sh" der Tomcat-Instanz konfiguriert ist, die die Webanwendung hostet. Der Inhalt der Datei sieht ungefähr so ​​aus:

export END_POINT_BASE_URL="http://localhost:9001/BusinessAppServices"
#export END_POINT_BASE_URL="http://localhost:8765/BusinessAppServices"

Das fehlende ";" Nach jeder Zeile verursachte die fehlerhafte URL und damit die schlechte Antwort. Das heißt, anstelle von "BusinessAppServices / OurService? Wsdl" hatte die URL eine CR vor "/". "TCP / IP Monitor" war sehr praktisch bei der Fehlerbehebung.

In meinem Fall ist dieser Fehler aufgetreten, weil die von mir verwendete API die Daten entweder im XML- oder im JSON-Format zurückgeben konnte. Als ich es mit einem Browser getestet habe, wurde standardmäßig das XML-Format verwendet. Als ich jedoch denselben Aufruf von einer Java-Anwendung aus aufrief, gab die API die JSON-formatierte Antwort zurück, die natürlich einen Analysefehler auslöste.

Sogar ich hatte ein ähnliches Problem. Grund war ein Müllzeichen am Anfang der Datei.

Fix: Öffnen Sie die Datei einfach in einem Texteditor (getestet auf Sublime-Text), entfernen Sie eventuelle Einrückungen in der Datei und kopieren Sie den gesamten Inhalt der Datei in eine neue Datei und speichern Sie sie. Das ist es!. Als ich die neue Datei ausführte, lief sie ohne Analysefehler.

Ich habe den Code von Dineshkumar genommen und geändert, um meine XML-Datei korrekt zu validieren:

import org.apache.log4j.Logger;

public class Myclass{

private static final Logger LOGGER = Logger.getLogger(Myclass.class);

/**
 * Validate XML file against Schemas XSD in pathEsquema directory
 * @param pathEsquema directory that contains XSD Schemas to validate
 * @param pathFileXML XML file to validate
 * @throws BusinessException if it throws any Exception
 */
public static void validarXML(String pathEsquema, String pathFileXML) 
	throws BusinessException{	
	String W3C_XML_SCHEMA = "http://www.w3.org/2001/XMLSchema";
	String nameFileXSD = "file.xsd";
	String MY_SCHEMA1 = pathEsquema+nameFileXSD);
	ParserErrorHandler parserErrorHandler;
	try{
		SchemaFactory schemaFactory = SchemaFactory.newInstance(W3C_XML_SCHEMA);
		
		Source [] source = { 
			new StreamSource(new File(MY_SCHEMA1))
			};
		Schema schemaGrammar = schemaFactory.newSchema(source);

		Validator schemaValidator = schemaGrammar.newValidator();
		schemaValidator.setErrorHandler(
			parserErrorHandler= new ParserErrorHandler());
		
		/** validate xml instance against the grammar. */
		File file = new File(pathFileXML);
		InputStream isS= new FileInputStream(file);
		Reader reader = new InputStreamReader(isS,"UTF-8");
		schemaValidator.validate(new StreamSource(reader));
		
		if(parserErrorHandler.getErrorHandler().isEmpty()&& 
			parserErrorHandler.getFatalErrorHandler().isEmpty()){
			if(!parserErrorHandler.getWarningHandler().isEmpty()){
				LOGGER.info(
				String.format("WARNING validate XML:[%s] Descripcion:[%s]",
					pathFileXML,parserErrorHandler.getWarningHandler()));
			}else{
				LOGGER.info(
				String.format("OK validate  XML:[%s]",
					pathFileXML));
			}
		}else{
			throw new BusinessException(
				String.format("Error validate  XML:[%s], FatalError:[%s], Error:[%s]",
				pathFileXML,
				parserErrorHandler.getFatalErrorHandler(),
				parserErrorHandler.getErrorHandler()));
		}		
	}
	catch(SAXParseException e){
		throw new BusinessException(String.format("Error validate XML:[%s], SAXParseException:[%s]",
			pathFileXML,e.getMessage()),e);
	}
	catch (SAXException e){
		throw new BusinessException(String.format("Error validate XML:[%s], SAXException:[%s]",
			pathFileXML,e.getMessage()),e);
	}
	catch (IOException e) {
		throw new BusinessException(String.format("Error validate XML:[%s], 
			IOException:[%s]",pathFileXML,e.getMessage()),e);
	}
	
}

}

Stellen Sie Ihr Dokument folgendermaßen ein:

<?xml version="1.0" encoding="UTF-8" ?>
<root>
    %children%
</root>

Ich hatte das gleiche Problem mit dem Frühling

MarshallingMessageConverter

und durch Pre-Proccess-Code.

Vielleicht braucht jemand Grund: BytesMessage #readBytes - Lesen von Bytes .. und ich habe vergessen, dass das Lesen eine Einrichtungsoperation ist. Sie können nicht zweimal lesen.

Versuchen Sie es mit BOMInputStream in apache.commons.io:

public static <T> T getContent(Class<T> instance, SchemaType schemaType, InputStream stream) throws JAXBException, SAXException, IOException {

    JAXBContext context = JAXBContext.newInstance(instance);
    Unmarshaller unmarshaller = context.createUnmarshaller();
    Reader reader = new InputStreamReader(new BOMInputStream(stream), "UTF-8");

    JAXBElement<T> entry = unmarshaller.unmarshal(new StreamSource(reader), instance);

    return entry.getValue();
}

Ich hatte das gleiche Problem beim Parsen der info.plistDatei auf meinem Mac. Das Problem wurde jedoch mit dem folgenden Befehl behoben, mit dem die Datei in XML umgewandelt wurde.

plutil -convert xml1 info.plist

Hoffe das hilft jemandem.

Ich hatte das gleiche Problem mit einigen XML-Dateien. Ich habe das Lesen der Datei mit ANSI-Codierung (Windows-1252) und das Schreiben einer Datei mit UTF-8-Codierung mit einem kleinen Skript in Python gelöst. Ich habe versucht, Notepad ++ zu verwenden, aber ich hatte keinen Erfolg:

import os
import sys

path = os.path.dirname(__file__)

file_name = 'my_input_file.xml'

if __name__ == "__main__":
    with open(os.path.join(path, './' + file_name), 'r', encoding='cp1252') as f1:
        lines = f1.read()
        f2 = open(os.path.join(path, './' + 'my_output_file.xml'), 'w', encoding='utf-8')
        f2.write(lines)
        f2.close()