org.xml.sax.SAXParseException: le contenu n'est pas autorisé dans le prologue

J'ai un client de service Web basé sur Java connecté au service Web Java (implémenté sur le framework Axis1).

Je reçois l'exception suivante dans mon fichier journal:

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)

Cela est souvent causé par un espace blanc avant la déclaration XML, mais il peut s'agir de n'importe quel texte , comme un tiret ou n'importe quel caractère. Je dis souvent causé par un espace blanc parce que les gens supposent que l'espace blanc est toujours ignorable, mais ce n'est pas le cas ici.

Une autre chose qui se produit souvent est une nomenclature UTF-8 (marque d'ordre d'octet), qui est autorisée avant que la déclaration XML puisse être traitée comme un espace si le document est transmis comme un flux de caractères à un analyseur XML plutôt que comme un flux d'octets .

La même chose peut se produire si des fichiers de schéma (.xsd) sont utilisés pour valider le fichier xml et que l'un des fichiers de schéma a une nomenclature UTF-8 .

En fait, en plus du message de Yuriy Zubarev

Lorsque vous transmettez un fichier xml inexistant à l'analyseur. Par exemple vous passez

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

lorsque seul le fichier C: /temp/abc.xml existe sur votre système de fichiers

Dans tous les cas

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

ou

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

Tous donnent le même message d'erreur.

Bug très décevant, car la trace suivante

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

ne dit rien sur le fait que «le nom du fichier est incorrect» ou «un tel fichier n'existe pas». Dans mon cas, j'avais un fichier xml absolument correct et j'ai dû passer 2 jours pour déterminer le vrai problème.

Essayez d'ajouter un espace entre la encoding="UTF-8"chaîne du prologue et la terminaison ?>. En XML, le prologue désigne cet élément délimité par un point d'interrogation entre crochets au début du document (tandis que la balise prologue dans stackoverflow fait référence au langage de programmation).

Ajouté: Ce tiret devant votre prologue fait-il partie du document? Ce serait l'erreur là, ayant des données devant la Prolog, -<?xml version="1.0" encoding="UTF-8"?>.

J'ai eu le même problème (et je l'ai résolu) en essayant d'analyser un document XML avec freemarker.

Je n'avais aucun espace avant l'en-tête du fichier XML.

Le problème se produit lorsque et uniquement lorsque le codage de fichier et l'attribut de codage XML sont différents. (ex: fichier UTF-8 avec attribut UTF-16 dans l'en-tête).

J'avais donc deux façons de résoudre le problème:

1. changer l'encodage du fichier lui-même
2. changer l'en-tête UTF-16 en UTF-8

Cela signifie que XML est mal formé ou que le corps de la réponse n'est pas du tout un document XML.

Je viens de passer 4 heures à rechercher un problème similaire dans un WSDL. Il s'avère que le WSDL a utilisé un XSD qui importe un autre espace de noms XSD. Ce XSD importé contenait les éléments suivants:

<?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">
        <....

Notez l' includeélément vide ! C'était la racine de mes malheurs. Je suppose que c'est une variation du problème de fichier d'Egor introuvable ci-dessus.

+1 au rapport d'erreur décevant.

Dans mon cas, la suppression de l'attribut 'encoding = "UTF-8"' a tout à fait fonctionné.

Cela ressemble à un problème d'encodage de jeu de caractères, peut-être parce que votre fichier n'est pas vraiment en UTF-8.

Ma réponse ne vous aiderait probablement pas, mais elle aide généralement à résoudre ce problème.

Lorsque vous voyez ce type d'exception, vous devriez essayer d'ouvrir votre fichier xml dans n'importe quel éditeur hexadécimal et parfois vous pouvez voir des octets supplémentaires au début du fichier que l'éditeur de texte n'affiche pas.

Supprimez-les et votre xml sera analysé.

Parfois, c'est le code, pas le XML

Le code suivant,

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

entraînera également cette erreur,

[Erreur fatale]: 1: 1: le contenu n'est pas autorisé dans prolog.org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; Le contenu n'est pas autorisé dans le prologue.

car il tente d'analyser la chaîne littérale "file.xml"(pas le contenu du file.xmlfichier) et échoue car en "file.xml"tant que chaîne, le XML n'est pas bien formé.

Correction: Supprimer StringReader():

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

