Сохранение исходного типа новой строки (\ r vs \ r \ n) в XML - PullRequest
Новая
       0

Сохранение исходного типа новой строки (\ r vs \ r \ n) в XML

3 голосов
/ 25 мая 2011

У меня есть приложение, в котором я хотел бы использовать файл XML для хранения: (1) исходного текста документа и (2) нескольких объектов, которые «указывают на» исходный текст с помощью смещения символов. E.g.:

<Document>
  <OriginalText>This is a test</OriginalText>
  <Word start_offset="0" end_offset="4" id="w1"/>
  <Word start_offset="6" end_offset="7" id="w2"/>
  <Word start_offset="8" end_offset="9" id="w3"/>
  <Word start_offset="10" end_offset="14" id="w4"/>
</Document>

Однако меня беспокоит потенциальная проблема - я не контролирую содержимое входного документа, поэтому он может содержать либо "\ n", либо "\ r \ n" переводы строк. Однако спецификация XML [1] гласит:

Процессор XML ДОЛЖЕН вести себя так, как будто он нормализовал все разрывы строк во внешнем проанализированные объекты (включая объект документа) на входе, до разбор, переводя оба двухсимвольная последовательность #xD #xA и любой #xD, за которым не следует #xA до одного символа #xA.

Т.е., символы новой строки нормализуются до того, как приложение увидит файл XML. К сожалению, мне кажется, что это может сбить смещения персонажей. Например, символ, который был со смещением 173 до нормализации смещений, может иметь смещение 168 после нормализации смещений. Мои вопросы:

  1. Правильно ли я интерпретирую спецификацию XML?

  2. Я предполагаю, что простое кодирование новых строк (то есть замена \ r на & # xD;) не решит проблему, потому что закодированные символы будут заменены до того, как процессор XML нормализует разрывы строк. Это правильно?

  3. Кто-нибудь может порекомендовать хорошее решение? Одно из решений, которое я рассмотрел, состоит в замене символов \ r, которые в противном случае удалялись бы при нормализации, на другие символы (либо пробел, либо какой-нибудь «специальный» символ); но я бы предпочел не изменять исходный текст документа, если это возможно. Другим возможным решением было бы закодировать исходный документ (например, с использованием base64 или uuencode), но я бы предпочел этого не делать, поскольку это усложнит чтение и использование файлов XML.

(Использование смещений символов для указания на документ не является дизайнерским решением, которое можно изменить, поскольку мне нужно интегрировать его с другими инструментами, которые используют смещения символов для наведения на текст документа.)

[1] http://www.w3.org/TR/REC-xml/#sec-line-ends

Ответы [ 2 ]

4 голосов
/ 25 мая 2011

Я понял часть спецификации, которую вы процитировали, что все напечатанные (буквальные) CR символы заменяются и перед синтаксическим анализом заменяются. Таким образом, любой CR, представленный в виде ссылки на символ &#xD;, не будет заменен на LF, поскольку замена должна быть сделана перед синтаксическим анализом (или она должна работать так, как если бы она выполнялась до синтаксического анализа). и ссылки на символы преобразуются в символьные данные во время синтаксического анализа XML . Обратите внимание, что CR s в секциях CDATA заменяются, но опять же, ссылки на символы в секциях CDATA не будут анализироваться с фактическими символами, на которые они ссылаются.

Таким образом, вы сможете сохранить ваши переводы строк такими, какими они были, если вы сериализовали их как ссылки на символы. Однако, будьте осторожны: я не буду рассчитывать на то, что все инструменты XML подчиняются этому соглашению. Также вы можете потерять CR s, если проанализированный XML отправляется другому инструменту, который снова интерпретирует содержимое.

Кроме того, индексирование данных по позициям персонажей звучит для меня довольно хрупко. Пожалуйста, подумайте, можете ли вы найти другой способ токенизации или сегментации ваших данных. Если вам нужно придерживаться индексации на основе позиции символов, я бы предложил как-то нормализовать текстовые данные. В конце концов, перевод строки не единственная возможная точка отказа. Другие включают, например, акцентированные символы и лигатуры.

0 голосов
/ 25 мая 2011

Если нет никаких гарантий относительно того, будут ли сохранены разрывы строк, то мой инстинкт был бы преобразовать их все в <br />.

...