ntohs和htons的区别
虽然注册CSDN已经有好几年了，学习写程序也有两年的时间了。对于绝大数人来说，我还是得菜鸟。平时遇到什么问题也会来到这个平台搜索别人的解答。也从这个平台上获益很多。
今天在公司因为一个问题和同事就关于htons与ntohs有没有区别探讨了一下，因为我平时也没留意过，凭着我自己的理解，认为是没有区别的。比如，同在X86的机器下，这两个函数都不是把小端的内存表示方法转成大端的吗。在回来的路上，我想回来查查，同时也想到何不就这个问题写下来，方便自己以后查看，也帮助那些想要解决同样问题的同志呢，于是就开始了我第一篇技术贴。希望我自己也会一直这么继续下去。好了闲话少说，开始正题吧。
我用vc试了一下，结果是相同的。
我就想去看看linux的源代码(/include/netinet/in.h)
# if __BYTE_ORDER == __BIG_ENDIAN
/* The host byte order is the same as network byte order,
so these functions are all just identity. */
# define ntohl(x) (x)
# define ntohs(x) (x)
# define htonl(x) (x)
# define htons(x) (x)
# else
# if __BYTE_ORDER == __LITTLE_ENDIAN
# define ntohl(x) __bswap_32 (x)
# define ntohs(x) __bswap_16 (x)
# define htonl(x) __bswap_32 (x)
# define htons(x) __bswap_16 (x)
# endif
# endif
代码是一样的。
ps: 开始我以为htons是函数，在源码包找了两个小时都没有找到，在绝望的时候看了下头文件，我汗颜了。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/kobeyxyx/archive/2010/05/17/5601830.aspx
从上面的头文件内容可以看出，如果平台是大字序的(如Pocket PC)，则这些函数不作任何转换，只有在平台是小字序时(如X86)，这些函数才进行相应的转换，htons和ntohs(以及htonl和ntohl)实际上没有任何区别，都是把字节序反转，只在于使用者对网络端和主机端理解意义的不同。
在PPC中则转换函数无效，若要进行转换可以自定义一个类似的函数，如下所示：
#define local_htons(x) ((unsigned short int)((((unsigned short int)(x) & 0x00ff)<<8)|/
(((unsigned short int)(x) & 0xff00)>>8)))
#define local_htonl(x) ((unsigned long int)((((unsigned long int)(x) & 0x000000ff)<<24)|/
(((unsigned long int)(x) & 0x0000ff00)<<8)|/
(((unsigned long int)(x) & 0x00ff0000)>>8)|/
(((unsigned long int)(x) & 0xff000000)>>24)))
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/ast_224/archive/2009/03/28/4032491.aspx
检测系统的字序：
#include <iostream> // The CPU bytes order enum TCPUArch {LITTLE_ENDIAN, BIG_ENDIAN, NONEIEEE}; int main(int argc, char *argv[]) { using namespace std; TCPUArch architecture; union { double f; unsigned int x[2]; } testcpu; testcpu.f = 1.0; if( testcpu.x[1] == 0x3FF00000 ) architecture = LITTLE_ENDIAN; else if( testcpu.x[0] == 0x3FF00000 ) architecture = BIG_ENDIAN; else architecture = NONEIEEE; cout << architecture << endl; return 0; }
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/woyaoying/archive/2009/07/09/4333434.aspx