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 l'infrastructure 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 avant la déclaration XML, mais il peut s'agir de de n'importe quel texte , comme d'un tiret ou de tout 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 un UTF-8 BOM (marque d'ordre des octets), est autorisé avant que la déclaration XML puisse être traitée comme un espace si le document est transmis sous forme de flux de caractères à un fichier XML analyseur plutôt que comme un flux d'octets.
La même chose peut arriver 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 un UTF-8 BOM .
En fait, en plus du post de Yuriy Zubarev
Lorsque vous transmettez un fichier XML inexistant à l’analyseur. Par exemple vous passez
new File("C:/temp/abc")
quand 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 parfaitement correct et je devais passer 2 jours à déterminer le vrai problème.
Essayez d'ajouter un espace entre la chaîne encoding="UTF-8" dans le prologue et le ?> final. En XML, le prologue désigne cet élément délimité par un point d'interrogation entre crochets au début du document (alors que le prologue de balise dans stackoverflow fait référence au langage de programmation).
Ajouté: Est-ce que ce tiret devant votre partie prologue du document? Ce serait l’erreur là, avoir des données devant le prologue, -<?xml version="1.0" encoding="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.
J'ai eu le même problème (et l'ai résolu) en essayant d'analyser un document XML avec freemarker.
Je n'avais pas d'espaces avant l'en-tête du fichier XML.
Le problème se produit quand et seulement quand le codage de fichier et l'attribut de codage XML sont différents. (ex: fichier UTF-8 avec l'attribut UTF-16 dans l'en-tête).
J'ai donc eu deux façons de résoudre le problème:
- changer l'encodage du fichier lui-même
- changer l'en-tête UTF-16 en UTF-8
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 XSD d'espace de noms Ce fichier XSD importé contient 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'élément include vide! C'était la racine de mes malheurs. Je suppose que ceci est une variante du fichier non trouvé d'Egor ci-dessus.
+1 pour signaler des erreurs décevantes.
Dans mon cas, supprimer l'attribut 'encoding = "UTF-8"' fonctionnait parfaitement.
Cela ressemble à un problème d’encodage du 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 aiderait à résoudre ce problème en général.
Lorsque vous voyez ce type d'exception, vous devez essayer d'ouvrir votre fichier xml dans n'importe quel éditeur hexadécimal et parfois afficher au début du fichier des octets supplémentaires que l'éditeur de texte ne montre pas.
Supprimez-les et votre XML sera analysé.
Comme Mike Sokolov l'a déjà signalé, l'une des raisons possibles est la présence de caractère (par exemple, un espace) avant la balise.
Si votre XML d'entrée est lu en tant que chaîne (par opposition à un tableau d'octets), vous pouvez alors remplacer votre chaîne d'entrée par le code ci-dessous pour vous assurer que tous les caractères "inutiles". 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.
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. Pas si sûr pourquoi cet UTF-8 donne problème. Pour que je sois sous le choc, cela fonctionne également pour UTF-8.
J'utilise Windows-7 32 bits et Netbeans IDE avec Java * jdk1.6.0_13 *. Aucune idée de comment ça marche.
Tout d'abord, nettoyez le projet, puis reconstruisez le projet. Je faisais également face au même problème. Tout s'est bien passé après cela.
Si tout é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 identifiant le fichier comme étant utf-8] au début du fichier. Nous l'avons fait et en avons trouvé. Nous avons donc converti le fichier utf-8 en ascii et cela a fonctionné.
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; numéro de ligne: 1; numéro de colonne: 1; Le contenu n'est pas autorisé dans prolog.
parce qu'il tente d'analyser le littéral de chaîne, "file.xml" (pas le contenu du fichier file.xml) et échoue car "file.xml" en tant que chaîne n'est pas un XML bien formé.
Correction: Supprimer StringReader():
Document doc = dBuilder.parse(new InputSource("file.xml"));
De la même façon, des problèmes de tampon encrassés peuvent laisser les fichiers inutiles en avance sur le XML réel. Si vous avez soigneusement vérifié votre XML et obtenez toujours cette erreur, enregistrez le contenu exact transmis à l'analyseur; Parfois, ce qui est réellement (essayé d'être) analysé est surprenant.
Pour tous ceux qui obtiennent cette erreur: AVERTISSEMENT: Catalina.start utilisant conf/server.xml: le contenu n'est pas autorisé dans prolog.
Pas très informatif .. mais cela signifie en réalité que votre fichier conf/server.xml contient des ordures.
J'ai vu cette erreur exacte dans d'autres fichiers XML. Cette erreur peut être provoquée en apportant des modifications à l'aide d'un éditeur de texte introduisant la corbeille.
La façon dont vous pouvez vérifier si vous avez des ordures dans le fichier consiste à l'ouvrir avec un "HEX Editor" Si vous voyez un caractère avant cette chaîne
"<?xml version="1.0" encoding="UTF-8"?>"
comme ce serait des ordures
"‰ŠŒ<?xml version="1.0" encoding="UTF-8"?>"
c’est votre problème. La solution consiste à utiliser un bon éditeur HEX. Celui qui vous permettra d’enregistrer des fichiers avec différents types d’encodage.
Puis, sauvegardez-le simplement au format UTF-8 . Certains systèmes utilisant des fichiers XML peuvent nécessiter un enregistrement au format UTF NO BOM Ce qui signifie "NO Byte Order Mark".
J'espère que cela aide quelqu'un là-bas !!
J'ai suivi les instructions trouvées ici et j'ai eu la même erreur.
J'ai essayé plusieurs solutions pour la résoudre (changer l'encodage, taper le fichier XML plutôt que de la copier-coller, etc.) dans Notepad et XML Notepad mais rien ne fonctionnait.
Le problème a été résolu lorsque j'ai édité et enregistré mon fichier XML dans Notepad ++ (encodage -> utf-8 sans nomenclature).
Dans mon cas, le web.xml de mon application dispose d'un espace supplémentaire, même après la suppression de mon travail, je ne devais pas rétablir les chages et ses correctifs .__ et oui, je jouais avec logging.properties et web.xml dans mon Tomcat mais même après avoir annulé l’erreur persistante, cette erreur a été corrigée)).
Pour être plus précis, j’ai essayé d’ajouter org.Apache.catalina.filters.ExpiresFilter.level = FINEun dépassement de flux à propos de logging.properties
Même moi j'avais rencontré un problème similaire. La raison était un caractère de mémoire au début du fichier.
Solution: ouvrez simplement le fichier dans un éditeur de texte (testé sur Sublime), supprimez tout retrait éventuel dans le fichier et copiez-collez tout le contenu du fichier dans un nouveau fichier et enregistrez-le. C'est tout!. Lorsque j'ai exécuté le nouveau fichier, il s'est exécuté sans erreur d'analyse.
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 reçu Content is not allowed in prolog lors de l'importation du fichier sur le serveur de portail. Même visuellement, le fichier me paraissait bon, mais il était corrompu.
Alors j'ai re-téléchargé le même fichier et essayé la même chose et cela a fonctionné.
Dans mon cas, j'ai eu cette erreur parce que 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, le format XML par défaut, mais lorsque j'ai appelé le même appel depuis une application Java, l'API a renvoyé la réponse au format JSON, ce qui a naturellement déclenché une erreur d'analyse.
J'ai pris le code de Dineshkumar et modifié pour valider mon fichier XML correctement:
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);
}
}
}Nous avons eu le même problème récemment et il s’est avéré qu’il s’agissait d’une mauvaise URL et, par conséquent, d’une réponse HTTP 403 standard (ce qui, de toute évidence, n’est pas le code XML valide recherché par le client). Je vais partager les détails au cas où quelqu'un dans le même contexte se heurterait à 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é et donc la mauvaise réponse. C'est-à-dire qu'au lieu de "BusinessAppServices/OurService? Wsdl", l'URL avait un CR avant "/". "Moniteur TCP/IP" était assez pratique pour résoudre le problème.
Pour moi, un Build-> Clean tout corrigé!
Pour résoudre le problème de nomenclature sur les systèmes Unix/Linux:
Vérifiez s'il y a un caractère de nomenclature indésirable:
hexdump -C myfile.xml | moreUn caractère de nomenclature indésirable apparaîtra au début du fichier sous la forme...<?xml>Sinon, faites
file myfile.xml. Un fichier avec un caractère de nomenclature apparaîtra comme suit:myfile.xml: XML 1.0 document text, UTF-8 Unicode (with BOM) textFixer un seul fichier avec:
tail -c +4 myfile.xml > temp.xml && mv temp.xml myfile.xmlRépétez 1 ou 2 pour vérifier que le fichier a été nettoyé. Probablement aussi judicieux de faire
view myfile.xmlpour vérifier 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
J'avais aussi le même
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 formatage XML, j'ai remplacé les balises & lt et & gt par <et>. L'erreur s'est alors produite et j'ai obtenu une réponse correcte. Je ne sais pas comment cela a fonctionné, mais ça a fonctionné.
échantillon :
String body = "<ns:addNumbersResponse xmlns:ns=\"http://Java.duke.org\"><ns:return>"
+sum
+"</ns:return></ns:addNumbersResponse>";
Définissez votre document pour former comme ceci:
<?xml version="1.0" encoding="UTF-8" ?>
<root>
%children%
</root>
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();
}
Juste une pensée supplémentaire sur celui-ci pour l'avenir. L'obtention de ce bogue pourrait être le cas si l'on appuie simplement sur la touche Suppr ou sur une autre touche de manière aléatoire lorsqu'ils ont une fenêtre XML comme affichage actif et ne font pas attention. Cela m'est déjà arrivé auparavant avec le fichier struts.xml dans mon application Web. Coudes maladroits ...
J'ai eu le même problème avec le printemps
MarshallingMessageConverter
et par code de pré-traitement.
Peut-être que quelqu'un aura besoin de 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.
J'avais le même problème lors de l'analyse du fichier info.plist 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 ça aide quelqu'un.