Попытка обнаружить недопустимые символы XML в процедуре PL / SQL - PullRequest
Новая
       16

Попытка обнаружить недопустимые символы XML в процедуре PL / SQL

5 голосов
/ 31 марта 2011

Вот загадка. Я хочу написать процедуру, которая проверяет таблицы на наличие любых символов, которые нарушают код XML. Их можно найти в Рекомендации W3C, но это сейчас не важно. Что важно, так это:

1) Символ 'ç' имеет код ASCII 135. Это факт. Тем не менее, когда я бегу 

begin
  ascii('ç');
end;

Я получаю 50087.

2) Когда я бегу 

begin
  dbms_output.put_line(chr(135));
end;

Я получаю pure nothing.

Ну, очевидно, ascii () и chr () обрабатывают только значения в 0..127. Поэтому мой вопрос заключается в том, как найти эквиваленты Юникода ИЛИ написать свои собственные расширения, которые работают с такими значениями, как 'ç' и 135.

Помощь будет высоко ценится.

P.S. Я использую Oracle SQL Developer.

Ответы [ 3 ]

1 голос
/ 11 мая 2011

Не совсем понятно, какую проблему вы пытаетесь решить. Преобразовать пользовательский ввод в правильную кодировку или проверить, что у вас есть действительный XML? Если последнее, я думаю, преобразование во встроенный XMLType подтвердит синтаксически правильность ввода. Вы даже можете проверить, что он соответствует заданной схеме XML.

1 голос
/ 24 мая 2011

Если вы просто хотите избавиться от странных символов, вы можете использовать функцию REGEXP_REPLACE.Например, 

REGEXP_REPLACE(your_value, '[:cntrl:]', '')

удалит все управляющие (непечатные) символы.

REGEXP_REPLACE доступно в Oracle 10g Rel.2 года.Документация на http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/functions130.htm

1 голос
/ 01 апреля 2011

Функции plsql для обработки произвольных наборов символов (ну, насколько rdbms знает о них) находятся в пакетах utl_i18n и utl_raw. для вашей конкретной задачи я бы предложил следующий тест: 

    select <pk_column_of_table_to_check>
         , instr (
              utl_i18n.string_to_raw ( 
                   <column_to_test>
                 , 'UTF8'
              )
            , hextoraw ( <hex_rep_in_utf8>  )
           )
      from <table_to_check>
         ;

Если вы хотите проверить символы Юникода, для которых представление utf8 недоступно, используйте термин 

      utl_raw.convert ( hextoraw ( <hex_rep_in_utf16>, 'UTF16', 'UTF8' ) )

как второй аргумент для instr. не полагайтесь на абсолютные позиции, возвращаемые instr, а только на дихотомию 0 / не-0, поскольку вы сравниваете не по символам, а по уровню байтов.

utf8 и utf16 - это две разные кодировки на уровне байтов для наборов символов Unicode в смысле именованных символов; подробности можно найти на википедии и unicode.org

обратите внимание, что представление utf8 допускает тестирование на уровне байтов на уровне конструкции. также обратите внимание, что кодировка utf16 должна быть легко доступна, так как это знакомое представление U + <4 шестнадцатеричных числа> для символов Юникода.

представление инкриминированных символов на уровне байтов должно быть доступно из стандарта (xml). в противном случае вы должны иметь представление о том, как называется символ, и искать его в базе данных кодовых точек на unicodde.org или где-то еще. Существуют также онлайн-инструменты для конвертации, если вы знаете только имя набора символов, но у вас есть образец текста в файле в вашей системе, я могу посмотреть Uris, если вам нужно.

Надеюсь, это поможет.

пс: после более точного прочтения вашего первого комментария я думаю, что вы можете оказаться на невыполнимой задаче: чтобы правильно интерпретировать байтовые последовательности из однобайтовых кодировок кодировки, необходимо сохранить информацию о кодировке в использовании. Разве эта информация не будет потеряна, когда пользователь копирует текст из текстового процессора (установленного в определенный набор символов [кодировка]) в базу данных (где он будет храниться в наборе символов базы данных), когда копируется последовательность байтов? вам может повезти, если оба конца будут настроены на юникод или кодировка db charset будет utf8 (поэтому копирование некоторых символов будет неудачным), но как только данные будут в базе данных, у вас будет трудное время для восстановления оригинала (возможно, с поддержкой словаря)

...