微处理器的“编码格式”是否正确？具体的？
计算机系统是基于二进制系统的。数据/指令以二进制编码。编码可以采用多种格式进行 - ASCII、UNICODE 等。
微处理器是否适合选定的“编码格式”？如果是，它如何兼容其他编码格式？在这种情况下不会有性能损失吗？
当我们创建一个程序时，它的编码格式是如何选择的？
A computer system is based on binary system. Data/instructions are encoded in binary. Encoding can be carried out in many formats - ASCII, UNICODE etc.
Is a microprocessor made for a chosen 'encoding format' ? if yes, how would it become compatible to other encoding formats? wouldn't there be a performance penalty in that case?
when we create a program, how its encoding format is chosen?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
ASCII 和 UNICODE 是文本数据的编码，与二进制数据无关。
ASCII and UNICODE are encoding of text data and have nothing about binary data.
不，微处理器所知道的都是二进制数——它们不知道这些数字的含义。这种意义是由我们和我们用于构建程序的工具提供的。例如，如果您使用 Visual Studio 编译 C++ 程序，它将使用多字节字符，但 CPU 不知道这一点。
No, all microprocessors know about is binary numbers - they don't have a clue about the meaning of those numbers. That meaning is provided by us and by our tools used to build programs. For example, if you compile a C++ program using Visual Studio, it will use multi-byte characters, but the CPU doesn't know that.
微处理器架构非常重要的一个领域是字节序 - 例如，当您尝试读取 UTF 时-16LE 在大端机器上编码文件，您必须交换每个代码单元的各个字节才能获得预期的 16 位整数。对于所有代码单元宽于一个字节的编码形式来说，这是一个问题。有关详细信息，请参阅 Unicode 标准第二章的 2.6 节 -深入讨论。处理器本身仍然处理单个整数，但作为库开发人员，您必须处理从文件（即字节序列）到内存数组（即代码单元序列）的映射。
One area where the microprocessor architecture does matter is endianness—for example, when you try to read a UTF-16LE encoding file on a big-endian machine, you have to swap the individual bytes of each code unit to get the expected 16-bit integer. This is an issue for all encoding forms whose code unit is wider than one byte. See section 2.6 of the second chapter of the Unicode standard for a more in-depth discussion. The processor itself still works with individual integer numbers, but as a library developer, you have to deal with the mapping from files (i.e., byte sequences) to memory arrays (i.e., code unit sequences).