Привет всем.

Написав систему репликации БД с использованием XML для транспортировки данных, обнаружили неприятную вещь:

наши доблестные пользователи, используя Word для подготовки данных и copy&paste, иногда в текстовые поля добавляют "не печатные" символы. Например, с кодом 6

Для записи/чтения XML-данных используются SAX-компоненты. При записи символы с кодом 6 попадают в XML без трансформации. При чтении возникает ошибка.

Я попробовал кодировать такие символы с помощью "&#SYMBOL_CODE;", но эффект нулевой.

Dim xml_doc As New MSXML2.DOMDocument40
 
If (Not xml_doc.loadXML("<a></a>")) Then
 err.raise -1,,xml_doc.parseError.reason 'Invalid unicode character
End If

Вопрос, что делать и как дальше жить?

Пока видится один основной путь — после формирования XML, уничтожать (кодировать же их не получается) в нем все "невостанавливаемые" символы.
Не дайте погибнуть — через три недели начнется промышленная эксплуатация

Так невалидный символ, допускаются только

Char    ::=    #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД><a></a>

Дело в том, что стандарт XML указывает, что базовым набором символов является Unicode, причем из символов с кодами меньше 32 допускаются лишь 9 (табуляция), 10 (перевод строки) и 13 (возврат каретки). Символа с кодом 6 с точки зрения языка XML просто не существует, а значит приведенный фрагмент в качестве разметки XML бессмыслен. Нужно добиться, чтобы бессмысленные наборы символов вроде "" в XML-разметку просто не попадали (очевидно, при записи надлежащий контроль отсутствует, а при прочтении SAX-разборщик такой контроль выполняет).

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Для записи/чтения XML-данных используются SAX-компоненты. При записи символы с кодом 6 попадают в XML без трансформации. При чтении возникает ошибка.

Невалидный символ.

КД>Пока видится один основной путь — после формирования XML, уничтожать (кодировать же их не получается) в нем все "невостанавливаемые" символы.
КД>Не дайте погибнуть — через три недели начнется промышленная эксплуатация

Так и делай, просто пропарсить и убить все невалидные символы. Где-то в спецификации все разрешённые символы есть.
Есть ещё вариант перекодировать всё в base64 перед записью в XML и пихать все чувствительные данные в CDATA секции.

С Уважением, Andir!

Здравствуйте, achp, Вы писали:

A>Здравствуйте, Коваленко Дмитрий, Вы писали:

A>

КД>><a></a>
A>

A>Дело в том, что стандарт XML указывает, что базовым набором символов является Unicode, причем из символов с кодами меньше 32 допускаются лишь 9 (табуляция), 10 (перевод строки) и 13 (возврат каретки). Символа с кодом 6 с точки зрения языка XML просто не существует, а значит приведенный фрагмент в качестве разметки XML бессмыслен. Нужно добиться, чтобы бессмысленные наборы символов вроде "" в XML-разметку просто не попадали (очевидно, при записи надлежащий контроль отсутствует, а при прочтении SAX-разборщик такой контроль выполняет).

Вот уроды, блин. Как это не существует, если у нас документ с такими символом попался (1 на ~4млн)

Я тут посмотрел на наши компоненты формирования/загрузки XML — запись и чтение (слава мне) локализованы в двух методах. То есть можно все таки попробовать применить кодирование.

Все что не удовлетворяет

Char    ::=    #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

Преобразовывать, например, в '$#6;' (символ $ — тоже нужно будет кодировать)

Большое всем спасибо !

Здравствуйте, Andir, Вы писали:

A>Так и делай, просто пропарсить и убить все невалидные символы. Где-то в спецификации все разрешённые символы есть.

Тут, правда, остается одна проблема — вдруг следующая версия SAX-писателя тоже начнет контролировать допустимость символов ...

A>Есть ещё вариант перекодировать всё в base64 перед записью в XML и пихать все чувствительные данные в CDATA секции.
Просветите темного, в двух словах, — что такое base64 . Или прямую ссылку на описание дайте...

Если в нем большинство (например кирилица) символов будет преобразована в многосимвольные последовательности, то не подходит из-за объема. Хотя конечно все равно пакеты обновлений будут сжимать...

Здравствуйте, Коваленко Дмитрий, Вы писали:

A>>Есть ещё вариант перекодировать всё в base64 перед записью в XML и пихать все чувствительные данные в CDATA секции.
КД>Просветите темного, в двух словах, — что такое base64 . Или прямую ссылку на описание дайте...

rfc1521
citforum

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

Сжимается он неплохо. Всё таки почтовые сообщения им пользуются, да и многие криптосистемы тоже

С Уважением, Andir!

самое интересное что подмена не XML цифирек на свои ситуацию не исправит ;>
у меня например MSXML4 SAX парсер валиться не на 0x0001 а на спец уникод эскейп символах, типа 0x0098 [START OF STRING].
на загрузке, сохраняет без проблем.
т.е. задача стоит о валидации/нормализации Unicode.