请问图片转换成二进制后正常的大小是多少

[qq_33031581]

我用socket发送图片，将图片转换为二进制，但是一个24k的图片转换成二进制后大小为96580，也太大了，传起来很慢。是转换的方式不对吗

[真相重于对错]

怎么转的，你的代码呢?

[大米粥哥哥]

我感觉并不大呀 多大啊

[赵4老师]

不要把 fopen("...","...");fscanf,fprintf,fgets,fgetc,fclose //读时把\r\n替换成\n，写时把\n替换成\r\n;读到\x1a就设置EOF;读写的内容当字符看待 和 fopen("...","...b");fseek,ftell,fread,fwrite,fgetc,fclose //不作以上替换，遇到\x1a仍继续读;读写的内容当字节看待 弄混了

[大尾巴猫]

图片文件本来就是二进制的，不是文本文件。不同分辨率的图片大小不一样。相同分辨率的图片保存格式不一致也会造成图片文件的大小不一样。

[赵4老师]

理解和讨论之前请先学会如何观察！ 在PS中将一幅比如200x200像素的图片用图像、模式中的各种模式和文件、存储为、格式中的各种格式都保存一遍，实际观察一下保存的文件都多少个字节。 不要迷信书、考题、老师、回帖； 要迷信CPU、编译器、调试器、运行结果。 并请结合“盲人摸太阳”和“驾船出海时一定只带一个指南针。”加以理解。 任何理论、权威、传说、真理、标准、解释、想象、知识……都比不上摆在眼前的事实！

[「已注销」]

二进制还需要转吗？读出来难道不是二进制？ 当然，我从不用 fopen、fread、fwrite、fclose 这套设计奇葩的 API： 1. 打开文件的 flag 不用二进制位或，而是字符串，参数还区分文本和二进制模式——这本来不应该是标准所该干预的。 2. fread 和 fwrite 居然不是以 fp 作为第一个参数，却放最后一个，但 fprintf 却是放在第一个。 3. fread 和 fwrite 居然要传 size 和 count 两个参数？除了这俩奇葩之外，哪个读写类 API 不是只传一个地址和长度(大小)？ 我一向坚持用本机 API： Linux 用 open、read、lseek、write、close Windows 用 CreateFile、ReadFile、SetFilePointer、WriteFile、CloseHandle 文件内容是怎么样，读出来就应该是怎么样。 杜绝使用 C 系列文件读写 API，从我做起。

[自信男孩]

图片，可以看成普通文件吧，每次读一定大小的数据到缓存里，然后通过socket发送到对端，对端写文件（文件格式和源端一致），等源端读完，发送完，目的端也写完数据。可以在目的端打开以下图片，是否和源端一致； 没必要一次性读完文件，然后一次性发送到对端；因为一次性读完，可能需要申请很大的空间，其次，一次发送很大的包，网络需要分包，分片；因此不一定提高效率，反而会降低效率；

[赵4老师]

引用 4 楼 SXJIAKE 的回复:

二进制还需要转吗？读出来难道不是二进制？ 当然，我从不用 fopen、fread、fwrite、fclose 这套设计奇葩的 API： 1. 打开文件的 flag 不用二进制位或，而是字符串，参数还区分文本和二进制模式——这本来不应该是标准所该干预的。 2. fread 和 fwrite 居然不是以 fp 作为第一个参数，却放最后一个，但 fprintf 却是放在第一个。 3. fread 和 fwrite 居然要传 size 和 count 两个参数？除了这俩奇葩之外，哪个读写类 API 不是只传一个地址和长度(大小)？ 我一向坚持用本机 API： Linux 用 open、read、lseek、write、close Windows 用 CreateFile、ReadFile、SetFilePointer、WriteFile、CloseHandle 文件内容是怎么样，读出来就应该是怎么样。 杜绝使用 C 系列文件读写 API，从我做起。

可惜教C语言的老师都只教 C 系列文件读写 API。

[「已注销」]

// Windows
#include <windows.h>

