如何使Django slugify与Unicode字符串正常工作？

我该怎么做才能防止slugify过滤器剥离非ASCII字母数字字符？(我正在使用Django 1.0.2)

cnprog.com有问题URL中的中文字符,所以我查看了他们的代码.他们没有slugify在模板中使用,而是在Question模型中调用此方法来获取永久链接

def get_absolute_url(self):
    return '%s%s' % (reverse('question', args=[self.id]), self.title)

他们是否在诋毁网址？

1> Evgeny..：

---

有一个名为unidecode的python包,我已经在askbot Q&A论坛上采用了它,它适用于基于拉丁语的字母表,甚至对于希腊语看起来也很合理:

>>> import unidecode
>>> from unidecode import unidecode
>>> unidecode(u'???????????')
'diakritikos'

它对亚洲语言有些奇怪:

>>> unidecode(u'???')
'Ying Shi Ma '
>>> 

这有意义吗？

在askbot我们计算slug如下:

from unidecode import unidecode
from django.template import defaultfilters
slug = defaultfilters.slugify(unidecode(input_text))

---

这真是一个很棒的小lib.这个答案应该是公认的答案.

2> Open SEO..：

---

Mozilla网站团队一直致力于实施:https: //github.com/mozilla/unicode-slugify 示例代码,网址为 http://davedash.com/2011/03/24/how-we-slug-at-mozilla /

---

这个答案应该是*[接受|最佳|最高投票]答案*

3> Arthur Heber..：

---

此外,Django版本的slugify不使用re.UNICODE标志,因此它甚至不会尝试理解\w\s与非ascii字符有关的含义.

这个自定义版本适合我:

def u_slugify(txt):
        """A custom version of slugify that retains non-ascii characters. The purpose of this
        function in the application is to make URLs more readable in a browser, so there are 
        some added heuristics to retain as much of the title meaning as possible while 
        excluding characters that are troublesome to read in URLs. For example, question marks 
        will be seen in the browser URL as %3F and are thereful unreadable. Although non-ascii
        characters will also be hex-encoded in the raw URL, most browsers will display them
        as human-readable glyphs in the address bar -- those should be kept in the slug."""
        txt = txt.strip() # remove trailing whitespace
        txt = re.sub('\s*-\s*','-', txt, re.UNICODE) # remove spaces before and after dashes
        txt = re.sub('[\s/]', '_', txt, re.UNICODE) # replace remaining spaces with underscores
        txt = re.sub('(\d):(\d)', r'\1-\2', txt, re.UNICODE) # replace colons between numbers with dashes
        txt = re.sub('"', "'", txt, re.UNICODE) # replace double quotes with single quotes
        txt = re.sub(r'[?,:!@#~`+=$%^&\\*()\[\]{}<>]','',txt, re.UNICODE) # remove some characters altogether
        return txt

注意最后的正则表达式替换.这是一个更强大的表达式问题的解决方法r'\W',它似乎要么删除一些非ascii字符或错误地重新编码它们,如下面的python解释器会话所示:

Python 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> # Paste in a non-ascii string (simplified Chinese), taken from http://globallives.org/wiki/152/
>>> str = '??????????????????'
>>> str
'\xe6\x82\xa8\xe8\xaa\x8d\xe8\xad\x98\xe5\xb0\x8d\xe5\x85\xa8\xe7\x90\x83\xe7\xa4\xbe\xe5\x8d\x80\xe6\x84\x9f\xe8\x88\x88\xe8\xb6\xa3\xe7\x9a\x84\xe4\xb8\xad\xe5\x9c\x8b\xe6\x94\x9d\xe5\xbd\xb1\xe5\xb8\xab\xe5\x97\x8e'
>>> print str
??????????????????
>>> # Substitute all non-word characters with X
>>> re_str = re.sub('\W', 'X', str, re.UNICODE)
>>> re_str
'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\xa3\xe7\x9a\x84\xe4\xb8\xad\xe5\x9c\x8b\xe6\x94\x9d\xe5\xbd\xb1\xe5\xb8\xab\xe5\x97\x8e'
>>> print re_str
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX????????
>>> # Notice above that it retained the last 7 glyphs, ostensibly because they are word characters
>>> # And where did that question mark come from?
>>> 
>>> 
>>> # Now do the same with only the last three glyphs of the string
>>> str = '???'
>>> print str
???
>>> str
'\xe5\xbd\xb1\xe5\xb8\xab\xe5\x97\x8e'
>>> re.sub('\W','X',str,re.U)
'XXXXXXXXX'
>>> re.sub('\W','X',str)
'XXXXXXXXX'
>>> # Huh, now it seems to think those same characters are NOT word characters

我不确定上面的问题是什么,但我猜它源于" 在Unicode字符属性数据库中被归类为字母数字的任何东西 ",以及如何实现它.我听说python 3.x在更好的unicode处理方面具有高优先级,所以这可能已经修复了.或者,也许这是正确的python行为,我滥用unicode和/或中文.

目前,解决方法是避免使用字符类,并根据明确定义的字符集进行替换.

4> Antoine Pins..：

---

使用Django> = 1.9,django.utils.text.slugify有一个allow_unicode参数:

>>> slugify("?? World", allow_unicode=True)
"??-world"

如果您使用Django <= 1.8(自2018年4月起不应该使用),您可以从Django 1.9中获取代码.

5> Jarret Hardi..：

---

我担心django对slug的定义意味着ascii,尽管django文档没有明确说明这一点.这是slugify的默认过滤器的来源...您可以看到值正在转换为ascii,如果出现错误,请使用'ignore'选项:

import unicodedata
value = unicodedata.normalize('NFKD', value).encode('ascii', 'ignore')
value = unicode(re.sub('[^\w\s-]', '', value).strip().lower())
return mark_safe(re.sub('[-\s]+', '-', value))

基于此,我猜cnprog.com没有使用官方slugify功能.如果您想要不同的行为,您可能希望调整上面的django片段.

尽管如此,URL的RFC确实声明非us-ascii字符(或者更具体地说,除了字母数字和$-.+!*'()之外的任何字符都应该使用%hex表示法编码.如果您查看浏览器发送的实际原始GET请求(例如,使用Firebug),您将看到中文字符实际上在被发送之前被编码...浏览器只是使它在显示中看起来很漂亮.我怀疑这就是为什么slugify只坚持ascii,fwiw.

6> un33k..：

---

您可能需要查看:https: //github.com/un33k/django-uuslug

它将照顾你的两个"U".U表示唯一,U表示 Unicode.

它会为你无忧无虑地完成工作.