维基百科

维基百科:格式手册/计算机

< Wikipedia:格式手册
格式手册
内容
格式
图片
排版
列表
特定主题
法律
文艺
地区
科学
相关方针指引
灰字链接非正式指引，仅供参考

本页的目的，是为电脑科学、软体、网际网路及资讯科技等领域之条目提供基本的格式指引。在遵循此指引的同时，也应该遵循格式手册的其它方针与指引。

商标

编辑
主页面：维基百科:格式手册/商标

在编辑与电脑科学相关公司、产品或服务之商标名称时，请遵照维基百科的商标相关方针与指引。

避免常见错误

编辑

维基百科不是字典。使用者应尽量将相同性质之科技相关术语或产品整合为较完善、优质的文章，而不是建立大量的小作品。

产品目录

编辑

任何介绍产品的条目皆应包含其开发背景及版本更迭。但是，维基百科不是目录也不是资讯收集处，因此不应将该产品的每一次更新或版本更迭全部列出。基本上，只需要包含一定程度的资讯，能让读者大致了解该产品的演进历程即可。如需列出产品的所有版本，可以在维基数据处编辑对应数据项的“软件版本”属性。

同时，也不要直接将产品诸多特色以列表形式呈现，因为表列的资讯可能会过期，或因为协助广告或宣传嫌疑而遭到移除；另外，请尽量不要使用模棱两可的时间词，如“近年来”及“今日”等。

产品的命名

编辑

在为产品条目命名时，应建立其最常用名称之重定向页。

大多数的软体供应商会使用两种方式为产品系列中的某一特定版本命名：

  1. 以版本号命名，如iOS 11、iOS 12等。
  2. 以特定名称命名，如Windows XP、Windows Vista等。

不过电子游戏业界则不同。大部分的电子游戏标题中带有的数字，是用以表达前作及续作之间的关系，而不只是单纯的版本号。例如，《超级玛利欧兄弟3》跟《超级玛利欧兄弟2》为前后作关系，是两款完全不同的游戏。不过有些时候电子游戏发行商仍会使用版本号以区别特定更新版本，例如《终极动员令：红色警戒2》v.1.008就单纯只是《终极动员令：红色警戒2》的更新补丁而已。

在描述产品时请尽量使用其最常使用的名称，如应使用Windows XP而不是Windows 5.1或Windows NT 5.1。另外，请不要混用版本号及特定名称，如应避免使用Windows v6.0或Windows 6指代Windows Vista。同时，维基百科也禁止自创缩写。

服务包

编辑

服务包是程式的更新、修复和补丁的合辑，基本上以独立安装套件之形式发布。使用者在编辑相关条目时，应清楚区分服务包与产品用词。

在描述服务包本身时，应列出该服务包之全名，例如：

  • Windows XP Service Pack 2
  • WinZip 9 Service Release 1

在描述已安装服务包的产品时，建议使用“（已）安装‘服务包名称’的‘产品名称’”，例如：

  • （已）安装Service Pack 2的Windows XP
  • （已）安装Service Release 1的WinZip 9

此外，在有需要时，可将软体版本号简写，例如：

  • Windows XP SP2
  • WinZip 9 SR-1

请尽量只使用上述其中一种方式撰写条目。若过度混合使用，将导致不熟悉科技术语的读者无法区分服务包及产品两者之间的差别。若引用来源中同时使用多种描述方式时，请尽量减少文章中的用词差异，并详细描述每一用词所指对象。

x86与IA-32

编辑

在撰写电脑相关条目时，请谨慎使用“x86”一词，因为其定义可能根据文章性质而有所不同。广义的x86是指由英特尔首先推出，其它厂商随后跟进研发的一种中央处理器指令集架构。x86又根据所使用的位元组字长不同，分为采用32位元架构的IA-32与采用64位元架构的x86-64，其中IA-32因其高普及率成为“x86”的代名词。不过，在撰写条目时，仍应将用词区分清楚。

