slugs 和 unicode 的规则
在研究了一些人们如何使用不同的方式来称呼标题之后，我注意到它经常缺少如何处理非英语标题。
url 编码是非常严格的。 请参阅http://www.blooberry.com/indexdot/html/topics/urlencoding。 htm
之类的标题，
因此，例如人们如何处理诸如“Una lágrima cayó en la arena”
人们可以为印欧语言提出一个合理的表格，即。 可以通过 ISO-8859-1 编码的东西。 例如，转换表将翻译 'á' => 'a'，所以 slug 将是
“una-lagrima-cayo-en-la-arena”
但是，我使用的是 unicode （特别是使用 UTF-8 编码），所以不能保证我的代码点是什么类型将会得到（我必须为无法进行 ISO-8859-1 编码的东西做好准备。
我很困惑。如何处理这个问题？我应该为 ISO_8859-1 范围内的字符提供一个转换表（< ;255) 并删除其他所有内容？
编辑：先验地提供更多背景信息，我真的不希望用非印欧语言来slugify数据，但我想要一个计划如果我遇到这样的数据。 扩展 ASCII 的转换表会很好。 有什么指点吗？
另外，既然人们问了，我正在使用 python，在 Google App Engine 上运行
After researching a bit how the different way people slugify titles, I've noticed that it's often missing how to deal with non english titles.
url encoding is very restrictive. See http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
So, for example how do folks deal with for title slugs for things like
"Una lágrima cayó en la arena"
One can come up with a reasonable table for indo european languages, ie. things that can be encoded via ISO-8859-1. For example, a conversion table would translate 'á' => 'a', so the slug would be
"una-lagrima-cayo-en-la-arena"
However, I'm using unicode (in particular using UTF-8 encoding), so no guaranties about what sort code points I'm going to get (I have to prepare for things that can't be ISO-8859-1 encoded.
I a nushell. How do deal with this? Should I come up with a conversion table for chars in the ISO_8859-1 range (<255) and drop everything else?
EDIT: To give a bit more context, a priori, I don't really expect to slugify data in non indo european languages, but I'd like to have a plan if I encounter such data.
A conversion table for the extended ASCII would be nice. Any pointers?
Also, since people are asking, I'm using python, running on Google App Engine
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
几乎完整的音译表（拉丁文、希腊文和西里尔文字符集）可以在 slughifi 库。 它面向 Django，但可以轻松修改以满足一般需求（我将它与 AppEngine 上基于 Werkzeug 的应用程序一起使用）。
Nearly-complete transliteration table (for latin, greek and cyrillic character sets) can be found in slughifi library. It is geared towards Django, but can be easily modified to fit general needs (I use it with Werkzeug-based app on AppEngine).
我只是使用 utf-8 作为 URL 路径。 只要域名是非 IDN FF3，IE 就可以正常工作。 Google 可以正确读取并显示它们。 IRI RFC 允许使用 Unicode。 只要确保正确解析传入的 URL 即可。
I simply use utf-8 for URL paths. As long as the domain is non-IDN FF3, IE works fine with this. Google reads and displays them correctly. The IRI RFC allows Unicode. Just make sure you parse the incoming urls correctly.
一般来说，这取决于您期望获得的语言。 如果您的主要用户群是日语，则删除除 ISO-8859-1 字符之外的所有内容不太可能得到很好的解决。
也就是说，如果您的字符集转换库支持的话，一种选择可能是使用音译模式。 例如，使用 GNU iconv，我们可以这样做：
如您所见，重音字符会自动转换为 ASCII 范围内的字符。 如何将其转换为代码当然取决于您使用的语言，但如果您的语言基于 GNU iconv 进行字符集转换（如果它在 Linux 上，则可能是），则可以直接应用此技巧只需指定“ascii//TRANSLIT”作为转换字符集。
然而，需要注意的一件事是，它仅对“看起来像”ASCII 中的字符有效。 例如：
正如您所看到的，这对于日语来说没有太大帮助，并且需要随后进一步处理以删除不适合URL的字符。
In general this is going to depend on the language you expect to get. If your primary userbase is Japanese, dropping everything but ISO-8859-1 characters is unlikely to go over well.
That said, one option might be to use transliteration mode, if your character set conversion library supports it. For example, with GNU iconv, one can do:
As you can see, the accented characters were automatically converted to something in the ASCII range. How to translate this to code will of course depend on the language you're using, but if your language is based on GNU iconv for charset conversion (and if it's on linux, it probably is), this trick can probably be applied directly by simply specifying "ascii//TRANSLIT" as the convert-to character set.
One thing to note with this, however, is it's only effective with characters that "look like" something in ASCII. For example:
As you can see, it's not much help for Japanese, and needs further processing afterward to remove characters not suitable for URLs.
如果所有其他方法都失败，您可以使用转换表，但可能有性能更好的解决方案可用。 您使用什么服务器端语言？
If all else fails, you could use a conversion table, but there might be a better performing solution available. What server side language are you using?