De même, des problèmes de tampon sale peuvent laisser des fichiers indésirables résiduels avant le XML réel. Si vous avez soigneusement vérifié votre XML et que vous obtenez toujours cette erreur, consignez le contenu exact transmis à l'analyseur; parfois, ce qui est réellement analysé (essayé d'être) est surprenant.

Tout d'abord nettoyer le projet, puis reconstruire le projet. J'étais également confronté au même problème. Tout s'est bien passé après cela.

Si tout le reste échoue, ouvrez le fichier en binaire pour vous assurer qu'il n'y a pas de caractères amusants [3 caractères non imprimables au début du fichier qui identifient le fichier comme utf-8] au début du fichier. Nous l'avons fait et en avons trouvé. nous avons donc converti le fichier de utf-8 en ascii et cela a fonctionné.

Pour les mêmes problèmes, j'ai supprimé la ligne suivante,

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

Cela fonctionne bien. Je ne sais pas trop pourquoi cet UTF-8 pose problème. Pour me garder sous le choc, cela fonctionne bien pour UTF-8 également.

J'utilise Windows-7 32 bits et Netbeans IDE avec Java * jdk1.6.0_13 *. Aucune idée de comment cela fonctionne.

Comme Mike Sokolov l'a déjà souligné, l'une des raisons possibles est la présence de certains caractères (comme un espace) avant la balise.

Si votre XML d'entrée est lu comme une chaîne (par opposition à un tableau d'octets), vous pouvez utiliser le remplacement de votre chaîne d'entrée par le code ci-dessous pour vous assurer que tous les caractères `` inutiles '' avant la balise xml sont effacés.

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

Vous devez cependant vous assurer que le xml d'entrée commence par la balise xml.

Dans mon cas, le web.xml dans mon application a un espace supplémentaire même après que j'ai supprimé n'a pas fonctionné, j'ai dû annuler les chages et ses correctifs et oui je jouais avec logging.properties et web.xml dans mon chat mais même après avoir inversé le l'erreur a continué à s'afficher, donc cela l'a corrigé)).

Pour être précis, j'ai essayé d'ajouter org.apache.catalina.filters.ExpiresFilter.level = FINE stack overflow quelque chose à propos de logging.properties

J'ai suivi les instructions trouvées ici et j'ai eu la même erreur.

J'ai essayé plusieurs choses pour le résoudre (c'est-à-dire changer l'encodage, taper le fichier XML plutôt que le copier-coller, etc.) dans le Bloc-notes et le Bloc-notes XML, mais rien n'a fonctionné.

Le problème a été résolu lorsque j'ai édité et enregistré mon fichier XML dans Notepad ++ (encodage -> utf-8 sans BOM)

Pour tous ceux qui obtiennent cette erreur: AVERTISSEMENT: Catalina.start en utilisant conf / server.xml: Le contenu n'est pas autorisé dans prolog.

Pas très informatif ... mais ce que cela signifie en fait, c'est qu'il y a des déchets dans votre fichier conf / server.xml.

J'ai vu cette erreur exacte dans d'autres fichiers XML .. cette erreur peut être causée en apportant des modifications avec un éditeur de texte qui introduit la poubelle.

La façon dont vous pouvez vérifier si vous avez des déchets dans le fichier est de l'ouvrir avec un "HEX Editor" Si vous voyez un caractère avant cette chaîne

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

comme ça serait des ordures

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

c'est votre problème .... La solution est d'utiliser un bon éditeur HEX .. Un qui vous permettra d'enregistrer des fichiers avec différents types d'encodage ..

Ensuite, enregistrez-le simplement au format UTF-8. Certains systèmes qui utilisent des fichiers XML peuvent avoir besoin de les enregistrer sous UTF NO BOM, ce qui signifie avec "NO Byte Order Mark"

J'espère que cela aide quelqu'un là-bas !!

Pour moi, un Build-> Clean a tout réglé!

Pour résoudre le problème de nomenclature sur les systèmes Unix / Linux:

1. Vérifiez s'il y a un caractère de nomenclature indésirable: hexdump -C myfile.xml | more un caractère de nomenclature indésirable apparaîtra au début du fichier comme...<?xml>

2. Sinon, faites-le file myfile.xml. Un fichier avec un caractère de nomenclature apparaîtra comme:myfile.xml: XML 1.0 document text, UTF-8 Unicode (with BOM) text

