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

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 dieselbe Fehlermeldung aus.

Sehr enttäuschender Bug, weil 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 "Dateiname falsch ist" oder "eine solche Datei existiert nicht". In meinem Fall hatte ich eine absolut korrekte XML-Datei und musste 2 Tage verbringen, um das eigentliche Problem zu ermitteln.

Fügen Sie ein Leerzeichen zwischen der encoding="UTF-8"-Zeichenfolge im Prolog und dem abschließenden ?> ein. In XML bezeichnet der Prolog dieses durch Klammerzeichen getrennte Element am Anfang des Dokuments (während der Tag Prolog in stackoverflow sich auf die Programmiersprache bezieht).

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

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

Ich hatte das gleiche Problem (und das Problem gelöst), 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. die Kodierung der Datei selbst ändern
2. Ändern Sie den Header UTF-16 in UTF-8

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, 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 include-Element! Dies war die Wurzel meines Leids. Ich denke, das ist eine Variation von Egors Datei, die oben nicht gefunden wurde. 

+1 zu enttäuschender Fehlermeldung.

In meinem Fall funktionierte das Entfernen des Attributs 'coding = "UTF-8" insgesamt.

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

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

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-Datei wird analysiert. 

Wie Mike Sokolov bereits darauf hingewiesen hat, besteht einer der möglichen Gründe darin, dass einige Zeichen vor dem Tag vorhanden sind (z. B. ein Leerzeichen).

Wenn Ihre Eingabe-XML als String gelesen wird (im Gegensatz zum Byte-Array), können Sie Verwenden, um Ihre Eingabezeichenfolge durch den folgenden Code zu ersetzen, um sicherzustellen, dass alle "nicht benötigten" -Zeichen vor dem XML-Tag vorhanden sind abgewischt werden.

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

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

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. Nicht so sicher, warum UTF-8 Probleme bereitet. Um mich unter Schock zu halten, funktioniert es auch für UTF-8.

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

Reinigen Sie zuerst das Projekt, und erstellen Sie dann das Projekt neu. Ich stand auch vor demselben Problem. Danach kam alles gut. 

Wenn alles andere fehlschlägt, öffnen Sie die Datei als Binärdatei, um sicherzustellen, dass sich am Anfang der Datei keine lustigen Zeichen befinden [3 nicht druckbare Zeichen, die die Datei als utf-8 kennzeichnen] am Anfang der Datei. Wir haben das gemacht und einiges gefunden. also haben wir die datei von utf-8 nach ascii konvertiert und es hat funktioniert. 

Manchmal ist es der Code, nicht der XML-Code

Der folgende Code

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

führt auch zu diesem Fehler,

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

da es versucht, das Zeichenfolgenliteral zu analysieren, "file.xml" (nicht den Inhalt der file.xml-Datei), und der Vorgang fehlschlägt, weil "file.xml" als Zeichenfolge kein ordnungsgemäß formatiertes XML ist.

Fix: Entfernen Sie StringReader():

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

In ähnlicher Weise können Dirty-Puffer-Probleme einen Restmüll vor dem eigentlichen XML-Code hinterlassen. Wenn Sie Ihre XML-Datei sorgfältig geprüft haben und immer noch diesen Fehler erhalten, protokollieren Sie den genauen Inhalt, der an den Parser übergeben wird. Manchmal ist es überraschend, was tatsächlich analysiert wird.

Für alle, die diesen Fehler erhalten: WARNUNG: Catalina.start mit conf/server.xml: In prolog ist kein Inhalt zulässig.

Nicht sehr informativ. Was dies jedoch bedeutet, ist, dass Ihre conf/server.xml-Datei 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 Papierkorb einführt.

Sie können überprüfen, ob Sie Müll in der Datei haben oder nicht, indem Sie sie mit einem "HEX-Editor" öffnen, wenn Sie ein Zeichen vor dieser Zeichenfolge 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 es möglicherweise als UTF NO BOM .__ gespeichert werden. Dies bedeutet "NO Byte Order Mark".