使用范例
正确用法 错误用法 备注
“此程式支援IA-32及x86-64架构。” “此程式支援x86及x86-64架构。” 由于x86-64本身为x86架构分支之一，将两者并列即属画蛇添足。
“此程式支援IA-32架构，但不支援x86-64架构。” “此程式支援x86架构，但不支援x86-64架构。” 由于x86架构中已包含x86-64，使此段描述自相矛盾。
“此程式支援IA-32、ARM及PowerPC架构。” “此程式支援x86架构。” 尽管x86、ARM及PowerPC属于相同层级且互不相容的硬体架构，将其并列理论上并无不妥之处；但由于“x86”一词本身有多重涵义，在没有特别指明整个x86架构皆包含在内的情况下，应将详细的分支架构列出。

32位元与64位元

编辑

请勿使用任何关于位元组字长，如“32位元”、“64位元”等用词描述特定软硬体架构。由于这些用词之定义过于模糊不清，若使用容易造成读者误解。

在多数情况下，32位元及64位元分别是指采用该长度位元组之中央处理器架构中最常用者，即IA-32及x86-64（又称x64）。但由于两者皆不是唯一采用32及64位元的架构，因此不能用以代称“32位元”及“64位元”中央处理器。在撰写条目时，应清楚列明特定架构名称。

正确用法举例：

  • “此程式支援x64架构之中央处理器。”
  • “至于产品的IA-64版本⋯⋯”
  • “⋯⋯专为Zilog Z80及与其相容的中央处理器设计的.z80格式⋯⋯”

错误用法举例：

  • “此程式支援64位元架构之中央处理器。”
  • “至于产品的32位元版本⋯⋯”

Linux与GNU/Linux

编辑
参见：GNU/Linux命名争议、en:Talk:Linux/Archive 41 § Page move: GNU/Linux和en:Talk:Linux/Referring to this article

请使用“Linux”而非“GNU/Linux”描述以Linux核心为基础的作业系统。GNU/Linux一词应仅用于描述特定作业系统和部分Linux发行版。

尽管自由软体基金会建议使用GNU/Linux为Linux的标准译名，但维基社群基于名从主人原则，在参考诸多可靠来源及长时间的多方讨论之后，决定否决自由软体基金会之主张，选择以Linux作为维基百科内的通用译名。

任何主张都要有来源佐证

编辑
主页面：维基百科:可供查证和维基百科:可靠来源

在维基百科中，任何主张都必须有可靠来源佐证，包括软体的发售时间、大小、支援语言及开发时所使用的程式语言等。有些主张看似“不必证明”，因而容易被编辑者所忽略，包括“支援多种语言”、“以C++语言撰写”及“在Windows环境中开发”等。

用词的搭配

编辑

请不要刻意在条目中使用赘词或艰涩难懂的字汇。维基百科的目标是让读者阅读资讯时感到舒适，而不是成为线上权威学术期刊。若无必要，请勿使用罕用或具违和感的同义词，因为没有必要。

常见情形如下：

  • 已经被被开发者或版权所有者忽略，因此不再进行销售或提供技术支援的电脑软体应称为“已被废弃的软体”（abandonware），而不必使用“已被忘却的软体”（forgottenware）等具不必要文学意涵的用词。
  • 描述“产品的生命周期结束时，供应商停止行销、售后服务等行为”的术语应称为“停止支援”（discontinuation）而非“丢弃”（abandonment）。
  • 电脑程式“运行于作业系统中”（run under），而非“运行于作业系统上”（run up）或“运行于作业系统下”（run down）。
  • 电脑程式“自用户帐号中”（in/within the context of a user account）存取资料，而非“自用户帐号上”（on）、“自用户帐号下”（under）、“自用户帐号里”（inside）或“自用户帐号外”（over）存取资料。尽管这些词语在口语或非正式场合使用是没有问题的，但典范条目标准建议使用较精准的词汇。
  • 尽管都是“碟”，但“光碟”（disc）与“磁碟”（disk）采用的读取结构完全不同，前者使用光学雷射扫描，后者则使用磁性媒介读写，请多加注意。

描述口吻

编辑

请避免使用过去式描述具有存在事实的事物。

