Coo*_*ola 15 encoding character-encoding
这是一个noob问题,但我想知道为什么有不同的编码类型,它们的区别是什么(即ASCII,utf-8和16,base64等)
ZZ-*_*-bb 16
原因很多我相信,但主要的一点是:"你需要显示多少个字符(编码)？" 例如,如果你住在美国,你可以使用ASCII.但在许多县,我们需要像ä,å,ü等字符(如果SO只是ASCII,或者你试图将这个文本读成ASCII编码文本,你会在ä,å和ü的地方看到一些奇怪的字符.想想中国,日本,泰国和其他"异国情调".你可能在世界各地看过的那些奇怪的照片可能是字母,而不是漂亮的照片.
至于不同编码类型之间的差异,您需要查看其规范.这是UTF-8的东西.
我不熟悉UTF-16.以下是有关差异的一些信息.
当需要编码需要存储的二进制数据并通过旨在处理文本数据的媒体传输时,使用Base64.如果您曾经使用PHP制作了一些电子邮件系统,那么您可能遇到过Base64.
简短:支持计算机程序对许多不同语言的用户界面本地化.(编程语言仍然主要由ASCII编码中的字符组成,虽然例如在Java中可以在变量名中使用UTF-8编码,并且源代码文件通常存储为除ASCII编码文本之外的其他内容,例如UTF- 8编码.)
简而言之:第2卷:总是当不同的人试图从特定的角度解决某些问题时(或者甚至在没有观点的情况下甚至可能),结果可能会大不相同.引用Joel的unicode文章(下面的链接):"因为字节有多达8位的空间,很多人不得不思考,"天哪,我们可以将代码128-255用于我们自己的目的."麻烦的是,很多人们同时有这个想法,他们有自己的想法,应该在128到255的空间里去哪里."
感谢Joachim和tchrist的所有信息和讨论.这是我刚读过的两篇文章.(这两个链接都在我之前链接的页面上.)自从我几年前读到它以来,我忘记了Joel文章中的大部分内容.我希望这个主题有很好的介绍.马克戴维斯更进一步.
有这么多变种的真正原因是Unicode联盟来得太迟了.
在开始内存和存储是昂贵的,并且使用超过8(或有时仅7)的内存来存储单个字符被认为是过度的.因此,几乎所有文本都是使用每个字符7或8位存储的.显然,8位内存不足以代表所有人类语言的字符.它几乎不足以代表单一语言中使用的大多数字符(对于某些语言,即使这是不可能的).因此,许多不同的字符编码被设计为允许不同的语言(英语,德语,希腊语,俄语,......)以每个字符8位编码它们的文本.毕竟单个文本文件(通常甚至是单个计算机系统)只能用于一种语言,对吧？
这导致了一种情况,即没有单独商定的字符映射到任何类型的数字.许多不同的,不兼容的解决方案,其中产生并且不存在真正的中央控制.一些计算机系统使用ASCII,其他计算机系统使用EBCDIC(或更确切地说:EBCDIC的许多变体之一),ISO-8859-*(或其众多衍生物之一)或任何现在几乎没有听说过的大编码.
最后,Unicode Consortium逐步完成了生成单一映射的任务(以及许多有用但超出此答案范围的辅助数据).
当Unicode联盟最终产生了一个相当全面的计算机可能代表的字符列表(连同许多编码方案将它们编码为二进制数据,具体取决于您的具体需求),其他字符编码方案已经被广泛使用.这大大减缓了Unicode及其编码(UTF-8,UTF-16)的采用.
如今,如果您想表示文本,最好的办法是使用可以代表所有Unicode字符的少数编码之一.UTF-8和UTF-16一起应该足以满足所有用例的99%,UTF-32几乎涵盖所有其他用例.而且要明确:所有UTF-*编码都可以编码所有有效的Unicode字符.但由于UTF-8和UTF-16是可变宽度编码的事实,它们可能不适用于所有用例.除非您需要能够与无法处理这些编码的遗留系统进行交互,否则现在很少有理由选择其他任何东西.
| 归档时间： |
|
| 查看次数： |
36084 次 |
| 最近记录： |