哪些问题导致人们使用日语特定的编​​码而不是Unicode？

在工作中，我遇到了许多使用Shift-JIS和其他编码的日语文本文件。对于所有计算机用户，这会导致许多mojibake（字符不可读）问题。Unicode旨在通过为所有语言定义单个字符集来解决此类问题，并且建议在Internet上使用UTF-8序列化。那么，为什么每个人都不能从日语专用的编码转换为UTF-8？UTF-8存在哪些问题或弊端？

编辑：W3C列出了Unicode的一些已知的问题，这可能也是原因吗？

一言以蔽之：遗产。

由于Unicode是唯一的日语编码方式，因此在Unicode可用/流行之前就使用了Shift-JIS和其他编码。公司已经在仅支持Shift-JIS的基础架构上进行了投资。即使该基础结构现在支持Unicode，出于各种原因，它们仍然会受制于Shift-JIS，从它的工作原理到接触的问题，再到编码的原因，是什么？要迁移，所有现有的文档，是太昂贵。

出于相同的原因，有许多西方公司仍在使用ASCII或latin-1，但没有人注意到，因为它从未引起问题。

这些就是我记得没有将UTF-8或其他Unicode表示作为主要在日本开发的脚本语言Ruby的默认字符编码的原因：

• 原因1：汉族统一。中国，韩国和日本使用的字符集（不确定“字母”在这里是否正确）都是相关的，是从共同的历史演变而来的，不确定细节。Unicode联盟决定只浪费一个Unicode代码点来编码具有历史意义的同一字符的所有变体（中文，日文和韩文），即使它们在三种语言中的外观都不同。他们的理由是，外观应由用于显示文本的字体决定。

显然，这种推理被日本用户认为是荒谬的，就像对英语读者说的那样，由于拉丁字母是从希腊字母发展而来的，对于希腊字母只有一个代码点就足够了。 α”和拉丁语“ a”，并让外观由使用的字体决定。（与“β” =“ b”，“γ” =“ g”等相同）

（请注意，如果是这种情况，我将无法在stackexchange上包括希腊字符。）

• 原因2：字符转换效率低下。 将字符从Unicode转换为旧的日语编码并返回需要表，即，没有简单的从Unicode代码点值到旧代码点值的计算，反之亦然。此外，转换时还会丢失一些信息，因为一种编码中的并非所有代码点在另一种编码中都具有唯一的表示形式。

可能有更多的原因使我不记得了。

deceze的答案具有很强的真理性，但是还有一个原因仍要使用Shift-JIS和其他语言：UTF-8对于某些语言（主要是在CJK语言集中），效率极低。Shift-JIS是IIRC，是两字节宽的编码，而UTF-8在使用CJK等编码时通常为3字节，有时甚至为4字节。

计算字符串大小/内存使用情况的主要原因之一。

在UTF-8中，东亚语言的字符通常需要3个或更多字节。与使用UTF-16相比，它们平均需要多50％的内存 -后者的效率已低于本机编码。

正如deceze指出的那样，另一个主要原因是遗产。

就像其他人说的那样，旧版和存储大小，但是还有一件事：片假名字符。

在Shift-JIS中仅需一个字节即可表示片假名字符，因此包括片假名在内的日语文本每个字符占用的字节数少于2个字节（对于50/50混合字符为1.5），这使Shift-JIS的效率比UTF-16（2个字节）高/ char），效率要比UTF-8（3个字节/字符）高得多。

廉价的存储本应使这个问题变得小得多，但显然不是。