错误用法举例： System Software 6曾是由苹果电脑开发，并曾发行于麦金塔平台上的作业系统。

上述用法会让读者认为System Software 6这个作业系统现在已经“不是由苹果电脑开发”、“不是发行于麦金塔上”了；但事实上作为已经发售的作业系统，其开发者及发行平台皆已成为既定事实，并不会随时间经过而改变。若必须要表达该事实已经发生，则应使用适当的年代表述。

正确用法举例： System Software 6是由苹果电脑开发，并于1988年4月发行在麦金塔平台上的作业系统。

命令行相关

编辑

命令行范例指的是一段程序或者shell命令的具体用法，用户可以将其输入计算机终端或者命令提示符运行。本章节描述这些范例，以及其他命令行内容的格式规范。

通用指引

编辑

当提供命令行范例时应当保持清晰和简单。这不仅会显得更专业，同时也防止读者产生困惑。下面的指南界定了什么是清晰，简单的范例。

  • 命令行的例子应当采用等宽字体。对于行内的代码，应该使用 <code>（有时要配合<nowiki>）。对于多行的代码块，应该使用mediawiki语法，在行前加一空格；或者也可以使用<pre>生成不带维基文本支持的代码块。对于Unix shell，也可以使用<syntaxhighlight>的lang="shell-session"高亮。
  • 维基百科不是一个展示作者的个人偏好的媒介。因此除非有必要，否则不应包含任何环境变量，日期，工作目录，用户名或主机名称。
  • 术语：选项(option)是一种开关（一些修改一般行为的命令） 。参数(parameter)是一个特定值，如文件或主机名称。引用(argument)这个词是用来指任何空格分隔的字符串按照命令的名字，其中包括选项和参数。
  • 列举引用时，应注意保持简单。不加解释地定义引用会混淆读者。
  • 维基百科不能取代手册页。条目不应该列出与命令相关的整个选项列表，除非这样的选项非常少，或者这样的描述方式是绝对必要的。
  • 当指定参数时，应当使用合理的名称来指代他们。这些名称应该使用斜体，不应包含空格（空格通常用来分隔命令行的多个引用，使用空格会导致混淆）。以下是一些例子：
(提示符) command parameter-name

(提示符) command parameterName

(提示符) command parameter_name

(提示符) command parametername
  • 一致性是很重要的。不要在同一个条目里同时使用上述四种方法来命名参数，以免混淆读者。
  • 非必须并且可以完全省略的引用应放在方括号[ ]中。
  • 有很多方法指定重复的参数。以下两个是最常见的：
(提示符) command parameter0 [.. parameterN]

(提示符) command [parameter ...]

具体平台指引

编辑

DOS、Windows、OS/2

编辑

目前最常见的DOS平台是Windows平台下的MS-DOS。因此，仅在MS-DOS下适用的例子一般不需要特别说明。但是，如果该实例仅针对某个特定版本的MS-DOS，那么应当标明相关信息。如果已知其他的DOS平台下该范例有不同的效果，也应当加以说明。 适用于DOS命令行的例子应遵循下列额外的指导方针：

  • 程序或命令名应全部大写。
  • 标准的MS-DOS风格的选项（例如/C，其中C可能是其他字符）也应该大写，除非它们是区分大小写的。
  • 程序名称应当附加适当的文件扩展名，以与内置的命令名称相区别。如果某些版本的MS-DOS中不包含某个特定的程序（如MOVE.EXE或EDIT.COM），那么应当注明包含这些程序的版本。

类Unix系统

