【问题标题】:Why always store shortnames for emojis?为什么总是存储表情符号的短名称?
【发布时间】:2016-06-24 09:20:45
【问题描述】:

EmojiOne's Github page,他们说:

在数据库中存储用户输入的文本时,[...] 您应始终确保存储的文本仅包含 :shortnames: 而不是 Unicode 表情符号字符 [...]。

为什么它总是是个坏主意?如果我的服务器语言、我的数据库和我的 Web 应用支持的浏览器版本都可以毫无困难地处理它们,那么问题出在哪里?

【问题讨论】:

  • 听起来非常基于我的意见。它减少了关于编码兼容性的麻烦,但话又说回来,如果你处理编码不正确,你一开始就会遇到更大的问题。
  • 你问过项目的作者了吗?这听起来像是非常糟糕的建议。表情符号字符(相对于其他 Unicode 字符)有特殊或不寻常之处。

标签: database web-applications unicode emoji


【解决方案1】:

在阅读 emoji 并查看 emojione 几天后,我的结论是——我不会在您的存储机制/db 中存储短代码(emojione 称为短名称)。正如您问题中的评论所建议的那样,只需将字符(表情符号:?)本身存储在您的数据库中即可。

对于那些刚刚开始了解表情符号的人来说,它们只是 unicode 标准中的另一个字符。字母、数字、感叹号、日文字符等都是 unicode 标准的字符部分。表情符号没有什么特别之处,您可以简单地将它们视为任何其他 unicode 字符。所有现代浏览器都会正确呈现它们。

我不存储短代码的主要原因是简单。通过存储实际的 unicode 字符?,您在向用户显示字符时无需进行任何类型的转换。如果您要存储短代码(在本例中为 :grinning:),则必须进行某种转换才能正确地向用户显示笑脸。

Emojione 的库能够将 unicode 本身或简码转换为其图像。鉴于此,只需存储 unicode 并使用 emojione 的库在显示给用户之前对其进行转换。如果您以后想停止使用 emojione 并使用标准的浏览器实现 emoji,您将没有额外的工作要做。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-09
    • 1970-01-01
    • 2021-09-14
    • 1970-01-01
    相关资源
    最近更新 更多