二进制文件，小和大端设置位 [英] Binary files, little&big endian setting bits
问题描述
我知道这是一个老问题（抱歉）
但是它有一个不同的问题，我需要写一个二进制文件如下
00000011
00000000
00000000
00000101
00000000
11111111
11111111
00000000
程序将用Microsoft Visual C ++编译
只是想把它写成字符（afaik字符是唯一的
unsigned int只有1个字节）所以基本上我会写的是
3,0,0 ，5,0,256,256,0
问题是，如果我写一个这样的文件，它会出现在上面的那些位上，VC ++写的很少或很大endian和endian以外
问题如果不是如上所述，为什么不呢？
Hi, i know this is an old question (sorry)
but its a different problem, i need to write a binary file as follows
00000011
00000000
00000000
00000101
00000000
11111111
11111111
00000000
program will be compiled in Microsoft Visual C++
was thinking of just writing it as chars (afaik chars are the only
unsigned int thats only 1 byte) so basicly i''ll be writing
3,0,0,5,0,256,256,0
question is if i write a file like that will it come out as the bits
above, does VC++ write little or big endian and other than endian
issues if it doesn''t come out as above, why not??
推荐答案
" Steve" < ST ******** @ nuigalway.ie>在消息中写道
news：28 ************************** @ posting.google.c om ...
"Steve" <st********@nuigalway.ie> wrote in message
news:28**************************@posting.google.c om...
我知道这是一个老问题（对不起）
关闭主题...
问题是，如果我写一个这样的文件将它作为上面的位出来，VC ++是否写出小或大端，而不是endian
问题，如果它不是如上所述，为什么不呢？
Hi, i know this is an old question (sorry)
Off topic, too...
question is if i write a file like that will it come out as the bits
above, does VC++ write little or big endian and other than endian
issues if it doesn''t come out as above, why not??
英特尔80x86处理器是Little Endian，无论你的编译器如何，
16位和32位字不会是按顺序但是会有他们的订单
逆转。但是，写字节时，你应该没有endiannes问题。
见
http://www.cs.umass.edu/~verts/cs32/endian.html
http://www.rdrop.com/~cary/html/endian_faq.html
了解详情。
The Intel 80x86 processors are Little Endian, regardless of your compiler,
16 bit and 32-bit words will not be "in order" but will have their order
reversed. Writing bytes, however, you should have no endiannes problems.
See
http://www.cs.umass.edu/~verts/cs32/endian.html
http://www.rdrop.com/~cary/html/endian_faq.html
for details.
Steve< st ******** @ nuigalway.ie>写道：
Steve <st********@nuigalway.ie> wrote:
但它有一个不同的问题，我需要写一个二进制文件如下
00000011
00000000
00000000
00000101
00000000
11111111
11111111
00000000
程序将在Microsoft Visual C ++中编译
这里应该无关紧要，如果你需要VC ++特定的东西你应该在某些MS相关的新闻组中询问更好。
只是想把它写成chars（afaik chars是唯一的
unsigned int，只有1个字节） ）
对不起，但是一个字符串并不是一个字节（即8位） - 一个
字符可以在不同的位上有不同的位数体系结构。
请参阅< limits.h>中的宏CHAR_BIT，它告诉你一个
char有多少位。
如此基本我会写的是3,0,0,5,0,256,256,0
的问题是，如果我写一个这样的文件就会把它作为上面的位出来，VC ++是否写小或大端和除了endian
问题，如果它不是如上所述，为什么不？??
but its a different problem, i need to write a binary file as follows 00000011
00000000
00000000
00000101
00000000
11111111
11111111
00000000 program will be compiled in Microsoft Visual C++
Should be irrelevant here, if you need something VC++ specific you
better should ask in some MS related newsgroup.
was thinking of just writing it as chars (afaik chars are the only
unsigned int thats only 1 byte)
Sorry, but a char isn''t nessecarily a single byte (i.e. 8 bits) - a
char can have different numbers of bits on different architectures.
See the macro CHAR_BIT in <limits.h>, that tells you how many bits a
char has.
so basicly i''ll be writing
3,0,0,5,0,256,256,0 question is if i write a file like that will it come out as the bits
above, does VC++ write little or big endian and other than endian
issues if it doesn''t come out as above, why not??
当你写单字节时字节序isn根本不是问题 - 当你写出比一个字节更大的数据时，
只会成为一个问题。
此致，Jens
-
\ Jens Thoms Toerring ___ Je *********** @ physik.fu-berlin.de
\ __________________________ http://www.toerring.de
Steve写道：
我知道这是一个老问题（对不起）
但是它有一个不同的问题，我需要写一个二进制文件如下
00000011
00000000
00000000
00000000
11111111
11111111
00000000
将在Microsoft Visual编译的程序C ++
只是想把它写成chars（afaik chars是唯一的
unsigned int只有1个字节）所以基本上我会写的是
3,0 ，0,5,0,256,256,0
问题是，如果我写一个这样的文件将它作为上面的位出来，VC ++写的是小端或大端而不是端点<如果它不是如上所述的问题，为什么不呢？
Hi, i know this is an old question (sorry)
but its a different problem, i need to write a binary file as follows
00000011
00000000
00000000
00000101
00000000
11111111
11111111
00000000
program will be compiled in Microsoft Visual C++
was thinking of just writing it as chars (afaik chars are the only
unsigned int thats only 1 byte) so basicly i''ll be writing
3,0,0,5,0,256,256,0
question is if i write a file like that will it come out as the bits
above, does VC++ write little or big endian and other than endian
issues if it doesn''t come out as above, why not??
我想你问的是关于
将写入每个字节的各个位：
将是3的第一位是高阶零还是低 -
命令一？
首先，可能没有*任何订单。
例如，假设输出发送到并行
接口同时显示所有8位：
哪个位是等于中的第一位什么时候他们一起游行
并排？单独的位甚至可能不是b $ b作为离散单位存在：考虑写入调制解调器
，在每个信号转换中编码许多位，或者
它使用数据压缩并结束传输
2.71828位来编码你提供的八个？在
C语言级别 - 甚至是机器语言
级别，对于大多数机器而言 - 字节是不可分割的
单位I / O，因为它是不可分割的顺序。
其组件无法辨别。
问题最终会出现，在
的水平上数据被存储或通过它传输.b
。在这里，每个存储设备或
传输介质都有自己的编码标准
这些不可分割的传输介质。字节。有些像串行接口一样，确实会分裂原子。并在指定的其他位置传输个人
位。其他如SCSI控制器，
指定特定位的特定信号线。还是
其他人，比如卡片拳（任何人都记得穿孔卡？）
会产生一个洞的图案，编码由3指定的角色
;这种模式可能与原来的8位没有任何明显的关系。
但你不必担心这个，除非你是
负责实施电气接口
到存储或传输介质。
的工作接口是接受序列化的位或SCSI
信号或穿孔卡中的孔并重新组合
来自它们的不可分割的字节值。作为一名程序员，你几乎从不关心细节（除非，或许，你可以写出想要生成指定的诊断代码的
信号线中的图案可以检测串扰，或者说是b $ b b的东西）。你写了一个3，这是各种媒体的业务
，通过这些媒体确保
在另一端发出3。没有huhu，cobber。
你*做*需要担心字节序问题
是你处理多字节数据对象的时候：
低级别媒体为您处理个别字节，但
您有责任将这些字节排列为更大的
结构。对于这样的安排，不同的系统有不同的约定
，这就是为什么你不能只使用
`fwrite（& int_value，sizeof int_value，1， stream）''发送
从一个系统到另一个系统的整数。但是，一旦你用交换格式确定了b $ b。指定订单
和各个字节的含义，你需要做的就是
将你的大对象分解成那些字节之前
写它们，并在读取时将字节重新组合成较大的
对象。实际形式的字节在
航班中这不是你的问题。
如果机器使用不同的字节，那么你可能会遇到的字节数为/ b $ b字节数据交换的唯一担心是>
sizes：例如，在具有8位和
9位字节的计算机之间交换数据可能会非常棘手。但如果你处理一个常见的字节大小，那么一切都很好。
-
呃********* @ sun.com
I think you''re asking about the order in which the
individual bits of each byte will be written: will the
first bit of the 3 be the high-order zero or the low-
order one?
To begin with, there may not *be* any order at all.
For example, suppose the output is sent to a parallel
interface that presents all eight bits simultaneously:
which bit is "first among equals" when they all march
in line abreast? The individual bits may not even
exist as discrete units: Consider writing to a modem
that encodes many bits in each signal transition, or
which uses data compression and winds up transmitting
2.71828 bits to encode the eight you presented? At the
C language level -- and even at the machine language
level, for most machines -- the byte is an indivisible
unit of I/O, and since it''s indivisible the "order" of
its components cannot be discerned.
The question does eventually arise, at the level of
the medium on which the data is stored or through which
it is transmitted. And here, each storage device or
transmission medium has its own standards for the encoding
of these "indivisible" bytes. Some, like serial interfaces,
will indeed "split the atom" and transmit the individual
bits in a specified other. Others, like SCSI controllers,
designate specific signal lines for specific bits. Still
others, like card punches (anybody remember punched cards?)
will produce a pattern of holes that encode the character
designated by 3; this pattern will probably not have any
obvious relation to the original eight bits.
But you needn''t worry about this unless you''re the
person charged with implementing the electrical interface
to the storage or transmission medium. It is the job of
that interface to accept the serialized bits or the SCSI
signals or the holes in a punched card and to reconstitute
the indivisible byte value from them. As a programmer you
almost never care about the details (unless, perhaps, you''re
writing diagnostic code that wants to produce specified
patterns in the signal lines to detect cross-talk, or that
sort of thing). You write out a 3, and it''s the business
of the various media through which that 3 travels to ensure
that a 3 comes out at the other end. No huhu, cobber.
Where you *do* need to worry about endianness issues
is when you''re dealing with multi-byte data objects: the
low-level media take care of individual bytes for you, but
you''re responsible for arranging those bytes into larger
structures. Different systems have different conventions
for such arrangements, and that''s why you can''t just use
`fwrite(&int_value, sizeof int_value, 1, stream)'' to send
an integer from one system to another. But once you''ve
settled on an "exchange format" that specifies the order
and meaning of the individual bytes, all you need to do is
decompose your larger objects into those bytes before
writing them, and reassemble the bytes into the larger
objects when reading. The actual form of the bytes "in
flight" is not your problem.
The only possible worry you might have with byte-by-
byte data exchange is if the machines use different byte
sizes: Exchanging data between machines with 8-bit and
9-bit bytes, for instance, can be tricky. But if you''re
dealing with a common byte size, all is well.
--
Er*********@sun.com
这篇关于二进制文件，小和大端设置位的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