3. Corrigez un seul fichier avec: tail -c +4 myfile.xml > temp.xml && mv temp.xml myfile.xml

4. Répétez 1 ou 2 pour vérifier que le fichier a été nettoyé. Il est probablement également judicieux de view myfile.xmlvérifier que le contenu est resté.

Voici un script bash pour nettoyer tout un dossier de fichiers XML:

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

Juste une réflexion supplémentaire sur celui-ci pour le futur. Obtenir ce bogue pourrait être le cas où l'on frappe simplement la touche de suppression ou une autre touche au hasard quand ils ont une fenêtre XML comme affichage actif et ne font pas attention. Cela m'est déjà arrivé avec le fichier struts.xml dans mon application Web. Coudes maladroits ...

J'avais aussi la même chose

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

, lorsque mon application créait une réponse XML pour un appel RestFull Webservice. Lors de la création de la chaîne de format XML, j'ai remplacé les & lt et & gt par <et>, puis l'erreur s'est produite et j'ai obtenu une réponse appropriée. Je ne sais pas comment cela a fonctionné mais cela a fonctionné.

échantillon :

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

J'ai eu le même problème.

J'ai d'abord téléchargé le fichier XML sur le bureau local et j'ai obtenu Content is not allowed in prolog lors de l'importation du fichier sur le serveur de portail. Même visuellement, le fichier me paraissait bien, mais il était corrompu.

J'ai donc retéléchargé le même fichier et essayé la même chose et cela a fonctionné.

Nous avons eu le même problème récemment et il s'est avéré être le cas d'une mauvaise URL et par conséquent d'une réponse HTTP 403 standard (qui n'est évidemment pas le XML valide recherché par le client). Je vais partager les détails au cas où quelqu'un dans le même contexte rencontrerait ce problème:

Il s'agissait d'une application Web basée sur Spring dans laquelle un bean "JaxWsPortProxyFactoryBean" était configuré pour exposer un proxy pour un port distant.

<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" est une variable d'environnement configurée dans "setenv.sh" de l'instance Tomcat qui héberge l'application Web. Le contenu du fichier ressemble à ceci:

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

Disparus ";" après chaque ligne a provoqué l'URL malformée et donc la mauvaise réponse. Autrement dit, au lieu de "BusinessAppServices / OurService? Wsdl", l'URL avait un CR avant "/". "TCP / IP Monitor" était assez pratique pour résoudre le problème.

Dans mon cas, j'ai eu cette erreur car l'API que j'ai utilisée pouvait renvoyer les données au format XML ou JSON. Lorsque je l'ai testé à l'aide d'un navigateur, il était par défaut au format XML, mais lorsque j'ai appelé le même appel à partir d'une application Java, l'API a renvoyé la réponse au format JSON, ce qui a naturellement déclenché une erreur d'analyse.

Même moi, j'avais été confronté à un problème similaire. La raison était un caractère de garbage au début du fichier.

Correction: il suffit d'ouvrir le fichier dans un éditeur de texte (testé sur Sublime text), de supprimer tout retrait le cas échéant dans le fichier et de copier-coller tout le contenu du fichier dans un nouveau fichier et de le sauvegarder. C'est tout!. Lorsque j'ai exécuté le nouveau fichier, il s'est exécuté sans aucune erreur d'analyse.

J'ai pris le code de Dineshkumar et modifié pour valider correctement mon fichier XML:

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

}

Configurez votre document pour qu'il forme comme ceci:

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

J'ai eu le même problème avec le printemps

MarshallingMessageConverter

et par code de pré-processus.

Peut-être que quelqu'un aura besoin d'une raison: BytesMessage #readBytes - lecture d'octets .. et j'ai oublié que la lecture est une opération à sens unique. Vous ne pouvez pas lire deux fois.

Essayez avec BOMInputStream dans 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();
}

J'avais le même problème lors de l'analyse du info.plistfichier dans mon mac. Cependant, le problème a été résolu à l'aide de la commande suivante qui a transformé le fichier en XML.

plutil -convert xml1 info.plist

J'espère que cela aide quelqu'un.

J'ai eu le même problème avec certains fichiers XML, j'ai résolu la lecture du fichier avec un encodage ANSI (Windows-1252) et l'écriture d'un fichier avec un encodage UTF-8 avec un petit script en Python. J'ai essayé d'utiliser Notepad ++ mais je n'ai pas réussi:

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