GNU 编码标准
870
最近更新日期： 2002/10/08 Tue 10:50:24+0800 CST
GNU 编码标准
● 引用私有程序
● 接受他人的奉献
● 修改日志（Change Logs）
● 与其它实现的兼容性
● Makefile惯例
r Makefile的通用惯例
r Makefile中的工具
r为用户提供的标准目标
r为指明命令而提供的变量
r为安装目录而提供的变量
● 配置是如何进行的
● 使用C以外的语言
● 格式化你的源代码
● 为你的工作写注释
● 清晰地使用C语言成分
● 命名变量和函数
● 使用非标准的特征
● 适用于所有程序的程序行为
● 格式化错误信息
● 库的行为
● 适用于GNU的移植性
● 命令行界面标准
● 为程序制作文档
● 制作发行包
GNU编码标准
GNU编码标准@author{Richard Stallman} @author{last updated 03 Feb 1993}
Copyright (C) 1992, 1993 Free Software Foundation
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by Free Software Foundation.
本文由王立翻译. 1999.11.9
引用私有程序
不要在任何情况下,为你在的GNU中的工作或者在工作中引用Unix的源代码（或者任何其它私有程序）。
如果你对一个Unix程序内容有一些模糊的记忆，这并不因为着你绝对写程序来模仿它， 但请试图在内部使用不同的代码行来组织它，因为这将使你工作的结果在细节上与Unix版本有所不同。
例如，Unix工具通常进行了优化以使用最少的内存；如果你更希望提高速度，你的程序将会有很大的不同。 你可以在内核中保存整个输入文件并且在内存中扫描而不是使用stdio。使用比Unix程序更新的、 更明智的算法。不使用暂时文件。在一遍扫描而不是两遍扫描中完成任务（我在assembler（汇编器）中这样做了）。
或者相反，强调简单性而不是速度。对于一些应用程序来说，今天的计算机只要使用简单的算法就够了。
或者注重一般性。例如，Unix程序通常使用静态的表格和固定大小的字符串，这导致了不可改变的限制； 用动态分配来代替。确认你的程序处理了输入文件为空和其它滑稽的情况。为增加扩展性而增加一种 程序语言并且用那种语言完成程序的一个部分。
或者把程序的一部分修改成独立的库。或者用一个简单的废物收集器而不是在释放内存的时候精确地进行跟踪， 或者使用诸如obstacks这样的新的GNU工具。
接受他人的奉献
如果其他人发给你一段添加到你正在编写程序中的代码，我们需要准许使用它的法律文书 --我们将需要从你那里取得同样的法律文书。程序的每个重要的贡献者都必须签署 某种法律文书以使得我们可以给程序一个清晰的标题。仅有主要作者是不够的。
所以，在把来自于他人的任何共享添加到程序中之前，告诉我们以便我们可以做出安排 以获取文书。在你实际地使用贡献之前，请等待直到我们告诉你我们已经收到了签署的文书。
这即适用于你发行程序之前也适用于发行之后。如果你收到了一个修正bug的补丁，并且 它们做了主要的修改，我们就需要为他提供法律文书。
你不需要为这里或者那里的少数几行修改提供文书，因为对于达到版权目的没有意义。 还有，如果你从建议中获得的仅仅是一些想法，而不是你实际上使用的代码，你也不需要文书。 例如，如果你写了一个程序的不同解决方案，你并不需要获得许可文书。
我知道这是十分麻烦的；它对我们来说也十分麻烦。但如果你不等待，你就可能误入歧途， 如果这个贡献者的雇主不肯签署弃权声明怎么办？你可能不得不再次把代码剔除出来！
最糟糕的情况是如果你忘记告诉我们其它的贡献者，我们可能会因此而窘迫地出现在法庭上。 修改日志（Change Logs）
为每个目录维护一个修改日志，以记述对这个目录下源文件的修改。这样做的目的是使得 在将来寻找bug的人可以指导大致是那些修改导致了错误。通常，一个新的bug可以在最近进行 的修改中被找到。更重要的事，修改日志有助于消除程序的不同部分之间在概念上的不一致性； 它们可以告诉我们概念冲突产生的历史。
使用Emacs命令M-x add-change在修改日之中创建一个新的条目。一个条目应该 包含一个星号、被修改的文件的名称以及被扩在括号内的、被修改了的函数、变量或者任何东西。 括号之后是冒号和对你对函数或变量的修改的说明。
用空行把无关的条目分隔开。如果两个条目反映了同一个修改，因而它们一同工作，那就不要 在它们之间使用空行。如果后续的条目针对的是相同的文件，那么你可以忽略文件名的星号。
下面是一些例子：
* register.el (insert-register): Return nil.
(jump-to-register): Likewise.
* sort.el (sort-subr): Return nil.
* tex-mode.el (tex-bibtex-file, tex-file, tex-region):
Restart the tex shell if process is gone or stopped.
(tex-shell-running): New function.
* expr.c (store_one_arg): Round size up for move_block_to_reg.
(expand_call): Round up when emitting USE insns.
* stmt.c (assign_parms): Round size up for move_block_from_reg.
在这里没有必要叙述修改的完整目录和它们是如何协同工作的。把这些说明作为注释放到 代码中更好一些。这就是说为什么只要给出“New function”就够了；在源代码中，与函数 放在一起的注释说明了它是做什么的。
然而，有时为一大堆修改写上一行文字以描述它们的整体目的是有用的。
在概念上，你可以把修改日志看作解释原始版本与当前版本的不同的“undo列表”。 人们可以阅读当前的版本；他们不需要修改日志告诉他们其中有什么。他们从修改日之中 得到的是关于早期版本的不同的清晰解释。
在你以简单的方式修改函数的调用顺序，并且你修改了所有对函数的调用时，不必为所有 的调用创建单独的条目。只要在被调用的函数的条目中写“All callers changed.”即可。
在你仅仅修改了注释或者文档字符串的时候，为该文件写一个条目，而不必提到函数， 就足够了。只要写"Doc fix."。不必为文档文件维护修改日志。这是因为文档不那么容易 受到难以修正的错误的影响。文档不是由那些必须以精确地工程方式相互作用的部分组成的； 要修改一个错误，你不需要知道这个错误传播的历史。
与其它实现的兼容性
作为一个特例，对于GNU中的工具程序和库，它们应该和Berkeley Unix相应的部分向上兼容， 如果标准C定义了它们的行为，那它们应该和标准C向上兼容，如果POSIX规范定义了它们的行为， 那它们也应该与POSIX规范向上兼容。
当这些标准发生冲突的时候，为每个标准提供兼容模式是有用的。
标准C和POSIX禁止进行任何形式的扩展。自由地进行你的扩展，并且把选项 `--ansi'或`--
compatible'包括进来以关闭你的扩展。 但是如果扩展很可能导致任何实际程序或者脚本的崩溃，那么它可能实际上不是向上兼容的。 尝试一下重新定义它的界面。
当一个特征仅仅被用户（而不会被程序或者命令文件）所使用的时候，并且在Unix中它完成得 并不好，请自由地用完全不同并且更好的方式代替它。（例如，用Emacs代替vi。）但同时提供兼容 模式仍然是很好的。（现在有自由的vi实现，所以我们提供了它。）
欢迎提供Berkeley Unix没有提供的有用功能。Unix中没有的附加功能可能是有用的，但我们 优先复制那些Unix已经有的功能。
Makefile惯例
本章叙述为GNU程序书写Makefile的惯例。
Makefile的通用惯例
每个Makefile都应该包含这一行：
SHELL = /bin/sh
以避免那些由从环境中继承SHELL变量的系统带来的麻烦。 （GNU make永远不会出现这个问题。）
不要假定`.'出现在用于寻找可执行的命令的路径中。当你需要在make期间运行作为你的 包的一部分的程序时，如果程序是作为make的一部分而创建的，请确保它使用了`./'，或者 如果文件是不会被改变的源代码的一部分，请确保它使用了`$(srcdir)/'。
如果运行`configure'时使用了选项`--srcdir'，那么`./'与 `$(srcdir)/'之间的区别就十分重要。一下形式的规则：
foo.1 : foo.man sedscript
sed -e sedscript foo.man > foo.1
将在当前目录不是源代码目录的情况下导致错误，这是因为`foo.man'和`sedscript' 不在当前目录中。
在使用GNU make的时候，由于不论源文件在那里，`make'的自动变量`$<' 都将表示它，所以在只存在一个依赖文件的情况下，依靠`VPATH'来寻找源文件仍然是可行的。 （许多版本的make只在隐含规则中设置`$<'。）如下的makefile目标：
foo.o : bar.c
$(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
将被如下目标所替代：
foo.o : bar.c
$(CC) $(CFLAGS) $< -o $@
以便使`VPATH'能够正确地工作。当目标含有多的依赖文件时，显式地使用`$(srcdir)' 让规则正常工作的最简单办法。例如，上述为`foo.1'而提供的目标最好被写作：
foo.1 : foo.man sedscript
sed -s $(srcdir)/sedscript $(srcdir)/foo.man > foo.1
Makefile中的工具
书写能够在sh，而不是在csh，中运行的Makefile命令（以及任何shell脚本，例如 configure）。不要使用任何ksh或者bash特殊的功能。
为创建和安装而提供的configure脚本和Makefile规则不要直接使用任何工具，除了以下的几个之外：
cat cmp cp echo egrep expr grep
ln mkdir mv pwd rm rmdir sed test touch
坚持使用这些程序通常支持的选项。例如，因为许多系统不支持`mkdir -p'，尽管它可能有些方便， 但不要使用它。
为创建和安装而提供的Makefile规则还可以使用编译器和相关的程序，但应该通过make变量以便 用户对它们进行替换。下面是一些我们所说的相关的程序：
ar bison cc flex install ld lex
make makeinfo ranlib texi2dvi yacc
在你使用ranlib的时候，你应该测试它是否存在，并且仅仅在它存在的情况下运行它，以使得发布 版本在那些没有ranlib的系统中也能够工作。
如果你使用了符号连接，你应该为没有符号连接的系统实现一个替代手段。
你可以在只打算用于特定系统的Makefile的部分（或者脚本）中使用你能够确认在那些系统上存在的工具。
为用户提供的标准目标
所有的GNU程序应该在它们的Makefile中含有下列目标：
`all'
编译整个程序。它应该是缺省目标。这个目标不需要重新创建任何文档文件；Info文件被包含在发布版本中， 同时，只有在用户明确地要求创建DVI文件的时候才创建DVI文件。 `install'
编译程序并且把可执行文件、库文件等文件复制到它们在实际应用中应该存在的位置。如果存在一个可以 检测程序是否被正确地安装了的简单测试，本目标将首先运行这个测试。
如果文件的安装目录不存在，该命令将创建这样的目录。它们包括由变量prefix和
exec_prefix的值指明的目录，以及需要的所有目录。完成该任务的一种方式是按照后面所说明的 方式通过目标installdirs来完成。
在任何用户安装man手册的命令之前使用`-'，以使得make忽略所有的错误。 错误将在那些没有安装Unix man手册文档系统的系统中出现。
安装Info文件的方式是用$(INSTALL_DATA)把它们复制到`$(infodir)'中。 （参见为指明命令而提供的变量），并且如果有程序install-info存在， 那么就运行它。install-info是一个脚本，它编辑Info `dir'文件以把给定的Info文件添加 或者更新目录项的脚本；它将是Texinfo包的一个部分。下面是用于安装一个Info文件一个简单规则：
$(infodir)/https://www.doczj.com/doc/dc3376402.html,: https://www.doczj.com/doc/dc3376402.html,
# There may be a newer info file in . than in srcdir.
-if test -f https://www.doczj.com/doc/dc3376402.html,; then d=.; \
else d=$(srcdir); fi; \
$(INSTALL_DATA) $$d/https://www.doczj.com/doc/dc3376402.html, $@; \
# Run install-info only if it exists.
# Use `if' instead of just prepending `-' to the
# line so we notice real errors from install-info.
# We use `$(SHELL) -c' because some shells do not
# fail gracefully when there is an unknown command.
if $(SHELL) -c 'install-info --version' \
>/dev/null 2>&1; then \
install-info --infodir=$(infodir) $$d/https://www.doczj.com/doc/dc3376402.html,; \
else true; fi
`uninstall'
删除所有由`install'目标创建的所有安装的文件（但不包括那些由诸如`make all' 之类的目标创建的，没有被安装的文件）。
`clean'
从当前目录中删除所有在创建程序过程中创建的文件。不要删除那些纪录配置情况的文
件。有些文件可能是在创建 过程中创建的，但因为它们是和发布版本一起发布的，通常不是在创建过程中创建的，这样的文件也需要保留下来。
如果`.dvi'文件不是发布版本的一部分，就删除它们。
`distclean'
从当前目录中删除所有在程序的配置和创建过程中创建的文件。如果你解包源代码并且在没有添加任何其它文件的 情况下创建程序，`make distclean'将仅仅保留那些出现在发布版本中的文件。
`mostlyclean'
类似于`clean'，可能不会删除少数人们通常不希望重新编译的文件。例如，GCC的
`mostlyclean'目标不会删除`libgcc.a'，这是因为很少需要重新编译并且重新编译将花费大量的时间。
`realclean'
从当前目录中删除所有可以由Makefile重新创建的文件。这通常包括所有由distclean删除的文件， 以及：由Bison生成的C源文件、标记表（tags tables）、Info文件等等。
然而有一个例外：即使`configure'可以通过使用Makefile中的规则重新创建，`make realclean' 也不会删除`configure'。更一般地说，`make realclean'将不会删除为了运行`configure' 而存在的任何东西，并且随后开始创建程序。
`TAGS'
为本程序更新标记表（tags table）。
`info'
生成所有需要的Info文件。书写该规则的最佳方式是：
info: https://www.doczj.com/doc/dc3376402.html,
https://www.doczj.com/doc/dc3376402.html,: foo.texi chap1.texi chap2.texi
$(MAKEINFO) $(srcdir)/foo.texi
你必须在Makefile中定义变量MAKEINFO。它应该运行程序makeinfo，该程序是Texinfo发布 版本的一部分。
`dvi'
Generate DVI files for all TeXinfo documentation. For example:
dvi: foo.dvi
foo.dvi: foo.texi chap1.texi chap2.texi
$(TEXI2DVI) $(srcdir)/foo.texi
你必须在Makefile中定义变量TEXI2DVI。它应该运行程序texi2dvi，该程序也是Texinfo 发布版本的一部分。作为另一个选择，只要写依赖文件并且允许GNU Make提供这个命令就行了。
`dist'
为本程序创建一个发布版本tar文件。该tar文件将被设置以使得在tar文件中的文件名以子目录名开头，这个子目录名 是包用于发布的名字。这个名字可以包含版本号。
例如，GCC版本1.40的发布tar文件将被解包到名为`gcc-1.40'的子目录中。
完成该任务的最简单方式是以适当的名称创建一个子目录，使用ln或者cp把正确的文件 安装到该目录中，而后tar这个子目录。
目标dist应该显式地依赖于发布版本中所有的非源文件，以确保它们在发布版本中都不是过时的。参见 制作发布包
`check'
（如果有的话）执行自检测。用户必须在运行测试之前，但不必在安装程序之前创建程
序；你应该写下自检测以便 它们在程序创建之后而没有被安装之前进行工作。
对于那些适用于以下的目标的程序，建议你按照常用的名字提供它们。
installcheck
（如果有的话）执行安装监测。用户必须在运行该检测之前创建并且安装程序。你不应该假定`$(bindir)' 出现在搜索路径中。
installdirs
添加一个名为`installdirs'的目标，以便创建安装文件的目录和它们的父目录。 有一个称为`mkinstalldirs'的脚本可以为此提供便利；在Texinfo包中可以找到它。你可以使用象下面那样的规则：
# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
$(srcdir)/mkinstalldirs $(bindir) $(datadir) \
$(libdir) $(infodir) \
$(mandir)
为指明命令而提供的变量
Makefile应该提供变量以覆盖某些命令、选项等等。
特别地，你应该通过变量来运行大部分工具程序。因此，如果你使用了Bison，就定义一个缺省值是通过`BISON = bison' 来设定的变量BISON，并且在你需要使用Bison的所有地方通过$(BISON)引用它。
在这种方式下，文件管理工具：ln、rm、mv等等并不需要通过变量引用，这是因为 用户不需要用其它程序来替代它们。
每个程序名变量都应该有一个对应的变量以便为程序提供选项。把`FLAGS'附加到程序名变量名的后面就是 选项变量名--例如，BISONFLAGS。（名字CFLAGS是这项规则的一个例外，但因为它是标准的而保留了它。） 在任何运行预处理器的编译命令中使用CPPFLAGS，在任何进行连接的编译命令和任何对ld的直接使用中 使用LDFLAGS。
如果存在一些为了正确地编译某些文件而必须使用的C编译器选项，不要把它们包括在CFLAGS 中。用户希望 能够自由地指明CFLAGS的值。替代的方式是：通过在编译命令行中显式地给出这些必要的选项或者通过定义一条隐含 规则，从而以独立于CFLAGS的方式把选项传递给C编译器。
CFLAGS = -g
ALL_CFLAGS = -I. $(CFLAGS)
.c.o:
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
把选项`-g'包括在CFLAGS中，因为它对于正确的编译来说并不是必要的。 你可以认为它仅仅是关于缺省值的一个建议。如果包被设置成在缺省的状态下由GCC编译，那么你可能还需要把`-O' 包括在CFLAGS的缺省值之中。
把CFLAGS放在编译命令行的最后，就是在其它包含了编译选项的变量之后，以便于用户使用CFLAGS 来覆盖其它的选项。
每个Makefile都应该定义变量INSTALL，它是把一个文件安装到系统中的基本命令。
每个Makefile还应该定义变量INSTALL_PROGRAM和INSTALL_DATA。（两者的缺省值都应该是 $(INSTALL)。）而后，Makefile应该使用这些变量作为实际安装的命令，分别用于安装可执行文件和不可执行的文件。 按照下面的方式使用这些变量：
$(INSTALL_PROGRAM) foo $(bindir)/foo
$(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a
总是把文件名，而不是目录名，作为安装命令的第二个参数。为每个需要安装的文件使用独立的命令。
为安装目录而提供的变量
安装目录总是应该通过变量来命名，以易于把包安装在其它非标准的位置。这些变量的标准名字是：
`prefix'
用于构造下列变量的缺省值的前缀。prefix的缺省值应该是`/usr/local'（至少现在是它）。 `exec_prefix'
用于构造下列某些变量的缺省值的前缀。exec_prefix的缺省值应该是$(prefix)。
一般来说，$(exec_prefix)指的是用于储存与机器有关的文件（比如说可执行文件和子程序库）的目录， 而$(prefix)则被直接用于其它目录。
`bindir'
用于储存用户可以运行的可执行程序的目录。一般来说应该是`/usr/local/bin'，但应该被写作 `$(exec_prefix)/bin'。
`libdir'
用于安装由程序运行，而不是由用户运行的可执行文件的目录。Object文件和object代码库也应该被储存在这个目录。 提供该目录的意图是为了储存适用于特殊机器结构，但又不必出现在命令路径中的文件。libdir的值通常是 `/usr/local/lib'，但应该被写作`$(exec_prefix)/ lib'。
`datadir'
用于安装程序在运行时需要访问的只读数据文件的目录。该目录用于储存与使用的机器独立的文件。它通常是 `/usr/local/lib'，但应该被写作`$(prefix)/lib'。
`statedir'
用于安装程序在运行时需要修改的数据文件的目录。这些文件应该与使用的机器类型独立，并且应该可以在网络 安装的情况下载不同的机器之间共享。它通常应该是`/usr/local/
lib'，但应该被写作`$(prefix)/lib'。
`includedir'
用于储存将被用户程序以C预处理指令`#include'引入的头文件的目录。它通常应该是 `/usr/ local/include'，但应该被写作`$(prefix)/include'。
除了GCC以外，大部分编译器并不在`/usr/local/include'中寻找头文件。所以以这种方式安装头文件仅仅 适用于GCC。但有些库被设计成与其它编译器共同工作。它们应该在两个地方安装它们的头文件，一个由includedir 给出，另一个由oldincludedir给出。
`oldincludedir'
为除了GCC之外的其它编译器安装头文件的目录。这通常应该是`/usr/include'。
Makefile命令应该检测oldincludedir的值是否为空。如果为空，Makefile命令就不应该试图使用 oldincludedir；Makefile命令应该放弃对头文件的第二个安装。
除非头文件来自于同一个包，包不应该替换已经存在的头文件。因此，如果你的Foo包提供了一个头文件`foo.h'， 并且如果它没有出现在oldincludedir目录中或者oldincludedir目录中的`foo.h'也是来自 与Foo包，那么Foo包就应该把头文件安装到oldincludedir中。
为了判定`foo.h'是否来自于Foo包，可把一个特殊的字符串作为注释的一部分放在文件中，而后用grep搜索这个 字符串。
`mandir'
（如果存在）本包安装man手册的目录。它应该包含对应于正确的手册部分的后缀-- 对于一个工具来说通常是`1'。它一般是`/usr/local/man/man1'，但你 应该把它写成：`$(prefix)/
man/man1'。
`man1dir'
安装man手册第一部分的目录。
`man2dir'
安装man手册第二部分的目录。
`...'
如果包需要把man手册安装到手册系统的多个部分，就用这些名字来代替`mandir'。
不要把man手册作为GNU软件的主要文档。用Texinfo书写文档来代替它。Man手册只是因为 人们在Unix，它只是一个次要的应用程序，上运行GNU软件才存在的。
`manext'
作为需要安装的man手册的文件的扩展名。它应该是一个点加上一个适当的数字；通常它应该是：`.1'。
`man1ext'
将被安装到man手册第一部分的文件的扩展名。
`man2ext'
将被安装到man手册第二部分的文件的扩展名。
`...'
如果包需要把man手册安装到手册系统的多个部分，就用这些名字代替`manext'。
`infodir'
为本包安装Info文件的目录。在缺省状态下，它应该是`/usr/local/info'，当它应该被写成 ` $(prefix)/info'。
`srcdir'
用于编译源代码的目录。该变量的值通常是由configureshell脚本插入的。
例如：
# Common prefix for installation directories.
# NOTE: This directory must exist when you start the install.
prefix = /usr/local
exec_prefix = $(prefix)
# Where to put the executable for the command `gcc'.
bindir = $(exec_prefix)/bin
# Where to put the directories used by the compiler.
libdir = $(exec_prefix)/lib
# Where to put the Info files.
infodir = $(prefix)/info
如果你的程序在一个标准的用户给定的目录中安装了大量的文件，可能把为程序特别提供的文件存放到 子目录中会有用一些。如果你这样做了，你应该改写install规则以创建这些子目录。
不要指望用户会把子目录名包括在上面列出的变量的值中。为安装目录提供统一的变量名集合的意图是 使得用户可以为一些不同的GNU包指明完全相同的值。为了使这些规定变得有用，所有的包都必须这样设计 以便在用户这样做的时候它们将能够有效地工作。
配置是如何进行的
每个GNU发布版本都应该还有一个名为configure的shell脚本。你需要把 你希望在那种机器和系统上编译程序作为参数告诉这个脚本。
脚本configure必须记录配置信息以便它们可以影响编译工作。
这样做的一种方式是把一个诸如`config.h'的标准名字和为选定的系统匹配的 正确配置文件连接起来。如果你使用了这种技术，发布版本中就不应该包含名为 `config.h'的文件。这样做是为了保证用户在配置程序之前不能够创建它。
configure可以做的另一件事情是编辑Makefile。如果你这样做了，发布 版本中就不能包含名为
`Makefile'的文件。用`Makefile.in'来代替 它，并且`Makefile.in'为configure的编辑提供了输入。同样， 这样做是为了保证用户在配置程序之前不能创建它。
如果configure生成了`Makefile'，那么`Makefile' 就应该包含一个名为`Makefile'的目标，这个目标将重新运行configure 以与获取上一次配置相同的配置信息。由configure读取的文件，应该作为 依赖性文件而在`Makefile'中被列出。
所有由configure脚本生成的文件在它们的第一行都应该包含一条注释 以说明它们是由configure自动生成的。这样做是为了确保用户不会试图手工 修改它们。
脚本configure应该写入一个名为`config.status'的文件，该文件 说明了在程序的最后一次配置中给出了那些配置选项。该文件应该是一个shell脚本，如果运行它， 将重新生成相同的配置。
脚本configure应该接受形式为`--srcdir=dirname' 的选项以指明在那个目录中可以找到源代码（如果源代码不在当前目录中）。这使得可以在 实际代码目录没有被修改的情况下，在分离的中创建程序成为可能。
如果用户没有给出`--srcdir'，那么configure将在`.' 和`..'中寻找源文件。如果它在上述地方之一发现源文件，它就应该在那里使用它们。 否则，它应该报告它没有找到源文件，并且以非零状态退出。
通常，支持`--srcdir'的简单方式是通过编辑被放到Makefile中的一个 VPATH的定义。可能有一些规则需要被显式地引用以指明源代码目录。为了达到这个 目的，configure可以把一个名为srcdir的变量添加到Makefile中， 该变量的值就是给定的目录。
脚本configure还应该提供一个可以指明程序是究竟为那种系统而创建的选项。 这个选项看起来应该象：
cpu-company-system
例如，一个Sun 3可能是`m68k-sun-sunos4.1'。
脚本configure需要能够解释所有对机器的似是而非的描述方式。因此， `sun3-sunos4.1'应该是有效的别名。`sun3-bsd4.2'也是如此， 因为SunOS是基于BSD的并且没有其它的BSD系统被用于Sun。对于许多程序来说， 因为Ultrix和BSD之间的区别很少被注意到，所以`vax-dec-ultrix'将是 `vax-dec-bsd'的一个别名。但少数程序可能需要区分它们。
这里有一个被称为`config.sub'的shell脚本，你可以把它作为一个子程序使用 以检查系统类型并且对别名进行规范化。
允许出现其它选项以指明关于机器的软件或者硬件的更多细节：
`--with-package'
包package将被安装，所以把本包配置成与package一同工作。
package可能的取值包括`x'、`gnu-as'（或者 `gas'）、`gnu-ld'、`gnu-libc'和`gdb'。
`--nfp'
目标机器没有浮点数处理器。
`--gas'
目标机器的汇编器是GAS，GNU的汇编器。该选项已经过时了；用`--with-gnu-as'来代替。 `--x'
目标机器已经安装了X Window系统。该选项已经过时了；用`--with-x' instead来代替。
所有的configure脚本都应该接受所有这些“细节”选项，而不论它们是否会对手头的特定 包产生影响。特别地，它们应该接受任何以`--with-'开头的选项。这样做是因为这使得用户 可以用同一组选项配置整个GNU源代码树。
作为编译的一部分的包可能支持交叉编译（cross-compliation）。在这种情况下，程序的主机和目标机器 可能是不同的。configure通常把指明的系统类型当作主机和目标机器，因此将创建与运行它 的机器类型相同的机器上运行的程序。
创建交叉编译器（cross-compiler）、交叉汇编器（cross-assembler）、或者你自己的程序，通过在运行 configure时给出选项`--host=hosttype'来完成。它在不影响 目标机器的情况下指明了主机名。hosttype的语法与前面所说的一样。
因为为互操作（cross-operation）配置整个操作系统是一件没有意义的事，对互操作来说没有意义的程序 就不必接受选项`--host'。
有些程序自动地配置它们自己。如果你的程序被设置成这样，你的configure脚本只需要简单地 忽略它的大部分参数就行了。
使用C以外的语言
使用C以外的语言就好像使用非标准特征：它将为用户带来麻烦。即使GCC能够支持其它语言，
用户也可能因为不得不安装其它语言的编译器以创建你的程序而感到不便。所以请使用C语言。
这条规则有三个例外：
● 如果有些程序包括了特殊语言的解释器，那么就可以使用这种语言。
因此，GNU Emacs包含用Emacs Lisp写的代码就没有问题，因为GNU Emacs包含了Lisp解释器。
● 如果一个工具就是为了某种语言而编写的，那么就可以使用那种语言。
这是因为那些需要创建这个工具的人必然是那些已经安装了其它语言的人。
● 如果一个应用程序没有被极端广泛地关注，那么应用程序的安装不太方面就不是特别重
要。
格式化你的源代码
把作为C函数的开头的左花括号放到第零列是十分重要的，并且避免把任何其它的左花括号、左括号 或者左方括号放到第零列。有些工具通过寻找在第零列的左花括号来寻找C函数的起点。这些工具将不能 处理那些不按照这种方式排版的代码。
对于函数定义来说，把函数名的起始字符放到第零列也同样重要。这帮助任何寻找函数定义，并且 可能有助于帮助某些工具识别它们。因此，正确的格式应该是：
static char *
concat (s1, s2) /* Name starts in column zero here */
char *s1, *s2;
{ /* Open brace in column zero here */
...
}
或者，如果你希望使用标准C，定义的格式是：
static char *
concat (char *s1, char *s2)
{
...
}
在标准C中，如果参数不能够被美观地放在一行中，按照下面的方式把它们分开：
int
lots_of_args (int an_integer, long a_long, short a_short,
double a_double, float a_float)
...
对于函数体，我们希望它按照如下方式排版：
if (x < foo (y, z))
haha = bar[4] + 5;
else
{
while (z)
{
haha += foo (z, z);
z--;
}
return ++x + bar ();
}
我们发现如果在左括号之前以及逗号之后添加空格将使程序更加容易阅读。尤其是在 逗号之后添加空格。
当我们把一个表达式分成多行的时候，在操作符之前而不是之后分割。下面是正确的方式：
if (foo_this_is_long && bar > win (x, y, z)
&& remaining_condition)
尽力避免让两个不同优先级的操作符出现在相同的对齐方式中。例如，不要象下面那样写： mode = (inmode[j] == VOIDmode
|| GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])
? outmode[j] : inmode[j]);
应该附加额外的括号以使得文本缩进可以表示出这种嵌套：
mode = ((inmode[j] == VOIDmode
|| (GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])))
? outmode[j] : inmode[j]);
插入额外的括号以使得Emacs可以正确地对齐它们。例如，如果你手工完成缩进工作， 那么它们看起来不错，但Emacs将把它们混在一起：
v = rup->ru_https://www.doczj.com/doc/dc3376402.html,_sec*1000 + rup->ru_https://www.doczj.com/doc/dc3376402.html,_usec/1000
+ rup->ru_https://www.doczj.com/doc/dc3376402.html,_sec*1000 + rup->ru_https://www.doczj.com/doc/dc3376402.html,_usec/1000;
但添加一组括号解决了这个问题：
v = (rup->ru_https://www.doczj.com/doc/dc3376402.html,_sec*1000 + rup->ru_https://www.doczj.com/doc/dc3376402.html,_usec/1000
+ rup->ru_https://www.doczj.com/doc/dc3376402.html,_sec*1000 + rup->ru_https://www.doczj.com/doc/dc3376402.html,_usec/1000);
按照如下方式排版do-while语句：
do
{
a = foo (a);
}
while (a > 0);
请按照逻辑关系（而不是在函数中）使用走纸字符（control-L）以把程序划分成页。 页有多长并不重要，因为它们不必被放在一个打印的页中。走纸字符应该单独地出现在一行中。
为你的工作写注释
每个程序都应该以一段简短地、说明其功能的注释开头。 例如：`fmt - filter for simple filling of text'.
请为每个函数书写注释以说明函数做了些什么，需要哪些种类的参数，参数可能值的含义 以及用途。如果按照常见的方式使用C语言类型，就没有必要逐字重写C参数声明的含义。如果 它使用了任何非标准的东西（例如，一个类型为char *的参数实际上给出了 一个字符串的第二个字符，而不是第一个字符，的地址），或者是可能导致函数不能工作的 任何可能的值（例如，不能保证正确处理一个包含了新行的字符串），请确认对它们进行了说明。
如果存在重要的返回值，也需要对其进行解释。
请在你的注释之后添加两个空格，以便Emacs句子命名进行处理。还有，请书写完整的句子 并且使头一个单词以大写字母开头。如果小写字母组成的标识符出现在句子的开头，不要把它 变成大写的！修改拼写就构成了不同的标识符。如果你不希望句子以小写字母开头，可以写下 不同的句子（例如，“The identifier lower-case is ...”）。
如果你使用参数名来说明参数值，关于函数的注释就会更清晰。变量名本身应该是小写的， 但在你说到它的值而不是变量本身的时候就使用大写字母。因此，“the inode number node_num”
比“an inode”要好。
通常在函数之前的注释中没有必要重新提到函数的名字，因为读者可以自己看到它。 一种可能的例外是：注释太长了，以至于函数本身被挤出了屏幕底端之外。
对于每个静态变量，也象下面那样应该提供注释：
/* Nonzero means truncate lines in the display;
zero means continue them. */
int truncate_lines;
除非`#endif'是一个没有嵌套而且很短（只有几行）的条件，每个 `#endif'都应该含有一个注释。注释应该说明它所结束的条件，包括它的含义。 `#else'应该含有一个说明条件与随后代码的含义的注释。例如：
#ifdef foo
...
#else /* not foo */
...
#endif /* not foo */
但相反，按照如下方式为`#ifndef'写注释：
#ifndef foo
...
#else /* foo */
...
#endif /* foo */
清晰地使用C语言成分
请显式地声明函数的所有参数。不要因为它们是整数就忽略它们。
对外部函数以即将随后出现在源文件中的函数的声明应该出现在靠近文件开头 （在第一个函数定义之前的某个地方）的同一个地方。或者其它的声明应该出现在头文件中。 不要在函数中放置外部声明。
在过去一种常见的做法是在同一个函数中把同一个局部变量（比如说名为tem的变量 反复地用于不同的值。但现在，更好的方式是为每个不同的目的分别定义局部变量，并且给它们以更 有意义的名字。这不仅仅是程序更容易理解，它还会被好的编译程序所优化。你还可以把对局部变量 的声明放到包含对它的使用的最小范围中。这可以把程序变得更清晰。
不要使用可以遮蔽全局标识符的局部变量和参数。
不要在跨越了行的声明中声明多个变量。在每一行中都以一个新的声明开头。例如，不应该： int foo,
bar;
而应该：
int foo, bar;
或者：
int foo;
int bar;
（如果它们是全局变量，在它们之中的每一个之前都应该添加一条注释。）
当你在一个if语句中嵌套了另一个if-else语句，总是用花括号把if-else括起来。因此，不要写： if (foo)
if (bar)
win ();
else
lose ();
而总是要写：
if (foo)
{
if (bar)
win ();
else
lose ();
}
如果你在else语句中嵌套了一个if语句，即可以像下面那样写else if：
if (foo)
...
else if (bar)
类推技术标准 说一说汉字编码技术标准中的类推简化 1.引言 随着《通用规范汉字表》发布，一场宣传已经展开，随之也有一些争论出现。争论中一个重要问题，或焦点性问题：是应该实行有限制的类推，还是无限制的类推？这个问题不仅仅是语言文字学里的理论性争论，它密切关联着电脑的实际使用。实际上，此次的《字表》已经继续类推出一批电脑汉字编码中没有的汉字，即新造了一批电脑外字，160余个。这将带来一系列不良后果。由于汉字编码技术标准是新事物，其产生历史不过仅仅三十多年，又具有较强的技术性，领导机构管理者、广大公众对其了解较少。本文将对此做简要但也是较为完整的介绍。 2.文字编码技术标准的产生 世界上最早的文字计算机编码技术标准是ISO646—1973（约40年前）。这是一个关于拉丁字母文字的国际编码标准。编码的字符包括拉丁字母、数码以及标点等其他符号，总计94个可见图形字符，及一些起控制作用符号共计128个，占用7位二进制位。此标准的前身是美国国内的编码技术标准，1960年代的版本中只有大写字母，没有小写字母；后来补充大写字母，又被称为ASCII字符集。这个ISO646或者说是ASCII字符集，成为世界信息技术界最重要的技术标准。它决定了拉丁字母文字信息的表达、存储、加工、以及传输，保障了一大批西方文字、科技语言、程序语言在全球范围的电子化流通。
这个信息化的、电子化的字符集，取代了历史久远，在工业时代、机械化时代成功广泛应用的，以纸质印刷形式为主的‘字母表’，成为文字规范的新形式、新手段。以此为基础的英文信息处理电脑化的成功，极大地刺激了、推动了世界各国文字处理技术的电脑化浪潮。3.中国汉字编码技术标准的初期，简化字无限制类推阶段 中国的第一个汉字计算机编码技术国家标准是GB2312—1980（刚刚33年）。这是在国际性文字处理电脑化浪潮初起时期的一项开创性工作。主持者是一位比王选还年轻十来岁的青年技术工作者。该标准的语言文字学依据，自然靠向语文学家请教，遵循了当时语文界的主流认识。它不包含任何一个繁体字。这个标准并不完美，甚至还有错字出现。但正是这个标准的适时推出，保障了中国汉字电脑化浪潮有了一个可用的基础，对汉字的电脑化迅猛但有序的发展作出了重大贡献，曾经被授予科技重奖。这个国家标准GB2312—1980，收字仅仅6763个，不包含任何繁体字。标准实施过程中，同时设计了五个称为‘辅助字符集’的编码标准，总计约四万余汉字，以实现对汉字文献的完整表达。其中，第二、第四辅助集，是经过无限制类推简化得到的，不包含任何繁体字。而第一、第三、第五辅助集，是与前者并立的繁体汉字系统集，其中不包含任何简化字。这种思路，自然来自当时语文界的主流认识。其政策依据是《简化字总表》的说明（1964年5月）。在类推简化字表的说明中指出：“汉字总数很多，这个表不必尽列。”表中未列出的字，在实际使用中需要用到时，“凡用第二表的简化字或简化偏旁作为偏旁的，一般应该同样简化”。
南 联食品二期项目需求规格说明书 1 / 19 1. 业务模型描述1.1. 业务场景编码标准化 1.1.1. 基础档案编码是企业信息化体系建设中的基础性工作，基础档案编码的一致性、完整性、易用性将直接影响ERP系统的信息交互与数据共享能力。南联公司现在各部门对各种基础档案的叫法或者命名各不相同。为了实现数据的无缝集成及满足未来南联公司发展的需要，有必要在公司范围内制定统一的数据规范，夯实公司统一管控的基础。 1.1.1.1. 基本准则1. 统一规划，集中管理，组织保障按照编码的使用范围，区分不同的管理层次。按照公司编码使用范围，由南联公司指定部门专人负责编码规则的规划、制定、备案；组织开展编码工作；对完成的编码进行校验、更新及下发使用。为保证编码工作的顺利实施，南联公司必须指派专人负责此项工作。在项目持续期间协助项目成员与南联公司各对口业务部门进行工作协调；在项目结束后负责
南联公司全部编码的管理，包括编码规则的备案、维护（新增、更新等），并负责督导编码规则的推广与应用。建议成立编码委员会，负责新编码的审定、变更等决策工作。人员由编码涉及的主要业务板块人员组成，如分管领导、总监、关键用户、骨干业务人员等。务必包含对基层具体业务熟悉的骨干业务人员。对于确定推广应用的编码规则，根据应用范围，建议以编码委员会以及对应的管理部门下达文件的方式推广。2. 参照国际、国家、行业标准中有关分类标准体系，考虑企业现有的编码，制定编码体系有国际、国家、行业标准的，以国际、国家、行业标准为基础，借鉴行业其他成功案例，结合考虑实际情况，制定适用于南联公司的编码规范。若南联公司现有的编码规则成熟且能够第2页共19页 适用未来较长一段时期的发展趋势，则对现有编码进行系统梳理后可纳入到整体编码体系中。建议编码委员会制定专人，负责收集、整理更新不同的标准，为南联公司编码制定提供标准。3. 编码的基本原则唯一性尽管编码对象可能有不同的名称或不同的描述，但代码结构必须保证一个编码对象仅赋予一个代码，一个代码只反映一个编码对象。即：一个分类代码必须与指定的类目一一对应。可扩性代码结构必须能适应编码对象不断增加的需要，也就是说，必须为新的编码对象留有足够的备用码，从而使分类集可以进行必要的修订和补充。简短性在不影响代码系统的容量和可
编码定义 用预先规定的方法将文字、数字或其他对象编成数码，或将信息、数据转换成规定的电脉冲信号。编码在电子计算机、电视、遥控和通讯等方面广泛使用。 编码是根据一定的协议或格式把模拟信息转换成比特流的过程。 在计算机硬件中，编码（coding）是在一个主题或单元上为数据存储，管理和分析的目的而转换信息为编码值（典型地如数字）的过程。在软件中，编码意味着逻辑地使用一个特定的语言如C或C++来执行一个程序。在密码学中，编码是指在编码或密码中写的行为。 将数据转换为代码或编码字符，并能译为原数据形式。是计算机书写指令的过程，程序设计中的一部分。在地图自动制图中，按一定规则用数字与字母表示地图内容的过程，通过编码，使计算机能识别地图的各地理要素。 n位二进制数可以组合成2的n次方个不同的信息，给每个信息规定一个具体码组，这种过程也叫编码。数字系统中常用的编码有两类，一类是二进制编码，另一类是二—十进制编码。 为什么要进行汉字编码 汉字编码Chinese character encoding为汉字设计的一种便于输入计算机的代码。由于电子计算机现有的输入键盘与英文打字机键盘完全兼容。因而如何输入非拉丁字母的文字（包括汉字）便成了多年来人们研究的课题。汉字信息处理系统一般包括编码、输入、存储、编辑、输出和传输。编码是关键。不解决这个问题，汉字就不能进入计算机。中国人本来是用一只手执笔杆，一笔一画写字的，现在却要统统改为用两只手十个指头击键写字。键符越过笔画，代表部件写字，在键盘上使用编码检出汉字，就是用编码写字，键盘就成为我们的笔杆了。这种以检字来使用汉字，提高信息交换速度，对中华民族的汉字来说，这是几千年来前所未有的一次翻天覆地的大变革。回顾汉字发展的历史，从甲骨文、金文、大篆、小篆、隶书，到现代汉字，它的变革，都只是笔势上的变革，而没有牵涉到它的结构。而这一次，却牵涉到它的结构——把汉字拆分为部件。因此，这次变革，不仅给我国人民将带来巨大的好处，还将使蒙辱一百多年的、背上“落后”黑锅的汉字，重新展现它的光辉。 途径 汉字进入计算机的三种途径分别为：
企业信息化标准 QB/JF.12001-2007 编码规则 受控状态: 发放编号: 版号: A/0 2007-06-08发布2007-07-01实施
XXXXXX有限公司发布 XXXXXXXXX有限公司企业编码标准 QB/JF.12001-2007 公司组织机构编码规则 本标准参照了根据XXXXXXXXX有限公司对组织机构管理的需要，结合实际情况制定。 本标准起草部门：XXXXXXXXX有限公司信息系统部。 1主题内容与适用范围 本标准规定了XXXXXXXXX有限公司组织机构的分级、代码管理。 本标准适用于XXXXXXXXX有限公司组织的管理、登记、统计及会计核算等工作。 2术语 公司:具有独立法人资格或需要独立核算管理的分支机构或企业，可以定义为公司。 部门:有明确的职能范围和工作职责的组织。 3分类原则 本标准根据企业需要不设分类。 4编码方法 4.1本标准采用分级数字代码结构，共分五层，最长码为9位，第一层以一位阿拉伯数字表示,代表集团号；第二层以2位阿拉伯数字表示，代表集团部门，其中99表示分厂;第三层以两位阿拉伯数字表示, 表示集团部门下属机构或分厂的序号;第四层以两位阿拉伯数字表示，表示分厂下属部门;第五层以两位阿拉伯数字表示，表示分厂下属部门班组。其分类结构如下： XX XX X XX XX 第五层 第四层 第三层 第二层
4.2各层均留有适当空码，以备增加或调整时使用。 4.3第一、二、三、四、五层的分类不再细分时，其代码后不需补“0”。5组织机构代码表(例)
XXXXXXXXX 有限公司企业编码标准 QB/JF.12001-2007 员工代码编码规则 本标准参照了根据建发鞋楦公司对员工管理的需要，结合实际情况制定。 本标准起草单位：XXXXXXXXX 有限公司。 1主题内容与适用范围 本标准规定了XXXXXXXXX 有限公司员工的分类、代码及关键描述信息、岗位的分类。 本标准适用于XXXXXXXXX 有限公司员工的管理、工资核算、考勤、奖惩、登记、统计及会计核算等工作。 2术语 岗位 泛指职位，执行一定职务的位置。 职级 员工对应的工资等级,与员工岗位技能相关。 3分类原则 根据企业管理的需要，人员编码不按特定意义区分，所有的分类以属性方式加以描述。 4 岗位编码 4.1本标准采用等长3位数字代码结构，以3位阿拉伯数字表示，表示顺序号。其分类结构如下： 4.2 所有岗位代码均采用3位编码，必须保证编码的唯一性。 4.3 岗位代码表（例） XXX 第一层
QB ****公司企业标准 信息分类和编码 第3分册工程信息分类和编码 （初稿） 20XX-XX-XX 发布 20XX -XX -XX 发行 *****有限责任公司 发 布 ICS XXX 备案号XXX
目次 前言 (3) 引言 (4) 1范围 (5) 2规范性引用文件 (5) 3术语和定义 (5) 4分类原则和方法 (6) 4.1基本原则 (6) 4.2分类对象的层面划分 (6) 4.3工程信息分类 (7) 4.4工程信息整体框架 (8) 5编码方法 (9) 5.1基本原则 (9) 5.2码值 (9) 5.3代码组结构和层次 (10) 5.3.1交互定位码 (10) 5.3.2项目编码 (10) 5.3.3管理属性编码 (11) 5.3.4设计属性编码 (11) 5.3.5合同属性编码 (12) 5.3.6档案属性编码 (12) 5.3.7采购、财务、招标信息属性编码 (13) 5.3.8非项目信息编码 (13) 6分类与代码表 (14) 6.1非项目信息分类标识码(30301) (14) 6.2省电网公司及直属单位编码(30302) (14) 6.3工程项目建设管理单位代码(30303) (15) 6.4项目属性代码(30304) (18) 6.5综合指标(30305) (19) 6.6立项时间(30306) (20) 6.7批次项目标识码(30307) (21) 6.8信息属性码分类(30308) (21) 6.9项目阶段代码((30309) (22) 6.10工作分解代码(30310) (22) 6.11信息创建部门代码(30311) (23) 6.12设计资料分类代码(30314) (24) 6.13设计阶段代码(30315) (24) 6.14类目代码(30316) (25)
1．ASCII与Binary 我们日常接触到的文件分ASCII和Binary两种。ASCII是“美国信息交换标准编码”的英文字头缩写，可称之为“美标”。美标规定了用从0到127的128个数字来代表信息的规范编码，其中包括33个控制码，一个空格码，和94个形象码。形象码中包括了英文大小写字母，阿拉伯数字，标点符号等。我们平时阅读的英文电脑文本，就是以形象码的方式传递和存储的。美标是国际上大部分大小电脑的通用编码。 然而电脑中的一个字符大都是用一个八位数的二进制数字表示。这样每一字符便可能有256个不同的数值。由于美标只规定了128个编码，剩下的另外128个数码没有规范，各家用法不一。另外美标中的33个控制码，各厂家用法也不尽一致。这样我们在不同电脑间交换文件的时候，就有必要区分两类不同的文件。第一类文件中每一个字都是美标形象码或空格码。这类文件称为“美标文本文件”(ASCII Text Files)，或略为“文本文件”，通常可在不同电脑系统间直接交换。第二类文件，也就是含有控制码或非美标码的文件，通常不能在不同电脑系统间直接交换。这类文件有一个通称，叫“二进制文件”(Binary Files). 2．国标、区位、“准国标” “国标”是“中华人民共和国国家标准信息交换用汉字编码”的简称。国标表（基本表）把七千余汉字、以及标点符号、外文字母等，排成一个94行、94列的方阵。方阵中每一横行叫一个“区”，每个区有九十四个“位”。一个汉字在方阵中的坐标，称为该字的“区位码”。例如“中”字在方阵中处于第５４区第４８位，它的区位码就是5448. 其实94这个数字。它是美标中形象码的总数。国标表沿用这个数字，本意大概是要用两个美标形象符代表一个汉字。由于美标形象符的编码是从33到126，汉字区、位码如果各加上32，就会与美标形象码的范围重合。如上例“中”字区、位码加上32后，得86,80。这两个数字的十六进制放在一起得5650，称为该字的“国标码”，而与其相对应的两个美标符号，VP,也就是“中”字的“国标符”了。 这样就产生了一个如何区分国标符与美标符的问题。在一个中英文混用的文件里，“VP”到底代表“中”字呢，还是代表某个英文字头缩写？电子工业部第六研究所开发CCDOS的时候，使用了一个简便的解决方案：把国标码的两个数字各加上128，上升到非美标码的位置。（改变后的国标码，习惯上仍叫“国标”。） 这个方案固然解决了原来的问题，可是新的问题随之产生。中文文件成了“二进制文件”，既不能可靠地在不同电脑系统间交换，也不与市场上大部分以美标符号为设计对象的软件兼容。 为了区分以上两种“国标”，我们把原与美标形象码重合的国标码称为“纯国标” ，而把CCDOS加上128的国标码称为“准国标”。 3．GBK码： GBK码是GB码的扩展字符编码，对多达2万多的简繁汉字进行了编码，简体版的Win95和Win98都是使用GBK作系统内码。 从实际运用来看，微软自win95简体中文版开始，系统就采用GBK代码，它包括了TrueType宋体、黑体两种GBK字库（北京中易电子公司提供），可以用于显示和打印，并提供了四种GBK汉字的输入法。此外，浏览器IE4.0简体、繁体中文版内部提供了一个GBK-BIG5代码双向转换功能。此外，微软公司为IE提供的语言包中，简体中文支持（Simplified Chinese Language Support Kit）的两种字库宋体、黑体，也是GBK汉字（珠海四通电脑排版系统开发公司提供）。其他一些中文字库生产厂商，也开始提供TrueType或PostScript GBK字库。 许多外挂式的中文平台，如南极星、四通利方（Richwin）等，提供GBK码的支持，包括字库、输入法和GBK与其他中文代码的转化器。
上海亚东国际货运有限公司（企业标准） 信息分类与编码 （草案） 日期：2011年10月
目录 1、前言 2、范围 3、规范性应用文件 4、术语和定义 5、分类 6、编码 7、分类对象表示 8、分类编码表
1、前言 本标准由亚东总部办公会议提出，归口到亚东总部信息管理部。 标准起草部门：总经办、办公室、人力资源部、信息管理部。 标准起草人：劳渝声、张正良、孙海龙、沈锡鹤 2、范围 本标准规定了亚东物流信息的分类、编码及分类代码。 本标准适用于总部各级管理部门、分子公司以及相关单位对于物流信息的管理及应用。 3、规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的国标文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，亚东总部鼓励各部门及子分公司根据本标准使用这些国标文件的最新版本。凡是不注日期的引用国标文件，其最新版本适用于本标准。 GB/T 10113-2003 分类与编码通用术语 GB/T 23831-2009 物流信息分类与代码 4、术语和定义 下列术语和定义适用于本标准。 4.1 类 category 具有某种共同属性（或特征）的实物或概念的集合。 【引自GB/T 10113-2003，2.1.1】 4.2 分类 classification 按照选定的属性（或特征）区分分类对象（3.4），将具有某种共同属性（或特征）的分类对象（3.4）集合在一起的过程。 【引自GB/T 10113-2003，2.1.2】 4.3 信息分类 information classifying
把具有某种共同属性或特征的信息归并在一起，把具有不同属性或特征的信息区别开来的过程。 【引自GB/T 10113-2003,2.1.3】 4.4 分类对象 objects of classification 被分类（3.2）的事物或概念。 【引自GB/T 10113-2003,2.1.4】 4.5 线分类法 method of linear classification 将分类对象（3.4）按选定的若干属性（或特征），逐次地分为若干层级，每个层级又分为若干类目。同一分支的同层级类目之间构成并列关系，不同层级类目之间构成隶属关系。 【引自GB/T 10113-2003，2.1.5】 4.6 层次码 layer code 能反映编码对象为隶属关系的代码。 【引自GB/T 10113-2003，2.2.22】 5、分类 5.1 原则 本标准按物流信息的业务管理及应用所反映的属性分类，遵循以下原则：5.1.1科学性 选择物流信息最稳定本质属性或特征作为分类的基础和依据。 5.1.2系统性 将选定的物流信息的属性或特征按一定的排列顺序予以系统化，形成一个科学合理的分类体系。 5.1.3可扩延性 设置收容类目，并且在建立物流信息分类体系和代码编码中充分考虑今后的信息分类与代码的扩充、延拓和细化。 5.1.4兼容性 与相关标准的相关内容相兼容。
商品标识地国家标准 国家对商品地标识有明确地规定，必须符合国家地各项强制性地标准.标识主要是商品标签地规范和各种技术性指标地标志等.具体地要求如下： 食品标签地国家标准 1．食品地品名，必须采用表明食品地真实属性地名称；2．标签上必须有配料表，注明原料、配料、食品添加剂等； 3．净含物以及固形物地含量；4．制造者、经营者地名称、地址等； 5．食品地生产日期、保质期、保存期；6．贮藏方法、贮藏条件、质量等级等；7．产品执行国家地标准号；8．特殊地标注内容. 具体细节参照附录《食品标签管理规定》，其中宠物进口食品必须有中国国家检查机构出具地检验证明. 饮料、酒标签地国家标准 1．必须有商品地品名，名称符合国家相关标准地规定，不可以独创；2．标签上必须有产品地配料表，注明原料、配料、食品添加剂以及特殊酒类中地中草药成分等；3．注明酒精度，如啤酒用%（m/m），其他酒类用%(v/v) 注明；4．标明原汁地含量，啤酒用麦芽汁地含量，如12度，果酒用原果汁地含量，如50%；5．标明产品地净含量；6．必须有制造者、经营者地名称、地址；7．必须有生产日期、保质期、产品地标号（执行地国家标准）和质量地等级； 8．白酒需要注明香型，果酒、葡萄酒、黄酒需要标明类型和糖度，如半干白，或糖度7.0g/l. 化妆品标签地国家标准 1．化妆品必须有中文标识，而且标签地所有内容，均应简单明了，通俗易懂，科学正确； 2．化妆品标识不能出现“消炎”等医疗用语，或者与药品混淆地用语，一切有着夸大和虚假内容地标签，都说明这个化妆品地品质值得怀疑； 3．化妆品标签上都需用中文（无论是进品还是国内生产地）标明产品制造、包装、分装者地依法登记注册地名称和地址，进口化妆品还应标明在我国经销或代理商地登记注册名称和地址；4．标签上还应标明生产日期、生产批号和使用日期，日期应标注在产品包装地可视面； 5．进口化妆品还需标明进口化妆品卫生许可证批文号； 6．化妆品应标明生产企业地生产许可证号、卫生许可证号和产品批准号.常用地雪花膏、水包油护肤膏霜地引用标准是：GB7619（化妆品卫生标准）、GB/T13531.1（化妆品通用检验方法）、QB/T1685（化妆品产品包装外观要求）、QB/T1684（化妆品检验规则）；7．对于染发、烫发、脱毛、美乳、健美、除臭、防晒、祛斑等特殊用途化妆品，必须标注特殊用途化妆品卫生批准文号；8．化妆品要有安全警告、使用指南以及标明储存条件； 9．体积小又无包装，并且不便标注说明性内容地产品（如唇膏、化妆笔等），应标明产品名称和制造者名称. 家用电器标签地国家标准 参照附录《第一批实施强制性产品认证地产品目录》节选，进口电器要求有CCIB标签，国产电器要求有CCEE标签，通讯类产品同时要具备电信入网标签. 服装标签地国家标准 1．标签上必须有制造者地名称、地址，进口产品必须标明原产地以及代理商、进口
物料编码是行业将实际物料进行整理、标准化的第一步。借助编码标准化及提升物料准确性，进行相应的管理优化，不仅可以成功实施信息系统，还能实现准确的运营管理，以及快速的产品开发的更高目标。 物料编码标准化的工作主要可分为四个阶段： 1. 组织工作小组。工作小组并不是一个松散的团体，而应 当有相应完备的组织结构、工作任务和工作计划。 工作小组通常应由标准化部门（一般情况下属于研发或设计部门）牵头，并抽调相关部门（如信息化、销售、采购、工艺、财务、仓库及售后等）人员组成，同时分部人员也应参与其中，以便对涉及物料运营等各方面充分地进行了解。此外，当企业存在较多物料问题时，工作小组有必要保持一定的编制，保障系统上线直到运行良好。 2. 物料整理、分类。在这一阶段，确定物料的分类原则和层 级关系、识别物料的性质。 每一种类别的层级不超过三层。大类一般可根据工程材料特性不同而进行划分；中类可根据物料的用途划分；小类中则可进一步考虑颜色/尺寸的不同。物料分成三级以内有利于容纳物料，具有更大的灵活性以适应企业未来产品的发展。
3. 编码准备。在此关键阶段，将对物料名称、规格进行标准化，进一步确定物料的细分与组合，最后确定编码规则和BOM 规则。 物料名称、规格的不统一是一个看似简单但实际很难处理的问题，有些物料，尤其是定制的塑件，名称叫法不统一造成入库困难。确定编码之前，工作小组需要规范统一物料名称，纠正混乱的称呼。同时规范物料规格的描述方法，不能仅从设计角度，而要从运营角度考虑，使物料的规格描述能方便所有相关部门的使用和识别。在工作方法上，最常采用的是在初期制定物料名称对照表，必要时可辅之以图片说明，进行充分的培训；另一方面则要对外部供应商进行沟通，对名称和规格描述达成共识，要求送货规范。经过前期的培训及后期系统的运行，规范的名称将在企业各部门内流动使用，最终达成统一。 4. 应用基础物料档案与物料清单。在最后阶段系统即将上线前，工作小组分工导入数据。物料档案不仅记录有物料的编码、名称、规格、单位，还要设置有关属性，使得物料在不同的运营环境下起到不同的作用，满足不同部门的需要。物料的录入工作量大，且需要细致的处理，适当地采用一些通用模块可以大大减轻工作量，提高BOM的准确性
企业信息化标准 QB／JF.120０１－2０07 编码规则 受控状态: 发放编号: 版 A／0 号: 200７—0６－08发布２00７—0７-01实施 XXＸXXX有限公司发布 XXXＸXXXXＸ有限公司企业编码标准 ＱB／JＦ、1２0０1—20０7 公司组织机构编码规则 本标准参照了根据XXＸXXXXXX有限公司对组织机构管理得需要,结合实际情况制定。 本标准起草部门:XXXXXXＸXX有限公司信息系统部、 １主题内容与适用范围 本标准规定了XＸＸXXＸXXX有限公司组织机构得分级、代码管理、 本标准适用于XＸXXXXXＸX有限公司组织得管理、登记、统计及会计核算等工作。 ２术语 公司:具有独立法人资格或需要独立核算管理得分支机构或企业,可以定义为公司。
部门:有明确得职能范围与工作职责得组织。 3分类原则 本标准根据企业需要不设分类、 ４编码方法 4、1本标准采用分级数字代码结构,共分五层,最长码为9位,第一层以一位阿拉伯数字表示,代表集团号;第二层以2位阿拉伯数字表示,代表集团部门,其中9９表示分厂;第三层以两位阿拉伯数字表示,表示集团部门下属机构或分厂得序号;第四层以两位阿拉伯数字表示,表示分厂下属部门;第五层以两位阿拉伯数字表示,表示分厂下属部门班组、其分类结构如下:
XXＸXXXXXＸ有限公司企业编码标准 QＢ/ＪF、１2０0１-２007 员工代码编码规则 本标准参照了根据建发鞋楦公司对员工管理得需要,结合实际情况制定、 本标准起草单位:XＸXXＸXＸXX有限公司。 1主题内容与适用范围 本标准规定了ＸXXXXＸXXＸ有限公司员工得分类、代码及关键描述信息、岗位得分类。 本标准适用于ＸXXXXXXXX有限公司员工得管理、工资核算、考勤、奖惩、登记、统计及会计核算等工作、 2术语 岗位 泛指职位,执行一定职务得位置。 职级 员工对应得工资等级,与员工岗位技能相关、 ３分类原则 根据企业管理得需要,人员编码不按特定意义区分,所有得分类以属性方式加以描述、 4 岗位编码
《信息技术服务分类与代码》解读 刘宏 2017-03-09 《信息技术服务分类与代码》标准为信息技术服务分类提供了分类方案，为信息技术服务体系的建立和维护提供了依据。目前公司的业务基本上是按照《信息技术服务分类与代码》进行分类，因此本文介绍了《信息技术服务分类与代码》主要内容。 信息技术服务需求包括纵横两个维度的内容，一是横向的由管理体系、人员、信息资源、技术支撑等组成的信息化体系要素，二是纵向的系统生命周期过程，即系统的概念、开发、生产、使用、支持、退役等六个阶段。 应对需方信息技术服务需求的各项内容，在供方层面产生了八项信息技术服务业务，包括咨询服务、培训服务、数据处理服务、软件开发和部署服务、测试服务、集成服务、IT运维服务和租赁服务。这八种信息技术服务应对需方信息技术服务需求全部要素的同时，也涵盖了系统生命周期过程的全部六个阶段。 运营 图 1 信息技术服务框架图 图1中，八类信息技术服务业务与信息技术服务需求的基本对应关系如下： 1)咨询服务，包括规划、设计、管理咨询、监理、评估认证和技术培训等，应对于 需方信息技术服务需求中的管理体系、人员、信息资源，以及技术支撑中的概念 和开发等阶段。 2)设计与开发服务，包括硬件、软件等设计开发，应对于需方技术支撑需求中的设
计开发阶段。 3)系统集成试试服务，包括基础环境、硬件、软件、安全等集成实施，以及集成实 施管理等，应对于需方技术支撑需求中的集成实施阶段。 4)运行维护服务，包括基础环境、硬件、软件、安全等运行维护服务，以及运行维 护管理等，应对于需方技术支撑需求中的运行维护阶段。 5)数据处理和存储服务，包括数据加工处理、存储等，应对于需方的信息资源需 求。 6)运营服务，包括软件、平台基础设施等运营服务，应对于需方的租用服务需求； 7)数字内容服务，包括数字动漫、游戏设计、地理信息等内容的加工与整合，应对 于需方的数字内容服务需求。 8)呼叫中心服务，包括业务咨询、信息查询、数据查询等信息服务，应对于需方的 信息服务需求； 在《信息技术服务分类与代码》标准编制中对信息技术服务框架的中的信息技术服务分类进行了调整。表1是目前使用的信息技术服务分类。 特别注意的是在2010年前，由于认知上的失误，将“系统运行与维护”定义为“IT服务”，即所谓“大IT服务（覆盖IT全生命周期阶段的服务）”与“小IT服务（覆盖系统运行与维护阶段的服务）之争。基于《信息技术服务分类与代码》标准，目前公司的业务都属于信息技术服务范围内。公司目前个别业务单元名称冠以“IT服务”（其核心业务为“系统平台运行维护”等），在国内进行业务沟通与交流时可能存在一定的误解，需要特别关注。 信息技术服务的分类与代码内容如下： 表1 信息技术服务分类与代码
量具类产品国家标准 一、长度测量器具 1. 量具类 GB/T 1957-1981 光滑极限量规 GB/T 6093-2001 几何量技术规范（GPS）长度标准量块 GB/T 6322-1986 光滑极限量规型式与尺寸 GB/T 9056-1988 钢直尺 JB/T 7980-1999 半径样板(替代GB 9054-88) JB/T 8788-1998 塞尺 JB/T 10313-2002 量块检验方法 2. 卡尺类 GB/T 1214.1-1996 游标类卡尺通用技术条件 GB/T 1214.2-1996 游标类卡尺游标卡尺 GB/T 1214.3-1996 游标类卡尺高度游标卡尺 GB/T 1214.4-1996 游标类卡尺深度游标卡尺 GB/T 6317-1993 带表卡尺 GB/T 14899-1994 电子数显卡尺 JB/T 5608-1991 电子数显深度卡尺 JB/T 5609-1991 电子数显高度卡尺 JB/T 8370-1996 游标类卡尺游标卡尺(测量范围为0-1500mm、0-2000mm) 3. 千分尺类 GB/T 1216-1985 外径千分尺 GB/T 1218-1987 深度千分尺 GB/T 6312-1986 壁厚千分尺 GB/T 6313-1986 尖头千分尺 GB/T 6314-1986 三爪内径千分尺 GB/T 8061-1987 杠杆千分尺 GB/T 8177-1987 内径千分尺 GB/T 9057-1988 单杆内径千分尺 GB/T 9058-1988 奇数沟千分尺 JB/T 2989-1999 板厚千分尺(替代JB 2989-1981) JB/T 4166-1999 带计数器千分尺(替代JB 4166-1985) JB/T 6079-1992 电子数显外径千分尺 JB/T 10005-1999 小测头千分尺(替代ZB J42 002-1987) JB/T 10006-1999 内测千分尺(替代ZB J42 003-1987) JB/T 10007-1999大外径千分尺(测量范围为1000～3000mm)(替代ZB J42 004-87) JB/T 10032-1999 微米千分尺 JB/T 10033-1999 测微头
1 / 19 南联食品二期项目 需求规格说明书
1.业务模型描述 1.1. 业务场景 1.1.1.编码标准化 基础档案编码是企业信息化体系建设中的基础性工作，基础档案编码的一致性、完整性、易用性将直接影响ERP系统的信息交互与数据共享能力。南联公司现在各部门对各种基础档案的叫法或者命名各不相同。为了实现数据的无缝集成及满足未来南联公司发展的需要，有必要在公司范围内制定统一的数据规范，夯实公司统一管控的基础。 1.1.1.1. 基本准则 1.统一规划，集中管理，组织保障 ?按照编码的使用范围，区分不同的管理层次。按照公司编码使用范围，由南联公司指定部门 专人负责编码规则的规划、制定、备案；组织开展编码工作；对完成的编码进行校验、更新及下发使用。 ?为保证编码工作的顺利实施，南联公司必须指派专人负责此项工作。在项目持续期间协助项 目成员与南联公司各对口业务部门进行工作协调；在项目结束后负责南联公司全部编码的管理，包括编码规则的备案、维护（新增、更新等），并负责督导编码规则的推广与应用。 ?建议成立编码委员会，负责新编码的审定、变更等决策工作。人员由编码涉及的主要业务板 块人员组成，如分管领导、总监、关键用户、骨干业务人员等。务必包含对基层具体业务熟悉的骨干业务人员。 ?对于确定推广应用的编码规则，根据应用范围，建议以编码委员会以及对应的管理部门下达 文件的方式推广。 2.参照国际、国家、行业标准中有关分类标准体系，考虑企业现有的编码，制定编码体系 ?有国际、国家、行业标准的，以国际、国家、行业标准为基础，借鉴行业其他成功案例，结 合考虑实际情况，制定适用于南联公司的编码规范。若南联公司现有的编码规则成熟且能够
中国石化信息分类编码标准 Q/SH005-01-2006 设备分类标准与编码 （2006年试用版） 不作为正式发布 先由相关企业试用 2006年- 8月制订 2006年- 10月试用
目录 Q/SH005-01-2006 (1) 前言 (3) 设备分类标准及编码说明 (4) 一、编制目的 (4) 二、编制依据 (4) 三、适用范围 (4) 四、编码对象 (4) 五、术语定义 (4) 六、设备分类标准制定原则 (5) 七、设备分类标准说明 (5) 八、编码规则 (5) （一）编码规则 (5) （二）代码表结构 (6) 九、油品销售企业《设备分类标准》填报说明 (6)
前言 本标准内容包括：中国石化设备分类与编码 本标准由中国石化信息标准化领导小组提出并归口管理 本标准起草单位：中国石化股份有限公司生产经营管理部 中国石化股份有限公司信息部 石化盈科信息技术有限责任公司 本标准主要起草人： 本标准负责单位：中国石化股份有限公司设备编码组 本标准由中国石化信息标准化领导小组办公室组织专家审核
设备分类标准与编码说明 一、编制目的 本标准编制的目的是为了统一规范设备分类，统一编码，满足石化总部及上、中、下游设备管理和ERP集中建设的需要。 二、编制依据 1、中国石化23大类《设备分类与编码》（2002年版） 2、《石油天然气行业设备分类与编码》（第四版） 3、油品销售EAM分类 三、适用范围 “设备分类标准及编码”适用于中国石化股份公司本部及所属单位。 四、编码对象 设备分类编码对象为28大类1037小类的设备分类。 五、术语定义 1、工业管道系指企业、事业单位所属的用于输送工艺介质的工艺管道、公用工程管道及其他辅助管道。 2、公用管道系指城市或乡镇范围内的用于公用事业或民用的燃气管道和热力管道。 3、长输管道系指产地、储存库、使用单位间的用于输送商品介质的管道。
前言 机动车的四轮定位值是保证机动车的操纵稳定性和直线行驶稳定性的重要参数。为完善国家的行业标准，规范四轮定位仪的生产市场，健全生产法规，促使交通运输业快速健康的发展，特制定《汽车四轮定位仪》产品标准。 本标准由中华人民共和国交通部提出 本标准由交通行业计量技术委员会归口 本标准起草单位：鹤山市黑豹电子机械制造有限公司 吉林大学汽车运输工程研究所 本标准起草人：苏建李炎华张立斌王建强潘洪达戴建国周茹波刘玉梅陈熔李向阳何凤江武洪泽 本标准由交通行业计量技术委员会负责解释
四轮定位仪 1 范围 本标准规定了四轮定位仪的术语和定义、技术要求、试验方法、检验规则、标志与使用说明书和包装、运输、贮存。 本标准适用于检测汽车四轮定位的仪器。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。 GB/T 191 包装储运图示标志（eqv ISO 780） GB 机械安全 机械电器设备 第1部分 通用技术条件 GB 工业产品使用说明书 总则 GB/T 电子仪器环境试验方法 低温贮存试验 GB/T 电子仪器环境试验方法 高温贮存试验 GB/T 电子仪器环境试验方法 跌落试验 GB/T 13384 机电产品包装 通用技术条件 3 术语和定义 下列术语和定义适用本标准。 四轮定位仪 Four-wheel alignmenter 用于测量汽车四轮定位参数的仪器。 单轮前束 Individual wheel toe-in 每一车轮的旋转平面相对汽车纵向轴线（几何中心线）的内夹角称为单轮前束角（θ），车轮前端偏向纵向轴线方向为正，反之为负，单轮前束通过公式（1）计算。 l=θsin ?D （1） 式中：l ——单轮前束值,单位:mm ； D ——车轮前束测量点所处的直径，单位：mm ； θ——单轮前束角，单位：o 。 总前束 total wheel toe-in 左、右单轮前束之和。 推力角 Thrust angle 车辆在俯视平面内纵向轴线和推力线（是一条假想的线，从后轴中心向前延伸，由两后轮共同确定的后轴行驶方向线）的夹角。推力线相对纵向轴线向左侧偏斜为正，向右侧偏斜为负。 轴偏角 Wheel setback angle 同一轴上两车轮中心连线与车辆纵向轴线的垂线之间的夹角。右轮相对于左轮在前为正，反之为负。轴偏角也称为退缩角。
代码通用规范 建立符合WEB标准的站点,每个页面必须包含以下内容： 定义语言编码、根据需要定义
定义语言编码、根据需要定义 允许搜索机器人搜索站内所有链接 浏览器上的图标 快捷方式中的图标
所有标签的元素和属性的名字都必须使用小写, 大小写夹杂也是不被认可的，如："onMouseOver"必须修改成"onmouseover" XHTML要求有严谨的结构，因此所有的嵌套都必须按顺序，如： 必须修改为： 在XHTML中，它们必须被加引号。例如： 编码规则标准 Prepared on 22 November 2020
企业信息化标准 QB/ 编码规则 受控状态: 发放编号: 版号: A/0 2007-06-08发布2007-07-01实施 XXXXXX有限公司发布 XXXXXXXXX有限公司企业编码标准 QB/ 公司组织机构编码规则 本标准参照了根据XXXXXXXXX有限公司对组织机构管理的需要，结合实际情况制定。 本标准起草部门：XXXXXXXXX有限公司信息系统部。 1主题内容与适用范围 本标准规定了XXXXXXXXX有限公司组织机构的分级、代码管理。 本标准适用于XXXXXXXXX有限公司组织的管理、登记、统计及会计核算等工作。 2术语 公司:具有独立法人资格或需要独立核算管理的分支机构或企业，可以定义为公司。 部门:有明确的职能范围和工作职责的组织。 3分类原则 本标准根据企业需要不设分类。 4编码方法 本标准采用分级数字代码结构，共分五层，最长码为9位，第一层以一位阿拉伯数字表示,代表集团号；第二层以2位阿拉伯数字表示，代表集团部门，其中99表示分厂;第三层以两位阿拉伯数字表示,表示集团部门下属机构或分厂的序号;第四层以两位阿拉伯
数字表示，表示分厂下属部门;第五层以两位阿拉伯数字表示，表示分厂下属部门班组。其分类结构如下： QB/ 员工代码编码规则 本标准参照了根据建发鞋楦公司对员工管理的需要，结合实际情况制定。
本标准起草单位：XXXXXXXXX 有限公司。 1主题内容与适用范围 本标准规定了XXXXXXXXX 有限公司员工的分类、代码及关键描述信息、岗位的分类。 本标准适用于XXXXXXXXX 有限公司员工的管理、工资核算、考勤、奖惩、登记、统计及会计核算等工作。 2术语 岗位 泛指职位，执行一定职务的位置。 职级 员工对应的工资等级,与员工岗位技能相关。 3分类原则 根据企业管理的需要，人员编码不按特定意义区分，所有的分类以属性方式加以描述。 4 岗位编码 本标准采用等长3位数字代码结构，以3位阿拉伯数字表示，表示顺序号。其分类结构如下： 所有岗位代码均采用3位编码，必须保证编码的唯一性。 岗位代码表（例） XXX 第一层
SAP物料分类及描述规范 1.说明 本文件概括性地描述了ERP SAP R/3系统中物料数据及其他数据的编码分类、编码规则的总体情况。 2.物料编码的基本原则 为保证公司信息编码标准化、一体化、规范化，减少信息重复处理，避免一物多号、一号多物等现象，编写物料编码应遵循以下基本原则： 2.1 唯一性：保证一个编码对象赋予一个代码，一个代码只反映一个编码对象。 2.2 可扩充性：适应编码对象的不断增加，留有足够的备用码。 2.3 规范性：代码格式要规范、统一，提高可靠性。 2.4 简练性：代码位数尽可能少，减少差错。 2.5 稳定性：要考虑代码变化的可能性，尽可能保持代码系统的稳定。 2.6 识别性：代码应反映编码对象的部分特点，方便记忆和使用。 2.7可操作性：代码应尽可能减少计算机处理的时间。 3.物料编码的基本结构 流水码，结构码 + 流水码 第 1 页共6 页
如： 1开头的为主料，6开头的为成品（其中碎片放在成品的编码范围中） 4.物料描述的基本规范 4.1、主辅料、成品、劳保及客供料、工具、低（高）值易耗等 描述通用规则：产品名称 + 规格型号 如：单晶硅片S125 银浆PV145 电导率仪 DDB-6200 注：1、若无规格型号的只使用产品名称； 2、对于非专用物料，例如基本计量单位为ML的，不再作为新的物料代码进行编码； 3、对于专用的不同的包装的使用不同的编码。如200ML与500ML三氯氧磷，使用不同代码。 4.2、办公用品、备品备件 A、专用备件：名称+规格型号+品牌，如：伺服电机TSB08751C-2BH3东元 B、通用备件/办公用品：名称+规格型号+(品牌) 如：有机玻璃板 2400*1200*5(mm) C、国外备件：设备厂家+（订货代号）+ 中文名称（附加数据：英文名称及参数）如：RENA 112054两通隔膜阀 注：1.规格型号比较多的情况下以/隔开区分； D、非标件：名称+图纸号+版本号 4.3、碎片根据性质分为硅碎片、制绒碎片、扩散碎片、刻蚀碎片、PECVD碎片、丝印碎片、烧结碎片、电池碎片按面积比例定义碎片（大于1/2电池碎片、小于1/2电池碎片）。 4.4、硅片及电池片针对OEM是否为采购的，分别分为两个物料号；OEM物料为采购过来，硅片及电池片描述前加采购OEM； 若为客供料，该部分物料为无价物料，硅片及电池片前加“客供OEM”； 4.5 保税料：保税+名称 4.6、电池片研发及在建工程根据财务要求，针对每一种产成品分别增加零价的物料号码；在描述前分别添加“项目物料(名称)”注明。 第 2 页共6 页