拉绳编码器选型要注意的问题
拉绳编码器是一种机械转换成电信号的装置，可输出电流、电压、电阻、脉冲等信号，以满足信息传输、处理、控制、显示、记录等。对与拉绳编码器选型需要注意以下几点要求：
1、首先用户在选择拉绳编码器时要考虑其测量的行程，也就是指的所测量的距离范围是多少，可根据实际工作中的设备测量行程的长短。
2、产品的精度是表现拉绳编码器的关键因素，因为精度越高测量的数值就越准确。一般情况下精度取决于编码器的线性。
3、拉绳式传感器的输出信号种类比较多，使用时可根据自身控制软件来选择信号方式。电流输出拉绳传感器就是一种常见的信号模式，输出信号为4-20mA
4、在分辨率的选择上，分辨率越高的产品，发出的脉冲数就越精确，拉绳式编码器的分辨率是怎么计算呢？一般为轮毂周长/编码器线性*4倍频。
5、拉绳式编码器的电源线和信号线是万万不可以错接的，尤其是电源正和电源负也不可以调换。拉绳编码器厂家在出厂时都带有详细的说明书，标注详细的接线定义。应仔细阅读厂家提供的使用说明书。
6、为编码器提供电压的测量范围，供电电压的高低将会影响拉线编码器输出的信号，造成显示数值跳动、测量误差增大。
7、在安装高精度拉绳编码器时，其平行度可以允许有±0.3mm的误差。应采用水平仪测量一下，因为平行度误差过大会磨损出线口及增加摩擦力导致测量精度降低。
8、信号线和电源线的焊接应牢固，并套有热缩管以防信号连接在一起，外壳应做接地处理；输出电缆应加装防护套，以免在以后的使用中因外力损坏电缆。
9、防止干扰的发生。高精度拉绳编码器对干扰源是比较敏感的，诸如周边设备电磁干扰或静电干扰，都会造成编码器输出信号波动，这样就要在布线时注意焊接屏蔽线，并单独走线，不要和别的如控制线、动力线在一起。如果还未解决，应联系拉绳编码器厂家技术人员解决。
由此可见，为了能更好的发挥拉绳编码器的优质性能，在选择拉绳编码器时就要充分考虑各项技术参数，在采购该产品时根据实际使用选择合适的产品，以求发挥其最大的使用效果。
上海开地电子有限公司是一家专业的传感器系统及配件成套服务供应商。公司目前所生产及代理的产品有：拉绳编码器、电机编码器、旋转编码器、磁栅尺、接近开关、光电传感器、磁致伸缩位移传感器、倾角传感器、拉绳位移传感器、超速开关、测速电机、减速机、联轴器、皮带轮、链条、电缆、控制器及其相关附近等产品，欢迎选购（本文转载自http://www.kindele.com/bianmqzl/lswt.shtml，转载时请注明出处）。

软件工程导论
6.第六章软件编码


单选题

在编码中首先要考虑的是( )。 程序的可读性
序言性注释应置于文件或模块的( )位置。. 起始
选择程序设计语言不应该考虑的是( )。 语言的功能
最早用于科学计算的程序设计语言是( )。 FORTRAN



判断题

使用括号改善表达式的清晰性。 √
尽可能对程序代码进行优化。 ×
不要进行浮点数的相等比较。 √
利用数据类型对数据值进行防范。 √

2012-07-14 wcdj
问题描述：
在做字符串处理时，若缓冲区的长度固定，在向缓冲区copy字符串时会出现被截断的情况。此处考虑被copy的字符串使用GBK编码并含有汉字，若出现截断则缓冲区的内容结尾可能会出现乱码。此问题会引发向DB导入数据发生异常等其他一些问题。

解决方法：
首先要了解出现这个问题的原因，即字符集编码的问题。下面是关于GBK和UTF-8的介绍：
GBK http://baike.baidu.com/view/25421.htm

UTF-8 http://baike.baidu.com/view/25412.htm

Unicode http://baike.baidu.com/view/40801.htm

需要知道：
(1) GBK采用双字节表示，总体编码范围为8140-FEFE，首字节在81-FE 之间，尾字节在40-FE 之间。GBK的中文编码是双字节来表示的，英文编码是用ASCII码表示的，既用单字节表示。但GBK编码表中也有英文字符的双字节表示形式，所以英文字母可以有两种GBK表示方式。为区分中文，将其最高位都定成1。英文单字节最高位都为0。当用GBK解码时，若高字节最高位为0，则用ASCII码表解码；若高字节最高位为1，则用GBK编码表解码。

(2) UTF-8是UNICODE的一种变长字符编码又称万国码，它用1到6个字节编码UNICODE字符。

(3) Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符，或者说有1114112个码位。码位就是可以分配给字符的数字。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。


在Linux下如何查看文件的编码方式：

方法1：使用 vi 编辑器

我们通常是在Windows下写好代码然后再将文件上传到Linux下，那么可能会遇到文件编码转换的问题。Windows默认的文件格式是GBK(gb2312)编码，而Linux一般都是UTF-8编码。


在Linux下可以通过vi编辑器来查看文件的编码以及对文件进行编码转换：

在vi中可以直接查看文件编码：

:se fileencoding

在vi中可以直接转换文件编码：

:se fileencoding=utf-8

:se fileencoding=gbk

本文使用gbk的编码格式。


PS:

vi中有四个跟字符编码方式有关的选项：

(1) encoding        vi内部使用的字符编码方式

(2) fileencoding    vi中当前编辑的文件的字符编码方式

(3) fileencodings   vi自动探测fileencoding的顺序列表

(4) termencoding    vi所工作的终端的字符编码方式


这些选项可能的取值请参考vi在线帮助 :help encoding-names


