NSIS安装程序使用错误的字符集创建目录 [英] NSIS installer creates directory using wrong character set

问题描述

在某些机器上，我的NSIS安装程序会创建一个错误字符的文件夹。

NSIS应该创建一个包含 / p>

  // U + 0144ńc5 84拉丁小写字母N与ACUTE 
  pre> 
 
 
，而是创建了一个包含ñ char 
的文件夹
 
 
  // U + 00F1ñc3 b1拉丁小信件N与TILDE 
  
部分是只发生在一些机器上，我不能重现。据我所知，这只是为Windows Vista（可能是基本版）。
 
 
 
我怀疑这与Windows-1250到UTF转换有关。因为NSIS仍然不支持UTF，我使用Windows-1250编码的脚本文件。   char是 0xF1 ，应翻译为UTF  U + c584 安装程序将创建包含 U + c3b1  char的文件夹。另一方面， U + c3b1 等效于Windows-1252  0xF1 。
 
 
 
当编译安装程序运行时，什么可能影响NSIS脚本中使用的字符的解释？如何保证预期转换 0xF1  =>  U + c584 ？
语言为非Unicode程序（系统区域设置））。
 
 
 
您可以尝试创建自定义 LangString 。为了这个工作，你必须设置您的编辑器代码页到有问题的代码页，当键入ń。你可以通过在.onInit和StrCpy中检查$ LANGUAGE（或使用 System :: Call kernel32 :: GetACP（）i.r0 并检查$ 0） 
 
 
 
下一个NSIS版本可能是v3.0，我不知道你从哪里得到2.50，但它可能是只是unicode fork使用的占位符。
 
On some machines my NSIS installer creates folder with one wrong character.

The NSIS was supposed to create a folder with ń char
// U+0144   ń   c5 84   LATIN SMALL LETTER N WITH ACUTE
but instead created a folder with ñ char
// U+00F1   ñ   c3 b1   LATIN SMALL LETTER N WITH TILDE
The wired part is that happens only on some machines and I could not reproduce that. As far as I can tell this was reported only for Windows Vista (possibly basic edition).

I suspect that this has something to do with Windows-1250 to UTF conversion. Because NSIS still does not support UTF, I'm using Windows-1250 encoded script file. The ń char is 0xF1 and should be translated to UTF U+c584, but instead the installer creates folder with U+c3b1 char. On the other hand the U+c3b1 is equivalent of Windows-1252 0xF1.

What may affect the interpretation of characters used in NSIS script, when compiled installer runs? How to assure expected conversion 0xF1 => U+c584?
解决方案
The encoding of the NSIS source script does not really decide the final string, the translation of bytes from the script/installer to a unicode string happens on the end users system, therefore characters outside ASCII can vary based on the systems default codepage (Language for non-Unicode programs (System Locale)).

You can try to create a custom LangString for this directory name. For this to work you have to set your editors codepage to the problematic codepage when typing the ń. You can probably emulate this by checking $LANGUAGE (or use System::Call kernel32::GetACP()i.r0 and check $0) in .onInit and StrCpy a string that translates correctly on this system into the problematic variable.

The next NSIS version will probably be v3.0, I don't know where you got 2.50 from but it is probably just a placeholder used by the unicode fork.

                        
这篇关于NSIS安装程序使用错误的字符集创建目录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！