int main(int argc, const TCHAR *argv[])
{
	PCTSTR pszFile = argv[1];
	HANDLE hFile1 = CreateFile(pszFile, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
	if (hFile1 != INVALID_HANDLE_VALUE)
	{
		BYTE Buffer[1024] = { 0 };
		DWORD dwReadBytes = 0;
		ReadFile(hFile1, Buffer, sizeof(Buffer), &dwReadBytes, NULL);
		CloseHandle(hFile1);
	}
	HANDLE hFile2 = CreateFile(pszFile, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
	if (hFile2 != INVALID_HANDLE_VALUE)
	{
		BYTE Buffer[1024] = { 0 };
		DWORD dwWrittenBytes = 0;
		WriteFile(hFile2, Buffer, sizeof(Buffer), &dwWrittenBytes, NULL);
		CloseHandle(hFile2);
	}
	return 0;
}

// Linux
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/mman.h>

int main(int argc, const char *argv[])
{
	const char *file = argv[1];
	int fd1 = open(file, O_RDONLY);
	if (fd1 != -1)
	{
		char buf[1024] = { 0 };
		read(fd1, buf, sizeof(buf));
		close(fd1);
	}
	int fd2 = open(file, O_WRONLY | O_CREAT, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
	if (fd2 != -1)
	{
		char buf[1024] = { 0 };
		write(fd2, buf, sizeof(buf));
		close(fd2);
	}
	return 0;
}

[「已注销」]

引用 6 楼 zhao4zhong1 的回复:

可惜教C语言的老师都只教 C 系列文件读写 API。

[「已注销」]

不要迷信书、考题、回帖，要迷信 CPU、编译器、调试器、运行结果。 并请结合“盲人摸太阳”和“驾船出海时一定只带一个指南针”加以理解。 任何理论、权威、传说、真理、标准、解释、想象、知识……都比不上摆在眼前的赵4老师！

[BAO BAO]

图片本身就是二进制的啊 图片有多大 传输的内容就应该是多少，不知道你代码怎么写的

[赵4老师]

电脑内存或文件内容或传输内容只是一个一维二进制字节数组及其对应的二进制地址； 人脑才将电脑内存或文件内容或传输内容中的这个一维二进制字节数组及其对应的二进制地址的某些部分看成是整数、有符号数/无符号数、浮点数、复数、英文字母、阿拉伯数字、中文/韩文/法文……字符/字符串、汇编指令、函数、函数参数、堆、栈、数组、指针、数组指针、指针数组、数组的数组、指针的指针、二维数组、字符点阵、字符笔画的坐标、黑白二值图片、灰度图片、彩色图片、录音、视频、指纹信息、身份证信息……

[ckc]

引用 4 楼 SXJIAKE 的回复:

二进制还需要转吗？读出来难道不是二进制？ 当然，我从不用 fopen、fread、fwrite、fclose 这套设计奇葩的 API： 1. 打开文件的 flag 不用二进制位或，而是字符串，参数还区分文本和二进制模式——这本来不应该是标准所该干预的。 2. fread 和 fwrite 居然不是以 fp 作为第一个参数，却放最后一个，但 fprintf 却是放在第一个。 3. fread 和 fwrite 居然要传 size 和 count 两个参数？除了这俩奇葩之外，哪个读写类 API 不是只传一个地址和长度(大小)？ 我一向坚持用本机 API： Linux 用 open、read、lseek、write、close Windows 用 CreateFile、ReadFile、SetFilePointer、WriteFile、CloseHandle 文件内容是怎么样，读出来就应该是怎么样。 杜绝使用 C 系列文件读写 API，从我做起。

建议去搜索一下“fopen和open的差异"，多了解一些再发表结论。

[xiaohuh421]

24k大小, 现在的网络都是秒传的. 文件内容本身就是二进制了啊, 还要你转什么???? fopen 之后, fread到缓冲区, 然后用socket的send直接发送这个缓冲区就可以了. 不需要转换. 想到的转换的, 都是对数据内存或者数据表示方式理解不到位.

[「已注销」]

引用 13 楼 ckc 的回复:

建议去搜索一下“fopen和open的差异"，多了解一些再发表结论。

建议看清楚我想表达的意思，确定我说的重点再发表结论。

[ckc]

引用 15 楼 SXJIAKE 的回复:

[quote=引用 13 楼 ckc 的回复:]建议去搜索一下“fopen和open的差异"，多了解一些再发表结论。

建议看清楚我想表达的意思，确定我说的重点再发表结论。[/quote] 真没看出来你的重点。 打开文件的flag不用二进制或而是使用字符串的原因是为了不同平台上的兼容性，用二进制或的换了个cpu，换了个编译器，换了个操作系统 就有可能失灵，也就是你写的代码不怎么跨平台，所以才认识不到用字符串的重要意义。 参数区分文本和二进制是历史遗留问题，只是为了让古老的代码在今天的环境下编译的时候尽可能兼容，事实上今天完全可以不加这个参数。 fp是第一个参数还是最后一个参数也是历史遗留问题，可能是当年不同的人写的库函数，所以没能统一，这个是多大的原则问题？完全是小事情好吧 传递size和count两个参数也看不出有什么大不了，按块读写文件的时候一个指定块大小，一个指定读的块的数量，也很方便。你完全可以指定size， count用1就可以了，也就是多写一个参数的事情，这要是都受不了那你看看windows的函数调用，一大堆垃圾参数的情况多的是。 就你这3点，我看不出这些函数有什么十恶不赦的大罪。 至于你的所谓坚持用本机api，丢失了最宝贵的兼容性，你这个思路自己用用也就拉倒了， 还要在这教坏小朋友，所以我才好心劝你看看这两套api的差异。 你要是觉得你很NB，那就当我没说吧。

[「已注销」]

引用 18 楼 ckc 的回复:

真没看出来你的重点。 打开文件的flag不用二进制或而是使用字符串的原因是为了不同平台上的兼容性，用二进制或的换了个cpu，换了个编译器，换了个操作系统 就有可能失灵，也就是你写的代码不怎么跨平台，所以才认识不到用字符串的重要意义。 参数区分文本和二进制是历史遗留问题，只是为了让古老的代码在今天的环境下编译的时候尽可能兼容，事实上今天完全可以不加这个参数。 fp是第一个参数还是最后一个参数也是历史遗留问题，可能是当年不同的人写的库函数，所以没能统一，这个是多大的原则问题？完全是小事情好吧 传递size和count两个参数也看不出有什么大不了，按块读写文件的时候一个指定块大小，一个指定读的块的数量，也很方便。你完全可以指定size， count用1就可以了，也就是多写一个参数的事情，这要是都受不了那你看看windows的函数调用，一大堆垃圾参数的情况多的是。 就你这3点，我看不出这些函数有什么十恶不赦的大罪。 至于你的所谓坚持用本机api，丢失了最宝贵的兼容性，你这个思路自己用用也就拉倒了， 还要在这教坏小朋友，所以我才好心劝你看看这两套api的差异。 你要是觉得你很NB，那就当我没说吧。

我从未说我有多牛，差异我当然知道。我只想说明一点，fopen 这个默认文本模式的设计坑了不少人，如果读出来的内容都不是原始内容的话，这还能叫读取文件吗？这叫读取文本。你不能保证所有用 fopen 的人都清楚文本模式和二进制模式的区别，并且知道默认是文本模式。虽然这个是历史包袱，但有时候坑不熟悉的人是事实。参数不用二进制位或运算，以及 fp 参数的位置等，这是我个人顺带吐槽一下。

[幻夢之葉]

楼上的大神，人家还在学习怎么走路，你却教别人怎么跑步

[ckc]

引用 19 楼 SXJIAKE 的回复:

[quote=引用 18 楼 ckc 的回复:]真没看出来你的重点。 打开文件的flag不用二进制或而是使用字符串的原因是为了不同平台上的兼容性，用二进制或的换了个cpu，换了个编译器，换了个操作系统 就有可能失灵，也就是你写的代码不怎么跨平台，所以才认识不到用字符串的重要意义。 参数区分文本和二进制是历史遗留问题，只是为了让古老的代码在今天的环境下编译的时候尽可能兼容，事实上今天完全可以不加这个参数。 fp是第一个参数还是最后一个参数也是历史遗留问题，可能是当年不同的人写的库函数，所以没能统一，这个是多大的原则问题？完全是小事情好吧 传递size和count两个参数也看不出有什么大不了，按块读写文件的时候一个指定块大小，一个指定读的块的数量，也很方便。你完全可以指定size， count用1就可以了，也就是多写一个参数的事情，这要是都受不了那你看看windows的函数调用，一大堆垃圾参数的情况多的是。 就你这3点，我看不出这些函数有什么十恶不赦的大罪。 至于你的所谓坚持用本机api，丢失了最宝贵的兼容性，你这个思路自己用用也就拉倒了， 还要在这教坏小朋友，所以我才好心劝你看看这两套api的差异。 你要是觉得你很NB，那就当我没说吧。

我从未说我有多牛，差异我当然知道。我只想说明一点，fopen 这个默认文本模式的设计坑了不少人，如果读出来的内容都不是原始内容的话，这还能叫读取文件吗？这叫读取文本。你不能保证所有用 fopen 的人都清楚文本模式和二进制模式的区别，并且知道默认是文本模式。虽然这个是历史包袱，但有时候坑不熟悉的人是事实。参数不用二进制位或运算，以及 fp 参数的位置等，这是我个人顺带吐槽一下。[/quote] 嗯，你说的也很有道理。类似的地方其实还挺多的，我个人就对ftp的文本模式很反感，早些年遇到过很多次有人用文本模式传输二进制文件，然后文件被改掉了出故障。 不过这是两难的问题，所有的自动优化处理都可能会给不熟悉的人带来困扰。