编辑
  • 大部分类Unix系统的命令实际上都是可执行文件。Shell内建的命令（如cd和history）也在我们讨论的范围内。
  • 类Unix系统中常见的Shell相互之间有着一定的差异。因此，与特定的Shell相关的命令或者实用程序（如for循环或者流特性）应当尽可能地避免。
  • 如果为了正确地作出说明必须使用一串与特定Shell类型相关的命令，那么你应当同时提供类ALGOL的sh，ksh和bash代码，以及C语言风格的csh和tcsh代码。两者的语法没有差别时无需这么做。
  • 类Unix系统中的大部分命令都是全部使用小写字母的。然而，由于shell和操作环境区分大小写的特性，应注意大小写格式与命令或文件名匹配。如果有必要，建议使用标题错误模板。
  • 通常情况下需要权限的命令与不需要权限的那些应当加以区别。如果某个命令确实需要特定权限，那么应当给出一份免责声明指出在无限制的权限下执行命令所具有的风险。
  • 在某些情况下，命令行参数很可能包含一些shell元字符（如通配符等）。在这种情况下，明智的做法是在例子中使用引号，以防止用户收到让他们感到奇怪或者毫无来由的错误。

提供范例输出

编辑

为一个命令提供输出范例是一种保守的做法。这种情况下应当给出在终端中实际键入的完整的命令和所有的参数。命令的输出因此将只依赖于运行环境和其他变量。依顺序使用标签prenowiki可以确保输出文字的格式正确。

使用范例

编辑

DOS

编辑
  • DOS 预设命令DIR，这用于列出档案和资料夹:
> DIR [options] [pattern ..]
  • MS-DOS （其行为模拟了先前版本DOS的功能）上的程序 MOVE.EXE：
> MOVE.EXE source target

常规Unix

编辑
  • 用Unix风格系统上的ls命令列出文件和目录：
$ ls [options] [file ..]
  • 用mkfs命令创建新的文件系统，通常需要一定的权限：
# mkfs [-t fstype] [fs-options] device
  • wget程序，GNU实用工具之一，根据给出的URI获取文件。URI可以包含shell的元字符，因此参数需要加引号以防止出错。
$ wget [options] 'URI'

Shell特性

编辑
  • sh/ksh/bash中内置if结构的语法异同：
$ if command ; then command ; .. ; fi

在csh/tcsh中: 

% if (expression) then command ; .. ; endif

输出举例

编辑
  • df命令的输出举例，列出了挂载的文件系统磁盘空间使用情况：
$ df -P
Filesystem          512-blocks      Used Available Capacity Mounted on
/dev/hda2             39331760   7398904  29834768      20% /

避免重复举例

编辑

按照方针，维基百科不是教程，也不是未经筛选的例子收集处。编者应该将页面上已有的冗余代码全部移动至维基教科书的相关页面。

  • 在算法类条目（如快速排序）中不应用几种类似的语言重复举例，而要使用单个语法简单的流行语言或伪代码书写范例。按照不同编程范型实现算法、分开举例则一般是可以接受的。编者可以在维基教科书b:算法实现内罗列各种语言的实现。如b:算法实现/排序/快速排序。避免使用为特定语言、计算平台或编译器的代码优化而损失可读性的代码片段（如p[++i]=xxx;），请在维基教科书中详细介绍此类代码片段。
  • 在命令行程序的条目中的例子语言（csh、bash、cmd…）不同常常是Shell命令语言的不同。这不属于程序本身的功能，也须节制加入。
  • 在计算机语言条目（如Python）中不应使用大段代码来介绍该语言的语法。最好只保留该语言的helloworld程序示例，并使用文字或列表来说明该语言所支持的语法特性（如循环、函数对象等），并添加内部链接指向那些语法特性。
  • 移动代码段时要做以下几件事：
    • 在维基教科书的讨论页张贴来源横幅。
    • 在条目的外部链接部分使用{{wikibook}}模板来指出代码的位置。
    • 编辑维基数据项，添加跨语言链接，将教科书内的页面和维基百科条目关联。

网址

编辑
参见：维基百科:格式手册/连结

公开的URL

编辑

HTTP和HTTPS

编辑

一个网站可能同时支援超文本传输协定（HTTP）和超文本传输安全协定（HTTPS）传输协议，即网址以http://／https://开头。我们建议使用者参照以下模式加入连结：

  • 当网站只使用HTTPS，或同时支援HTTP和HTTPS时，使用https://。
  • 当网站只使用HTTP时，使用http://。
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia:格式手册/计算机&oldid=80232019”