Какие существуют стратегии для выхода из персонажа? - PullRequest
3 голосов
/ 15 декабря 2009

Мы выполняем обработку естественного языка для ряда документов на английском языке (в основном научных) и сталкиваемся с проблемами при переносе не-ANSI символов через различные компоненты. Документы могут быть "ASCII", UNICODE, PDF или HTML. На данном этапе мы не можем предсказать, какие инструменты будут в нашей цепочке или позволят ли они кодирование символов, отличное от ANSI. Даже символы ISO-Latin, выраженные в UNICODE, будут вызывать проблемы (например, некорректное отображение в браузерах). Мы можем встретить ряд символов, включая математические и греческие. Мы хотели бы «сгладить» их в текстовую строку, которая переживет многошаговую обработку (включая инструменты XML и regex), а затем, возможно, воссоздадим ее на последнем этапе (хотя это семантика, а не типография, которая нас интересует, так что это незначительное беспокойство).

Я ценю, что нет абсолютного ответа - в некоторых случаях любое побег может столкнуться - но я ищу что-то подобное в строках XML <![CDATA[ ...]]>, которое выдержит большинство нерекурсивных операций XML. Такие символы, как [, являются плохими, поскольку они часто встречаются в регулярных выражениях. Поэтому мне интересно, есть ли общепринятый подход, а не изобретать наш собственный.

Типичным примером является символ "градусы":

HTML Entity (decimal)   &#176;
HTML Entity (hex)   &#xb0;
HTML Entity (named)     &deg;
How to type in Microsoft Windows    Alt +00B0
Alt 0176
Alt 248
UTF-8 (hex)     0xC2 0xB0 (c2b0)
UTF-8 (binary)  11000010:10110000
UTF-16 (hex)    0x00B0 (00b0)
UTF-16 (decimal)    176
UTF-32 (hex)    0x000000B0 (00b0)
UTF-32 (decimal)    176
C/C++/Java source code  "\u00B0"
Python source code  u"\u00B0"

Мы также можем столкнуться с TeX

$10\,^{\circ}{\rm C}$

или

\degree

так что обратная косая черта, кудряшки и доллары - плохая идея.

Мы могли бы, например, использовать разметку, например:

__deg__
__#176__

и это, вероятно, сработает, но я буду признателен за советы тех, у кого есть подобные проблемы.

обновление Я согласен с тем, что @ MichaelB настаивал на том, чтобы мы использовали UTF-8 повсюду. Я обеспокоен тем, что некоторые из наших инструментов могут не соответствовать, и если это так, я вернусь к этому. Обратите внимание, что мой первоначальный вопрос не сформулирован правильно - прочитайте его ответ и ссылку в нем.

Ответы [ 2 ]

4 голосов
/ 15 декабря 2009
  • Попросите кого-нибудь сделать это, кто действительно понимает кодировки символов. Похоже, что нет, потому что вы не используете терминологию правильно. В качестве альтернативы прочитайте это .
  • Не придумывайте свою собственную схему побега - это вызовет у вас больше проблем, чем решит. Вместо этого нормализует различные исходные кодировки в UTF-8 (которая на самом деле является лишь одной из таких схем перехода, кроме эффективной и стандартизированной) и правильно обрабатывает кодировки символов. Возможно, используйте UTF-7, если вы действительно боитесь старших бит.
  • В наше время неправильная обработка кодировки символов недопустима. Если инструмент этого не делает, откажитесь от него - он, скорее всего, код очень плохого качества и во многих других отношениях и не стоит использовать его.
1 голос
/ 15 декабря 2009

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

В конце концов, вы можете передавать уникальные маркеры и их номера по цепочке через отдельный канал и проверять их наличие и номер в конце.

Пример, что-то вроде

the value of the temperature was 18 cd48d8c50d7f40aeb6a164181b17feee EZSGKZY= cd48d8c50d7f40aeb6a164181b17feee

ваш маркер - uuid, а сущность кодируется в base32. Затем вы проходите по маркеру cd48d8c50d7f40aeb6a164181b17feee. Он не может быть поврежден (если он поврежден, ваши фильтры, вероятно, все равно повредят все, что состоит из букв и цифр, но, по крайней мере, вы можете исключить их, потому что они имеют фиксированную длину), и вы всегда можете восстановить содержимое, заглянув внутрь двух маркеров.

Конечно, если в ваших документах есть uuids, это может представлять проблему, но, поскольку вы не передаете их в качестве авторизованных маркеров по боковому каналу, они не будут распознаваться как таковые (и в любом случае, что В любом случае, inbetween не будет проверяться как строка base32).

Если вам нужно их найти, вы можете оставить подразделение uuid, а затем использовать правильное регулярное выражение, чтобы определить эти случаи. Пример:

>>> re.search("(\w{8}-\w{4}-\w{4}-\w{4}-\w{12})(.*?)(\\1)", s)
<_sre.SRE_Match object at 0x1003d31f8>
>>> _.groups()
('6d378205-1265-44e4-80b8-a47d1ceaad51', ' EZSGKZY= ', '6d378205-1265-44e4-80b8-a47d1ceaad51')
>>> 

Если вам действительно нужен определенный «токен» для тестирования, вы можете использовать uuid1 с очень определенной спецификацией узла:

>>> uuid.uuid1(node=0x1234567890)  
UUID('bdcce554-e95d-11de-bd0f-001234567890')
>>> uuid.uuid1(node=0x1234567890)  
UUID('c4c57a91-e95d-11de-90ca-001234567890')
>>> 

Вы можете использовать в качестве узла все, что предпочитаете, uuid будет уникальным, но вы все равно можете проверить наличие (хотя вы можете получить ложные срабатывания).

...