Hoffe das hilft jemand da draußen !!

Ich folgte den Anweisungen hier und bekam den gleichen Fehler.

Ich habe verschiedene Dinge versucht, um das Problem zu lösen (dh, die Kodierung zu ändern, die XML-Datei einzugeben, statt sie zu kopieren, ect zu kopieren), und zwar in Notepad und XML Notepad, aber nichts hat funktioniert.

Das Problem wurde behoben, als ich meine XML-Datei in Notepad ++ bearbeitet und gespeichert habe (Kodierung -> utf-8 ohne Stückliste).

In meinem Fall hat das web.xml in meiner Anwendung zusätzlichen Speicherplatz, obwohl das Löschen nicht funktioniert hat. Ich musste die Chages und ihre Korrekturen rückgängig machen und ja, ich habe mit gespielt. logging.properties und web.xml in meinem Tomcat, aber selbst nachdem ich den Fehler zurückgesetzt hatte, wurde weiterhin angezeigt, so dass dies behoben wurde)).

Um genau zu sein, habe ich versucht, org.Apache.catalina.filters.ExpiresFilter.level = FINE Stack überflutet etwas mit logging.properties

Selbst ich war mit einem ähnlichen Problem konfrontiert. Grund war ein Müllzeichen am Anfang der Datei. 

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

Ich hatte das gleiche Problem.

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

Also lade ich die gleiche Datei erneut herunter und versuchte es gleich und es hat funktioniert.

In meinem Fall habe ich diese Fehlermeldung erhalten, weil die von mir verwendete API die Daten entweder im XML- oder im JSON-Format zurückgeben konnte. Beim Testen mit einem Browser wurde standardmäßig das XML-Format verwendet. Als ich jedoch denselben Aufruf von einer Java-Anwendung aus aufgerufen hatte, gab die API die JSON-formatierte Antwort zurück, die natürlich einen Parsing-Fehler auslöste.

Ich habe Code von Dineshkumar genommen und geändert, um meine XML-Datei korrekt zu überprüfen:

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);
	}
	
}

}

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

Dies war eine Spring-basierte Webanwendung, in der eine Bean "JaxWsPortProxyFactoryBean" so konfiguriert wurde, dass ein Proxy für einen Remote-Port verfügbar gemacht wird.

<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 bei der Problembehandlung sehr praktisch.

Für mich 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 ...<?xml> angezeigt.

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

3. Repariere 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 ist es auch sinnvoll, view myfile.xml zu tun, um zu überprüfen, ob Inhalte erhalten geblieben sind.

Hier ist ein Bash-Skript, mit dem Sie einen ganzen Ordner mit XML-Dateien bereinigen können:

#!/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

Ich habe auch dasselbe bekommen 

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

, wenn meine Anwendung eine XML-Antwort für einen RestFull Webservice-Aufruf erstellt hat. Beim Erstellen des XML-Formats String habe ich & lt und & gt durch <und> ersetzt. Der Fehler wurde behoben und ich erhielt die richtige Antwort. Nicht sicher, wie es funktioniert hat, aber es hat funktioniert.

Probe :

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

Stellen Sie Ihr Dokument so ein:

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

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();
}

Nur ein zusätzlicher Gedanke für die Zukunft. Wenn Sie diesen Fehler erhalten, kann es passieren, dass Sie einfach die Löschtaste oder eine andere Taste zufällig drücken, wenn sie ein XML-Fenster als aktive Anzeige haben und nicht aufpassen. Dies ist mir zuvor mit der Datei struts.xml in meiner Webanwendung passiert. Unbeholfene Ellbogen ...

Ich hatte das gleiche Problem mit dem Frühling 

MarshallingMessageConverter

und durch Pre-Process-Code.

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

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

plutil -convert xml1 info.plist

Hoffe das hilft jemandem.