谁不喜欢 emoji 呢？? 为交流增添一些额外的风格可以将基本消息变成稍微花哨的东西。 ✨
然而，尽管它们在某些平台上看起来不错，但并非每个人都能以相同的方式看到 emoji。 即使 Unicode 声明了一个标准，以确保字符被严格定义并在任何使用 Unicode 的系统中兼容，他们不负责 emoji 的设计。
如果你有一台 Windows 桌面电脑和一部 iPhone，你会注意到 emoji 在这两款设备上看起来不一样。 如果你查看像 Emojipedia 这样的网站，你就可以看到这些差异。 像 Sparkles 这样的字符的差异可能不会让人感到困惑，但对于像 笑眼心形脸 这样的字符，在不同平台之间有一些有趣的解释。
考虑到 Android 平台 emoji 从黑白到侧视图再到正面视图的演变，这些 emoji 的差异可能会改变对符号的解释。 例如 脸红 emoji。 在 Apple 上，它总是看起来像是一种震惊（“糟糕”）和尴尬的表情。 然而，在 Android 4.4 上，它可能暗示一张“害羞”的脸红。 如果你从旧款 Android 手机向拥有 Apple 设备的人发送该 emoji，他们将看不到你看到的“害羞”，因此可能会对 emoji 做出非常不同的解释。 由于无法控制用于字符的视觉效果，因此产生误解的可能性非常大。
明尼苏达大学 的一项研究表明，这个问题不仅是跨平台的，也是平台间的。 自这项研究以来，其中一个特别提到的字符，咧嘴笑脸，笑眼，已经在 许多平台上得到了改进，因此它与 鬼脸 明显不同。
最重要的是，并非所有用户都能看到细节中的细微差别。 根据你使用的是移动设备还是 Web 以及屏幕的大小，emoji 可能会非常小且难以看清。 允许某种机制让用户可以看到 emoji 的名称对于可用性和可访问性来说非常棒。
GitHub 的 Web 界面通过在用户将鼠标悬停在 emoji 上时显示 emoji 的短代码来做到这一点。 然而，通常 GitHub 依赖于 emoji 的原生系统实现。 Twitter 的 Web 界面更进一步，它用嵌入式图像替换了 emoji 字符，并在图像标签的 title 属性上附带完整的描述性文本。 此外，Twitter 使用 alt 属性来存储原始字符，因此，如果你选择文本块并将其复制到剪贴板，则会复制 Unicode 字符。 这是 HTML <img> 标签的一个功能，考虑到内联图像，这是一个很棒的功能。
不幸的是，Twitter 提供的整个完整形式的 Web 可访问性不是开源的。 Twitter 确实提供了 twemoji，这是一个客户端 emoji 替换脚本，它可以处理 emoji 到图像的替换，但不处理描述性文本。 为了让客户端脚本做到这一点，它需要本地了解所有 emoji 的描述，这是 几兆字节的数据（警告：大型文件链接）。
解决方案是什么？
Emojificiate 是完全可从 Web 访问的 emoji 的概念验证服务器端实现，用 Python 编写。 它的信息来源是 unicodedata 模块，该模块直接从 Unicode 标准编译而来。 使用的版本取决于所使用的 Python 版本。 Python 版本越新，Unicode 版本越新，可以识别的 emoji 就越多。
在没有任何脚本来更有效地传达 emoji 字符本身的情况下，emoji 用户有责任确保他们的含义不会被其通信的任何读者错误地假设。 通过限制误解的可能性，emoji 可以为文本交流增添一丝光彩，而不会带走任何意义。 ✨
Katie McLaughlin 将在德克萨斯州奥斯汀举行的 OSCON 2017 大会上发表题为 Unicode 采用的力量 ⚡️ 和责任 ? ✨ 的演讲。 如果您有兴趣参加会议，请在 注册时 使用此折扣代码，为我们的读者：PCOS。
2 条评论