在vi中可以通过以下两个命令查看字符的十六进制来确认当前的编码：

(1) ga

显示光标下字符的ASCII数值，十六进制，八进制数值。

(2) :%!xxd

用十六进制方式显示和编辑文件。

例如：

:%!xxd 整个文件以十六进制方式显示

:3!xxd 文件中第3行以十六进制方式显示

:%!od 隐藏右侧的文本列内容

注意：编辑完毕后，要使用命令 !xxd -r 将修改后的十六进制内容转换回来，否则修改后的十六进制的内容将被当作普通文本对待。

方法2：使用 od 命令
cat file | od -x

若使用不同的文件编码，可以查看文件实际存储数据是不同的。

方法3：使用 xxd 命令
xxd file | less

方法4：使用 hexdump 命令
hexdump -C file | less

测试代码


/* 
 * 防止串尾汉字(GBK)出现乱码
 * gerryyang
 * 2012-07-14
 */

#include <stdio.h>
#include <string.h>
#include <string>
using std::string;

/*
 * 功能：计算GBK中文串合理被截断的长度以防止串尾汉字出现乱码
 * @para s: 含有GBK编码字符串的头指针
 * @para iLeft: 函数外部能够使用的缓冲区大小
 * @para ret: 函数返回字符串s合理被截取的长度
 */

int GbkSubString(const char *s, int iLeft)
{
    int len = 0, i = 0;

	if( s == NULL || *s == 0 || iLeft <= 0 ) 
		return(0);

    while( *s )
    {
        if( (*s & 0x80) == 0 )
        {
            i ++;
            s ++;
            len ++;
        }
        else
        {
            if( *(s + 1) == 0 ) break;

            i += 2;
            s += 2;
            len += 2;
        }

        if( i == iLeft ) break;
        else if( i > iLeft )
        {
            len -= 2;
            break;
        }
    }

    return(len);
}


int main(int argc, char **argv)
{
	char szBuf[10] = {0};
	string str = "123abc你好";

	/* 
	 * [1] 未处理中文截断的情况
	 */
	snprintf(szBuf, sizeof(szBuf), "%s", str.c_str());
	printf("szBuf: %s\n", szBuf);

	/*
	 * [2] 处理中文可能被截断的情况
	 */
	memset(szBuf, 0x0, sizeof(szBuf));
	int iBufLeftLen = sizeof(szBuf)-1;

	// 计算合法的长度为iGbkValidLen
	int iGbkValidLen = GbkSubString(str.c_str(), iBufLeftLen);
	puts("");
	printf("str被合理截取的长度为: %d\n", iGbkValidLen);
	snprintf(szBuf, iGbkValidLen + 1, "%s", str.c_str());
	printf("szBuf: %s\n", szBuf);


	return 0;
}

/* 
g++ -Wall -g -o test code_test.c

output:
szBuf: 123abc你?

str被合理截取的长度为: 8
szBuf: 123abc你
*/

更多参考：


[1] 
Linux下文件中文乱码的一些情况

[2] vim encoding and font  

[3] vim 字符编码设置 


[4] 谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词  
http://blog.csdn.net/fmddlmyy/article/details/372148

[5] 浅谈文字编码和 Unicode（上） 
http://blog.csdn.net/fmddlmyy/article/details/1510189

[6] 浅谈文字编码和 Unicode（下） 
http://blog.csdn.net/fmddlmyy/article/details/1510193

[7] 字符集GBK和UTF8的区别说明
http://space.itpub.net/55022/viewspace-713901

[8] 常见字符编码和编码头BOM
http://xouou.iteye.com/blog/1337417

无规矩不成方圆，无论我们做任何事情，都必须遵循一定的规矩。对于一个程序员来说，编程规范可谓是重中之重。当然，不要狭义的把编程规范仅仅理解成是编码规范，整个软件开发过程都是需要规范的，软件工程本身就是一种规范。在这里，我想重点说一下编码规范中的注释。


在编码规范的世界里，注释扮演着一个相当重要的角色。那么，注释到底怎么重要了呢？
 
首先，从编码者自身的角度考虑。
我们完成一个项目，一般来说不是一天两天就完成了，经常是需要几周，几个月，甚至是几年。想象一下，如果你没有写注释，现在让你看你几个月之前写的代码。你能一下子看懂多少？你需要多长时间去回想自己当时的思路？这不是浪费时间嘛！而这些都是可以通过写注释来弥补的。
 
其次，从别人的角度考虑。
我们写代码，不仅仅是给自己看的，更重要的是让别人也能看懂。在软件开发的过程中，维护占大部分比例。而维护工作者可能不是当初编写代码的人。你可能是高手，编写代码的能力很高，本来应该是一天的工作，结果，你没有写注释，半天完成了。表面上看，似乎你的工作效率挺高的。但是，你知道嘛，后期维护的人可能需要用两天，甚至更长的时间去理解你写的代码。这就是好多人不愿意做维护工作的原因。我们总说，作为一个合格的程序员，要时时刻刻为客户着想，难道我们就不需要为和我们一起奋战的同胞们想一想吗？
 
最后，从公司的角度考虑。
你不写注释，一天的工作半天完成了，为公司节省了半天时间。可是，到维护的时候，维护人员可能花了两天的时间才看懂你的代码。可想而知，你为公司带来了多大的“利益”！试问，如果你是公司老板，你会雇佣这样的程序员吗？肯定不会！那么，这样的程序员将永远被定义为码农。码农啊，你懂吗？
 
总之，注释很重要，它是程序员之间沟通的桥梁。对了，强调一下，清晰的代码格式、规范的命名等是比注释更好的注释。
 
为了我们将来不成为专业码农的，从现在开始注重编程规范，认真编写注释吧。让“为‘客户’着想”的想法常驻心中。