<
返回首页

[WinStory #5] 再谈硬编码:onghornLay —— 检验硬编码的另一有趣方式

来源:哔哩哔哩

上一期我谈到了硬编码对本地化的影响,这一期我们接着上文,再从其他方面谈谈硬编码对 Windows 的影响。


(相关资料图)

比如 Michael S.Kaplan 在其博客里所写,记事本自从 Windows NT 3.1 引入“支持以不同编码保存文件”的功能以来,其默认保存的编码格式一直是 ANSI,即使在 1998-1999 年添加了 UTF-8 支持之后也是如此。这一默认方式延续了近25年,直到 Windows 10 Build 1903 后默认编码才改成了 UTF-8.

一直以来,不断有客户向微软提出建议,希望在使用记事本保存文件时自动使用 UTF-8,而不是默认使用 ANSI。

而 Kaplan 的回答是:

这不可能。此默认值已硬编码到记事本中。

他们在 1993 年将记事本的这一功能添加到 NT 3.1 时就做出了决定,并坚持他们的做法——即使在 1998-1999 年添加了 UTF-8 支持之后也是如此。

这是硬编码对文本编辑的影响。

之前我提到过,伪本地化是检验字符串是否被硬编码的方式之一。而其实,在 Windows 历史上,微软在 Longhorn 构建中还曾采用过另一种方式来检验版本字符串是否被硬编码 —— 猪拉丁语(Pig Latin),这一方式在 Build 4029-4040 中采用。

为什么要检验字符串是否被硬编码?原因与当年发布的 Windows Server 2003 有关。

Windows Server 2003 在开发过程中名称更改过多次,如“Whistler Server(开发代号)”“Windows XP Server”“Windows 2002 Server(未正式采用)”“Windows .Net Server (2003)”,直到最后的“Windows Server 2003”

而每一次的名称更改都要耗费微软大量的时间和精力,因为版本字符串在很多地方都是硬编码的。

为了让 Longhorn 不重蹈 Server 2003 的覆辙,微软在 Longhorn 中采用了猪拉丁语标记版本字符串,这样一来,如果某个地方的名称没有被更改,那么就说明它被硬编码了。

附猪拉丁语的规则:

对于以辅音开头的单词,初始元音之前的所有字母都放在单词序列的末尾,然后添加“ay”,如“Pig”→“igPay”

当单词以辅音群(形成一个声音的多个辅音)开头时,在说话或写作时将整个声音添加到末尾。如:“Friend”→“iendsFray”

对于以元音开头的单词,只需在末尾添加“hay”、“way”或“yay”(或仅添加“ay”)。如:"eat" = "eatway" 或 "eatay"

但是,根据这一规则,“Professional”应该要被翻译成“ofessionalPray”,但微软内部似乎并没有人在意这一点(毕竟语法有错并不影响他们检验硬编码)

标签: