nerezus
def escapeHtml(s):
return s.replace('&', ‘&’).\
replace('"', ‘"’).\
replace('\'', ‘'’).\
replace('<', ‘&lt;’).\
replace('>', ‘&gt;’).\
replace('\0', '')
Достаточно безопасно? За основу взят http://php.net/htmlspecialchars и добавлено \0

Зависит от задачи. В общем случае фильтровать нетекстовые символы (все, а не только \0) надо на входе, т.е. при получении данных от пользователя, так как они могут многое сломать ещё до подстановки в шаблон. Хотя на выходе тоже не помешает.
Замена нетекстовых символов (см. http://www.w3.org/TR/REC-xml#NT-Char):
re.compile(ur'', re.U).sub(replacement, text)
где replacement - ‘', ’?' или u'\uFFFD' на ваше усмотрение.
Для спецсимволов HTML/XML есть cgi.escape(), xml.sax.saxutils.escape().

cgi.escape()

хм, примерно то же, что я и написал, но без \0. отя не знал про эту функцию.

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

Например? Чем это может навредить?

nerezus

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

Например? Чем это может навредить?

Везде, где ожидаются только текст. Например, если внутри используется XML-RPC для передачи данных между компонентами системы. Большинство генераторов XML (например, ElementTree) не проверяют данные на наличие недопустимых символов, хотя должны давать ошибку. Зато большинство парсеров (например, expat, используемый тем же ElementTree) ведёт себя корректно - дают ошибку. Заметьте, генераторы должны давать именно ошибку, то есть данные в любом случае должны быть оччищены, а исправление этого типового бага в генераторах упростит отладку, но не решит саму проблему.

> но не решит саму проблему.
Стоп, а так проблема же в генераторах. Им дают данные, а они только должны их обрабатывать.

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

nerezus
Стоп, а так проблема же в генераторах. Им дают данные, а они только должны их обрабатывать.

Да, есть проблема с генераторами. Они считают, что если в XML может быть только текст, то пользователь им будет скармливать только текст. Хотя неплохо бы поменьше доверять пользователю и проверять.

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

Это почему же портить? Если мы принимаем (требуем) от пользователя текст, а он шлёт нам не текст (точнее, текст + несколько недопустимых символов, попавших туда из-за кривого браузера или злого умысла), то у нас есть 3 пути: 1) довериться пользователю (по нему следуют большинство, из-за чего многие сайты так легко сломать), 2) послать его куда подальше (хороший вариант, но виноват может быть не только пользователь, но и кривой браузер) или 3) убрать/заменить недопустимые символы. Мне больше нравится 3-й путь, потому ему и следую.
А вот когда на данные не накладывается такого ограничения (например, загрузка файла через форму), то портить их таким образом, конечно, нельзя.

ods А не легче ли преобразовывать текст тогда только на передаче в XML для передачи в XML? А для вывода только перед выводом?

nerezus
Daevaorn мм, не нашел… Вернее я нашел только | escape в шаблонах. Но я просто не хочу пользоваться Django'вскими шаблонами

Ну шаблонный фильтр это как никак функция. А вообще в django.utils.html есть функция escape, на основе которой фильтр и сделан.

Daevaorn
хы, там так же сделано:
return html.replace('&', ‘&amp;’).replace('<', ‘&lt;’).replace('>', ‘&gt;’).replace('“', ‘&quot;’).replace(”'", ‘&#39;’)