Я бился головой об этой ужасной ошибке последние 48 часов, так что я подумал, что наконец-то выброшу полотенце и попробую спросить здесь, прежде чем выбросить свой ноутбук в окно.
Я пытаюсь разобрать ответ XML на вызов, сделанный мной в AWS SimpleDB. Ответ возвращается по проводу нормально; например, это может выглядеть так:
<?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"?>
<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>
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: Content is not allowed in prolog.
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(Unknown Source)
at com.sun.xml.internal.stream.XMLEventReaderImpl.nextEvent(Unknown Source)
at com.amazonaws.transform.StaxUnmarshallerContext.nextEvent(StaxUnmarshallerContext.java:153)
... (rest of lines omitted)
Я дважды, трижды, четыре раза проверял этот XML на наличие «невидимых символов» или символов, не закодированных в UTF8, и т. Д. Я смотрел его побайтово в массиве для отметок порядка байтов или чего-то в этом роде. Ничего; он проходит все проверочные тесты, которые я мог ему предложить. Что еще более странно, это случается, если я использую синтаксический анализатор на основе Saxon, но ТОЛЬКО на GAE он всегда отлично работает в моей локальной среде.
Это очень затрудняет отслеживание кода проблем, когда я могу запустить отладчик только в среде, которая работает идеально (я не нашел хорошего способа удаленной отладки в GAE). Тем не менее, используя имеющиеся у меня примитивные средства, я испробовал миллион подходов, в том числе:
- XML с прологом и без него
- С символами новой строки и без них
- С атрибутом encoding = и без него в прологе
- Оба стиля новой строки
- С и без информации о фрагментах, присутствующей в потоке HTTP
И я пробовал большинство из них в нескольких комбинациях, где имело смысл их взаимодействие - ничего! Я на грани своего остроумия. Кто-нибудь видел подобную проблему раньше, которая, надеюсь, может пролить на нее свет?
Спасибо!
Ответы:
Кодировка в вашем XML и XSD (или DTD) различается.
Заголовок файла XML:
<?xml version='1.0' encoding='utf-8'?>
Заголовок файла XSD:
<?xml version='1.0' encoding='utf-16'?>
Другой возможный сценарий, который вызывает это, - когда что-либо предшествует объявлению типа документа XML. т.е. у вас может быть что-то вроде этого в буфере:
или даже пробел или специальный символ.
Есть некоторые специальные символы, называемые маркерами порядка байтов, которые могут находиться в буфере. Перед передачей буфера в парсер сделайте следующее ...
источник
Это сообщение об ошибке всегда вызвано недопустимым содержимым XML в начальном элементе. Например, очень маленькая точка «.» в начале элемента XML.
Любые символы перед «
<?xml….
» вызовут сообщение об ошибке « org.xml.sax.SAXParseException: содержимое не разрешено в прологе ».Маленькая точка » . " перед
“<?xml….
Чтобы исправить это, просто удалите все эти странные символы перед расширением
“<?xml“
.Ссылка: http://www.mkyong.com/java/sax-error-content-is-not-allowed-in-prolog/
источник
Я столкнулся с той же проблемой. В моем случае файлы XML были созданы из программы на C # и загружены в AS400 для дальнейшей обработки. После некоторого анализа было установлено, что я использовал кодировку UTF8 при создании файлов XML, тогда как javac (в AS400) использует «UTF8 без спецификации». Итак, пришлось написать дополнительный код, подобный упомянутому ниже:
источник
У меня возникла проблема при проверке файла xml в блокноте ++ и сохранении файла, хотя у меня был верхний тег xml utf-8 как
<?xml version="1.0" encoding="utf-8"?>
Исправлено сохранением файла в notpad ++ с помощью Encoding (Tab)> Encode in UTF-8: selected (было Encode in UTF-8-BOM)
источник
Удаление объявления xml решило это
источник
В моем xml-файле заголовок выглядел так:
В тестовом файле я читал байты файла и декодировал данные как UTF-8 (не понимая, что заголовок в этом файле был utf-16), чтобы создать строку.
Когда я попытался десериализовать эту строку в объект, я увидел ту же ошибку:
Когда я обновил вторую строку до
Мне удалось десериализовать объект очень хорошо. Итак, как заметил выше Ромен, кодировки должны совпадать.
источник
Я столкнулся с той же проблемой под названием «Контент не разрешен в прологе» в моем XML-файле.
Решение
Изначально моя корневая папка была «# Имя файла ».
Когда я удалил первый символ «#», ошибка исчезла.
Нет необходимости удалять #filename ... Попробуйте так ..
Вместо передачи объекта File или URL методу unmarshaller используйте FileInputStream.
источник
Неожиданная причина:
#
символ в пути к файлуИз-за некоторой внутренней ошибки ошибка Content is not allowed in prolog также появляется, если само содержимое файла на 100% правильное, но вы указываете имя файла, например
C:\Data\#22\file.xml
.Это может относиться и к другим специальным символам.
Как проверить: если вы переместите свой файл по пути без специальных символов и ошибка исчезнет, значит, это была эта проблема.
источник
Сегодня я поймал такое же сообщение об ошибке. Решением было изменить документ с UTF-8 с BOM на UTF-8 без BOM.
источник
У меня был символ табуляции вместо пробелов. Замена вкладки '\ t' устранила проблему.
Вырежьте и вставьте весь документ в редактор, например Notepad ++, и отобразите все символы.
источник
В моем случае проблемы решением было заменить немецкие умляуты (äöü) их HTML-эквивалентами ...
источник
ниже приведена причина выше исключения «org.xml.sax.SAXParseException: содержимое не допускается в прологе».
Заголовок файла XML:
<?xml version='1.0' encoding='utf-8'?>
Заголовок файла XSD:
<?xml version='1.0' encoding='utf-8'?>
hello<?xml version='1.0' encoding='utf-16'?>
источник
В духе «просто удалите все эти странные символы перед <? Xml» вот мой код Java, который хорошо работает с вводом через BufferedReader:
FWIW, байты, которые я видел (в десятичном формате): 239, 187, 191.
источник