mql5语言的特点、微妙之处以及技巧 - 页 163 1...156157158159160161162163164165166167168169170...247 新评论 Maxim Kuznetsov 2020.01.27 01:16 #1621 Nikolai Semko: 我没有注意到。虽然我不排除在某些情况下（在使用Unicode时），这是可能的。例如，在Java中，char类型是2字节。 我试着用两种方式解析加密交易所的数据：通过这个JSON库 和通过使用char数组工作。 结果发现，按速度计算，差异是700(!!!)倍。我很震惊。也许这远远不是最好的JSON实现。 字符是16LE，字符串显然是来自Pascal。顺便说一下和Fortran中的数组 Roman 2020.01.27 01:16 #1622 Nikolai Semko: 我没有注意到。虽然我不排除在某些情况下（在使用Unicode时），这是可能的。例如，在Java中，char类型是2字节。 我试着用两种方式解析加密交易所的数据：通过这个JSON库 和通过使用char数组工作。 结果发现，按速度计算，差异是700(!!!)倍。我很震惊。也许这远远不是最好的JSON实现。 当把mql字符串传给dll时，在dll这边，mql字符串的类型被当作wchar_t*。 而且类型大小不匹配不仅在Java中发现，它取决于架构类型，我不记得是什么，或者操作系统，或者铁。 700次？哇，我正把这个库放在一边，用于JSON解析，这不值得吗？ 在循环 中翻译StringToCharArray和解析数组 更好？ Nikolai Semko 2020.01.27 01:52 #1623 Roman: 700次？哇，我刚刚把这个库放在一边，用于JSON解析，所以它不值得？ 在循环 中翻译StringToCharArray和解析数组 更好？ 我想是的，是的。尽管你应该经常检查它。做一些测量。我不排除字符串函数没有以最好的方式编写，现在它们已经被修复。 我在一年多前进行了这些测量。 在处理char数组时，代码当然会比较大，但它更灵活。 [删除] 2020.01.27 12:40 #1624 Roman: 而且很可能在mql字符串下有short[]或wchar_t[]或wchar_t*。 毕竟，mql字符串是Unicode的，而utf是2字节的。 而StringToCharArray从short[]转换为char[]。 unicode != utf && utf != 2 bytes (utf与utf不同) && MSVC不是一个标准 wchar_t的意义在于将任何支持的字符装入一个wchar_t中（好吧，大约是smallsoft他们的方式），而输入输出流自己转换为/脱离locale编码。没有大小/编码的保证。当在dll中接受wchar_t时，要考虑它是否正确。除非，当然，把目光从沙盘转向成人世界是很有趣的。 Roman 2020.01.27 13:45 #1625 Vict: unicode != utf && utf != 2bytes (utf utf'y是不同的) && MSVC不是一个引用 wchar_t的意义在于将任何支持的字符装入一个wchar_t中（好吧，大约是smallsoft他们的方式），而输入输出流自己转换为/脱离locale编码。没有大小/编码的保证。当在dll中接受wchar_t时，要考虑它是否正确。除非，当然，把目光从沙盘转向成人世界是很有趣的。 是的，我知道Unicode和UTF是不同的编码，而且它们应该是不同的。 我只是想写和缩写Unicode这个词，所以我想我没有写好。 尽管Unicode参考资料说，该标准包括了世界上几乎所有书面语言的字符。 该标准由两个主要部分组成：通用字符集（UCS）和统一码转换格式（UTF）。 因为Unicode已经包含了UTF编码，所以我这样说是为了让这个词更短。 我不知道wchar_t*是否正确。 使用了Renat的例子中的内容，来自如何编写dll的文章。 mql5字符串在Unicode中，包含UTF，因此我认为在文章的例子中使用wchar_t *是合理的。 为了在一个wchar_t中容纳任何支持的字符。 关于没有大小/编码保证，甚至不知道它，也许使用Cish短*的纯度呢？ 当然，如果它能被MSVC IDE正确支持的话。 因为通常的真实会被环境所吞噬，并赋予它真实性。 Edgar Akhmadeev 2020.01.27 13:57 #1626 UTF-8和UTF-16有适当的比特深度。 在UTF-8中，语言页面是通过特殊代码来切换的。 UTF-16同时包括了全部的字符种类。 Roman 2020.01.27 14:13 #1627 Edgar Akhmadeev: UTF-8和UTF-16有适当的比特深度。 在UTF-8中，语言页面是通过特殊代码来切换的。 UTF-16同时包括了全部的字符种类。 好吧，我从论坛上许多人写的东西中了解到，mql5字符串只是在UTF-16中。 而在mql文档中，他们写道。 一个文本字符串是一个Unicode 格式的字符序列，结尾处有一个尾数0。 因为这一点，很难理解哪个编码实际上是mql5字符串。 如果Unicode已经包含了UTF的所有系列，那么为什么还要使用UTF这个词，并引入混淆。 Unicode就是全部，简单明了。 或者我们应该这样说吗？ 比特率为UTF-16的Unicode？ 事实上，早些时候有开发者写道 mql字符串类型由两部分组成，缓冲区8字节，指针4字节，共12字节。 [删除] 2020.01.27 14:36 #1628 Roman: 我知道Unicode和UTF是不同的编码。 正好，我想写和缩写unicode这个词，可能不是运气。 尽管Unicode参考资料说，该标准包括了世界上几乎所有书面语言的字符。 该标准由两个主要部分组成：通用字符集（UCS）和统一码转换格式（UTF）。 因为Unicode已经包含了UTF编码，所以我这样说是为了让这个词更短。 我不知道wchar_t*是否正确。 使用了Renat的例子中的内容，来自如何编写dll的文章。 mql5字符串在Unicode中，包含UTF，因此我认为在文章的例子中使用wchar_t *是合理的。 为了在一个wchar_t中容纳任何支持的字符。 你很迷惑。Unicode是一个带编码的字符表，它曾经适合在0-65535（2个字节） 内，然后它又增长了。而每个字符花费4个字节是很肥的。这就是utf，一种具有可变长度的编码的用武之地（例如，utf-8用一个字节编码ASCII字符）。因此，Unicode（表）不包含任何utf。 关于没有大小/编码保证，甚至不知道它，可能使用Cish短*的纯度，然后？ 当然，如果它能被MSVC IDE正确支持的话。 因为通常的真实会被环境所吞噬，并赋予它真实性。 该标准包括char16_t、 char32_t、固定尺寸类型。Wchar_t有不同的含义。 Edgar Akhmadeev 2020.01.27 14:42 #1629 Roman: 就我对这个论坛上许多人写的东西的理解而言，mql5字符串是UTF-16的。 而在mql文档中，他们写道。 一个文本字符串是一个Unicode 格式的字符序列，末尾有一个尾巴零。 因为这一点，很难理解哪个编码实际上是mql5字符串。 如果Unicode已经包含了UTF的所有系列，那么为什么还要使用UTF这个词，并引入混淆。 Unicode就是全部，简单明了。 或者应该这样说？ 具有UTF-16比特率的Unicode ? 这还不是全部。 由于ANSI西里尔语=CP1251，所以 Unicode。 UTF-8 = CP65001, // UNIX/Linux UTF-16LE = CP1200, // Windows utf-16be = cp1251。 UTF-32LE = ? UTF-32BE = ? ISO10646。 UCS-2 ~ UTF-16 UCS-4 = UTF-32 混乱？没有，没有听说。 [删除] 2020.01.27 14:42 #1630 Edgar Akhmadeev: UTF-8和UTF-16有适当的比特深度。 在UTF-8中，语言页面是通过特殊代码来切换的。 UTF-16同时包括了全部的字符种类。 什么代码页，你在说什么？特殊代码 "定义了编码一个字符的字节数，因为编码的长度是可变的。UTF-8可以编码任何Unicode字符，也可以编码UTF-16。而utf-16具有可变长度（代理对）。 1...156157158159160161162163164165166167168169170...247 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
我没有注意到。虽然我不排除在某些情况下（在使用Unicode时），这是可能的。例如，在Java中，char类型是2字节。
我试着用两种方式解析加密交易所的数据：通过这个JSON库 和通过使用char数组工作。
结果发现，按速度计算，差异是700(!!!)倍。我很震惊。也许这远远不是最好的JSON实现。
字符是16LE，字符串显然是来自Pascal。顺便说一下和Fortran中的数组
我没有注意到。虽然我不排除在某些情况下（在使用Unicode时），这是可能的。例如，在Java中，char类型是2字节。
我试着用两种方式解析加密交易所的数据：通过这个JSON库 和通过使用char数组工作。
结果发现，按速度计算，差异是700(!!!)倍。我很震惊。也许这远远不是最好的JSON实现。
当把mql字符串传给dll时，在dll这边，mql字符串的类型被当作wchar_t*。
而且类型大小不匹配不仅在Java中发现，它取决于架构类型，我不记得是什么，或者操作系统，或者铁。
700次？哇，我正把这个库放在一边，用于JSON解析，这不值得吗？
在循环 中翻译StringToCharArray和解析数组 更好？
700次？哇，我刚刚把这个库放在一边，用于JSON解析，所以它不值得？
在循环 中翻译StringToCharArray和解析数组 更好？
我想是的，是的。尽管你应该经常检查它。做一些测量。我不排除字符串函数没有以最好的方式编写，现在它们已经被修复。
我在一年多前进行了这些测量。
在处理char数组时，代码当然会比较大，但它更灵活。
而且很可能在mql字符串下有short[]或wchar_t[]或wchar_t*。
毕竟，mql字符串是Unicode的，而utf是2字节的。
而StringToCharArray从short[]转换为char[]。
unicode != utf && utf != 2 bytes (utf与utf不同) && MSVC不是一个标准
wchar_t的意义在于将任何支持的字符装入一个wchar_t中（好吧，大约是smallsoft他们的方式），而输入输出流自己转换为/脱离locale编码。没有大小/编码的保证。当在dll中接受wchar_t时，要考虑它是否正确。除非，当然，把目光从沙盘转向成人世界是很有趣的。
unicode != utf && utf != 2bytes (utf utf'y是不同的) && MSVC不是一个引用
wchar_t的意义在于将任何支持的字符装入一个wchar_t中（好吧，大约是smallsoft他们的方式），而输入输出流自己转换为/脱离locale编码。没有大小/编码的保证。当在dll中接受wchar_t时，要考虑它是否正确。除非，当然，把目光从沙盘转向成人世界是很有趣的。
是的，我知道Unicode和UTF是不同的编码，而且它们应该是不同的。
我只是想写和缩写Unicode这个词，所以我想我没有写好。
尽管Unicode参考资料说，该标准包括了世界上几乎所有书面语言的字符。
该标准由两个主要部分组成：通用字符集（UCS）和统一码转换格式（UTF）。
因为Unicode已经包含了UTF编码，所以我这样说是为了让这个词更短。
我不知道wchar_t*是否正确。
使用了Renat的例子中的内容，来自如何编写dll的文章。
mql5字符串在Unicode中，包含UTF，因此我认为在文章的例子中使用wchar_t *是合理的。
为了在一个wchar_t中容纳任何支持的字符。
关于没有大小/编码保证，甚至不知道它，也许使用Cish短*的纯度呢？
当然，如果它能被MSVC IDE正确支持的话。
因为通常的真实会被环境所吞噬，并赋予它真实性。
UTF-8和UTF-16有适当的比特深度。
在UTF-8中，语言页面是通过特殊代码来切换的。
UTF-16同时包括了全部的字符种类。
UTF-8和UTF-16有适当的比特深度。
在UTF-8中，语言页面是通过特殊代码来切换的。
UTF-16同时包括了全部的字符种类。
好吧，我从论坛上许多人写的东西中了解到，mql5字符串只是在UTF-16中。
而在mql文档中，他们写道。
一个文本字符串是一个Unicode 格式的字符序列，结尾处有一个尾数0。
因为这一点，很难理解哪个编码实际上是mql5字符串。
如果Unicode已经包含了UTF的所有系列，那么为什么还要使用UTF这个词，并引入混淆。
Unicode就是全部，简单明了。
或者我们应该这样说吗？
比特率为UTF-16的Unicode？
事实上，早些时候有开发者写道
mql字符串类型由两部分组成，缓冲区8字节，指针4字节，共12字节。
我知道Unicode和UTF是不同的编码。
正好，我想写和缩写unicode这个词，可能不是运气。
尽管Unicode参考资料说，该标准包括了世界上几乎所有书面语言的字符。
该标准由两个主要部分组成：通用字符集（UCS）和统一码转换格式（UTF）。
因为Unicode已经包含了UTF编码，所以我这样说是为了让这个词更短。
我不知道wchar_t*是否正确。
使用了Renat的例子中的内容，来自如何编写dll的文章。
mql5字符串在Unicode中，包含UTF，因此我认为在文章的例子中使用wchar_t *是合理的。
为了在一个wchar_t中容纳任何支持的字符。
你很迷惑。Unicode是一个带编码的字符表，它曾经适合在0-65535（2个字节） 内，然后它又增长了。而每个字符花费4个字节是很肥的。这就是utf，一种具有可变长度的编码的用武之地（例如，utf-8用一个字节编码ASCII字符）。因此，Unicode（表）不包含任何utf。
关于没有大小/编码保证，甚至不知道它，可能使用Cish短*的纯度，然后？
当然，如果它能被MSVC IDE正确支持的话。
因为通常的真实会被环境所吞噬，并赋予它真实性。
该标准包括char16_t、 char32_t、固定尺寸类型。Wchar_t有不同的含义。
就我对这个论坛上许多人写的东西的理解而言，mql5字符串是UTF-16的。
而在mql文档中，他们写道。
一个文本字符串是一个Unicode 格式的字符序列，末尾有一个尾巴零。
因为这一点，很难理解哪个编码实际上是mql5字符串。
如果Unicode已经包含了UTF的所有系列，那么为什么还要使用UTF这个词，并引入混淆。
Unicode就是全部，简单明了。
或者应该这样说？
具有UTF-16比特率的Unicode ?
这还不是全部。
由于ANSI西里尔语=CP1251，所以
Unicode。
UTF-8 = CP65001, // UNIX/Linux
UTF-16LE = CP1200, // Windows
utf-16be = cp1251。
UTF-32LE = ?
UTF-32BE = ?
ISO10646。
UCS-2 ~ UTF-16
UCS-4 = UTF-32
混乱？没有，没有听说。
UTF-8和UTF-16有适当的比特深度。
在UTF-8中，语言页面是通过特殊代码来切换的。
UTF-16同时包括了全部的字符种类。
什么代码页，你在说什么？特殊代码 "定义了编码一个字符的字节数，因为编码的长度是可变的。UTF-8可以编码任何Unicode字符，也可以编码UTF-16。而utf-16具有可变长度（代理对）。