tmp格式,Linux命令又多又杂?

2023-07-26 00:10:04 20阅读

1、tmp格式，Linux命令又多又杂？

写在前面，个人使用的是：ubuntu 18.04版本的系统，使用的是虚拟机和某讯云服务器的。

分类的依据主要是根据功能来区分的。

tmp格式,Linux命令又多又杂?

常用的命令

cd cd是change directory 的缩写；cd命令后面跟一个路径，可以是绝对路径也可以是相对路径。

ls命令 ls是list的缩写；列出路径或当前目录下的所有文件信息

mkdir命令 mkdir是make directory 的缩写。创建文件夹

cp命令 cp是copy 的缩写。复制文件或文件夹。

cat命令 cat是concatenate 的缩写。读取文件内容

rm命令 rm是remove 的缩写。用于删除文件或文件夹。

常用参数-r -f，需要注意的是，-f表示强制删除，不需要确认，所以不要轻易使用。

关机命令，sudo shutdown -h now 这样比直接关闭虚拟机好一些的，使用虚拟机时一定要保持好习惯。

man命令查看帮助手册 1-8 8个部分 1是命令 2是系统调用 3是库函数标准C 4是设备文件 5 文件格式 6是游戏帮助手册

安装命令，比如安装帮助手册 sudo apt install manpages

文件和目录的命令

cd .. 返回上一级目录

cd ../.. 返回上两级目录

cd ~ 返回根目录

pwd 显示工作路径

ls 查看目录中的文件

ls -l 显示文件和目录的详细资料

ls -a 显示隐藏文件

mkdir dir1 创建目录dir1

rm -rf dir1 删除dir1'目录和内容

查找和搜索命令

使用的主要是 find命令这个也是工作中和面试的时候常常遇见的命令。

文件权限命令

ls -lh 显示权限

+ 设置权限 - 取消权限

chmod命令

chattr +s file1 允许一个文件被安全地删除

chattr +S file1 一旦应用程序对这个文件执行了写操作，使系统立刻把修改的结果写到磁盘

chattr +u file1 若文件被删除，系统会允许你在以后恢复这个被删除的文件 lsattr 显示特殊的属性

打包压缩文件

tar cfvz

new.tar.gz

<文件名>

tar -xvf archive.tar 释放一个包

tar -xvf archive.tar -C /tmp 将压缩包释放到 /tmp目录下

tar -cvfz archive.tar.gz dir1 创建一个gzip格式的压缩包

tar -zxvf archive.tar.gz 解压一个gzip格式的压缩包

写在最后

1.命令哪怕不常用也是要了解和学习的，以后工作中拿来看看就可以用了

2.常用的命令不用死记硬背，熟能生巧，使用的次数多了，自然而然就记得了

3.记忆命令根据功能去分配记忆，好比脑海里有个导图一样，记忆更深刻

4.好记性不如烂笔头，多总结，记笔记，写总结。进步是最快的

2、kali系统用什么分区格式？

Kali Linux系统通常使用标准的Linux文件系统分区格式。最常用的文件系统格式是ext4（第四个扩展文件系统），它是Linux上最常见和推荐的文件系统类型。

当您在安装Kali Linux时，可以选择将根目录（/）和其他分区（如/home、/var、/tmp等）格式化为ext4文件系统。这些分区将用于存储系统文件、用户数据、日志等。

除了ext4之外，Kali Linux也支持其他一些常见的Linux文件系统格式，如ext3、ext2、XFS等。您可以根据自己的需要选择适合的文件系统格式。请注意，Windows系统通常不支持访问和写入这些Linux文件系统格式，而是使用自己的文件系统（如NTFS或FAT32）。

总结起来，Kali Linux系统通常使用ext4文件系统格式，但您也可以选择其他Linux文件系统格式来满足特定需求。

3、tem是什么格式的文件？

是系统产生的临时文件，可以删除的。

系统中经常看到一些莫名其妙的TMP格式文件，下面是产生过程：

临时文件产生

在系统C:\Windows\Temp文件夹中，我们经常会发现一些后缀名为TMP的文件，在该文件夹中的这些文件其实都是临时文件。它们可能是系统被误关机，或者其他程序没有删除而生的。而且在该文件夹中还有其他一些类型的文件，对于这类文件，一般没有什么使用价值，我们可以直接将其删除。

另外我们打开附件的“系统工具”下的“磁盘清理”，然后选择要清理的分区，一般首选为系统分区，即C盘。这样系统则会提示正在扫描，稍候片刻即会打开磁盘清理项目窗口，在“要删除的文件”中选中所有的文件，然后单击“确定”按钮即可。将这些临时文件清理后将可以获得更多的磁盘使用空间。

4、HEVC图像格式你知道多少？

在升级 iOS 11 之后，iPhone 7 及更新的设备内的照片存储将不再用 JPEG 了，而采用了一种新的图片格式 HEIF（发音同 heef），在 iOS 中对应的文件后缀为 .heic ，其编码用的是 HEVC（这个发不了音，哈哈哈）格式，又称 H.265 （这个就很熟悉了 H.264 的下一代），同时look也用 HEVC 作为编码器，对应的文件后缀还是 .mov 。

这里要注意他们俩的关系， HEIF 是图片格式，而 HEVC 是编码格式(类似 H.264,VP8)，HEIF 是图片容器（类似于look的 mkv，mp4 后缀），而用 HEVC 进行编码的 HEIF 图片就是后缀为 .heic 的图片，也是苹果主要使用的格式。

这两个都是很新的标准，分别在 2015 和 2013 年才被 ISO 批准。这篇文章主要介绍一下 HEIF 格式和与其他图片格式相比的优劣。

发展史如下：

screenshot

什么是 HEIF？

screenshot

这张图是 WWDC Session 511 的形容 Heif 的一句英文诗，JPEG 很大，但是 HEIF 和小。

HEIF 全称 High Efficiency Image Format (HEIF)。是由 Moving Picture Experts Group 制定的，存储图片和图片序列的格式。

相关的介绍位置这边可以看到 nokiatech.github.io/heif/ ，对的，你没有看错，是 Nokia 的技术人员们制定的。相比 JPEG ，PNG 等传统的图片格式来说， HEIF 可算是相当年轻了，但是这种格式相比 JPEG 等有很多的优点。

压缩比高，在相同的图片质量情况下，平比 JPEG 高两倍。

能增加如图片深度信息，透明通道等辅助图片。(苹果正是通过这个就能实现动态的调整图片的景深)。

depth

支持存放多张图片，类似相册和集合。（实现多重曝光的效果）

screenshot

支持多张图片实现 GIF 和 livePhoto 的动画效果。

无类似 JPEG 的最大像素限制。

支持透明像素。

分块加载机制。

支持缩略图。

在这个 Nokia 网站上可以看到相关的例子。

文件组成

在look文件中，容器和编码是独立开的，比如 mp4,mkv 等格式是容器，而 H.264,VP8 等是编码。但是图像文件中，像 JPEG 就是混合在一起的（所以它不好用啊，哈哈哈哈），HEIF 就把容器和编码分开了，有用来存放单个或者多个图像的容器。

所以基于不同的编码器，会有不同的文件后缀。

Apple 设备中默认使用的都是 HEVC 的编码的 HEIF 格式。

在 Apple 所编码的 HEIF 的文件组成大致如下图，其 mdat - Media Data 中存放的是 exif 信息，缩略图（320*240），和 HEVC 编码后的图片：

screenshot

HEIF 底层是默认 tiled，就是片状的有 512x512 个，由一个个小的图块，组成一张大图，这一特性有如下的优点：

加速解码

缩放加快(不用加载整张图片)

裁剪加快

HeifTile 和 SystemTile (CATiledLayer 等系统所提供的分块加载)是不一样的，但是两者结合会有很大的提升，所以在加载和处理特大图片时，性能有大幅度的提升。

HEIF 所采用的熵编码也和 JPEG 不一样，JPEG 是用的霍夫曼编码（Huffman），而 HEIF 使用的是基于上下文的自适应二进制算术编码（CABAC），编码的是数据量更小且更快。

兼容性

每当一个新的技术推进至工业化，兼容性无疑是最重要的考量点。像 HEIF 这样的图片格式，并不像 JPEG / PNG 等已经被广泛应用和适配了，估计在 Apple 推出之前，大部分开发者和我一样应该都是不知道的。目前工业化的体系内，对 HEIF 几乎是不兼容，Windows 上无法打开 HEIF 文件，10.13 前的 macOS 也无法打开。苹果在推行这一技术的时候，在内部也是做了很多兼容工作的。

对一般用户

一般情况下，用户是对这个格式无感知的，因为只有在新款支持硬解码的 iOS 手机内部是以 heif & hevc 格式来存储照片和look的，而在用户通过 Airdrop 或者数据线传送到电脑上的时候，对不兼容的设备会自动转换到 JPEG 的格式。所以也不会影响你使用微信，微博等软件。

不过在苹果内部的 app 中，基本都已经用上了这一技术，如照片，FaceTime 等应用。意味着以后同等储存空间能存放更多的照片和look，同时 FaceTime 也能节省更多了流量，相同网络情况下，FaceTime 也会更加清晰。

通过在设置 -> 照片选项中可以设置传到 MAC 或者 PC 上时保持 HEIF 格式。

screenshot

支持的设备

HEIF 图片：

编码：

硬件：**A10 **及以上芯片 iOS 设备。即只有 iPhone7 及以上是支持 HEIF 的(有双摄像头，才带有深度信息)。

软件：iOS11，运行 macOS 系统的 Mac 设备。

解码：

硬件：A9 及以上芯片 iOS 设备（iPhone6s），配备 6 代及以上 Inter Core 处理（Skylake）。

软件：iOS11 和 macOS 支持软解码，但是 iOS11 锁版本代表最低只支持到 5s

HECV look：

look分为 **8 位 / 10 位两种模式。基本和图片编解码保持一致，唯一有区别的是 10 **位硬解码要求是 7 代 Intel 处理器。

总结一下，就是升到 iOS 11 之后，你的设备就能解析新格式的图片和look，软硬解码的区别就是，硬解码会更快并更省电。

对开发者

上层框架 PhotoKit

对用户的几乎无感知切换的前提，肯定是上层 API 没有变化，调整的是最底层的 API，所以一般开发者使用上层的框架时，如 PhotoKIt 是不受影响的，不同格式的图片都抽象为了同一个对象。而且对图片增加滤镜和look的调整修改，最后都会渲染为 JPEG 和 H.264。在这一级别的 API 是接触不到图片文件格式转换所带来的变化的。

下层框架 Image I/O

Image I/O 中可以直接读写 .heic 文件。 iOS 11 中 Image I/O 能够直接读取 heif 的文件，包括读取 exif，xmp 等信息。

let inputURL = URL(fileURLWithPath:Bundle.main.resourcePath! + "/IMG_0513.HEIC") let source = CGImageSourceCreateWithURL(inputURL as CFURL, nil) let image = CGImageSourceCreateImageAtIndex(source!, 0, nil)

let options = [kCGImageSourceCreateThumbnailFromImageIfAbsent as String: true, kCGImageSourceThumbnailMaxPixelSize as String: 320] as [String: Any] let thumb = CGImageSourceCreateThumbnailAtIndex(source!, 0, options as CFDictionary)

guard let cImage = image else { print("not support heic") return; }

当然也可以选择把 CGImage 写入到 HEIC 格式，虽然这样可以节约更多的存储空间，实际使用的时候还是要注意转换操作。

let url = URL(fileURLWithPath: "/tmp/output.heic") guard let destination = CGImageDestinationCreateWithURL(url as CFURL,AVFileType.heic as CFString, 1, nil) else{ fatalError("unable to create CGImageDestination") } CGImageDestinationAddImage(imageDestination, image, nil) CGImageDestinationFinalize(imageDestination)

Apple 提供的很多 API ，供开发者检测设备是否支持新的格式。提供了两种推荐的工作场景事例。

社交网络

在社交软件中，涉及到图片分享之类的内容，是无法确定接受者是否能支持新的格式的， Apple 的策略是建议都进行转换到 JPEG 的操作，比如发送邮件，或者通过 extension 分享的时候，传入其他 app 中的时候，都已经进行了转换了。

p2p 场景

在该场景中，设备和设备间的直接连接，首先把接受者的支持格式告知发送者，然后发送者根据兼容的情况，选择 HEIF 或者 JPEG。比如 AirDrop 。

同时诸如 SDWebImage 目前也正在做对 heif 的兼容。

跨平台

大部分的播放器已经支持了 HEVC 即 H.265 的编码器，但是针对 HEIF 的图片兼容性还是相对较差的。目前有的是 Nokia 提供了一个 C++ 的读写库，通过该库，支持把 HEIF 的图片的解码到 HEVC 的编码数据。

Android 兼容性：

依赖 Nokia 的库，目前只能通过 CPU 软解。

据说 LG 正在研发支持硬解的手机。（raddit)

网页兼容性：

Nokia 提供 JS 库。

Windows 兼容性：

目前也没有能直接打开 HEIF 文件的应用。

对比

常常拿来与 HEVC 来做对比的是 VP9。两者的性能相近，但是 VP9 是开源的，而 HEVC 是需要专利费的（ $2 每设备）。目前暂时没有通过 VP9 进行编码的图片，所以这里主要对比的是 webp 就是通过 VP8 进行编码的图片。 webp WebP目前支持桌面上的Chrome和Opera浏览器，手机支持仅限于原生的Android浏览器、Android系统上的Chrome浏览器、Opera Mini浏览器。

WebP 有损支持

Google Chrome (desktop) 17+ Google Chrome for Android version 25+ Opera 11.10+ Native web browser, Android 4.0+ (ICS) WebP 有损 / 无损 / 透明支持

Google Chrome (desktop) 23+ Google Chrome for Android version 25+ Opera 12.10+ Native web browser, Android 4.2+ (JB-MR1) Pale Moon 26+ WebP 动画支持

Google Chrome (desktop and Android) 32+ Opera 19+

下面是几个关键技术点的对比，可见 HEIF 功能是最强大的。

压缩效率

下面的数据均是官方提出：

Webp 同等质量下，比 JPEG 图像小 25-34%。

JPEG 平均需要比 HEVC 多 139% 的比特率，意味着同等质量下，JPEG 的大小是 HEVC 的 2.39 倍！

把两个的参考标准统一一下：

Webp 比 JPEG 小 25-34% HEVC 比 JPEG 小 58%

但是在我自己的本地的测试中,测试了五组图片。webp 以 80 的质量进行压缩，hevc 以 crf 18 （视觉无损）压缩，同时增加一个 320x240 的缩略图。

自己进行 HEIF 转码的流程是，将图片通过 ffmpeg 编码到 H.265，再通过 Nokia 的库转成 HEIC 文件(Heif)。

//生成主图像编码 ffmpeg -i $1 -crf 18 -preset slower -pix_fmt yuv420p -f hevc bitstream.265 //生成缩略图编码 ffmpeg -i $1 -vf scale=320:240 -crf 28 -preset slower -pix_fmt yuv420p -f hevc bitstream.thumb.265 //调用 Nokia 的工具 ./writerapp config.json

除了一组特大图的表现不一样外，其他几组图片相比， heif 确实比 webp 压缩效率高 10-20%。

毕竟和 HEVC 对标的技术应该是 VP9，所以 heif 能够领先也是情理之中。

解码的消耗测试

主要测试设备是 iPhone 6s Plus 系统 iOS 11，用的解码方法 webp 为 Google 提供的库，hevc 和 jpeg 用的是 CGImageSource 来解码。测试用图片还是之前的五组图片，同时对 JPEG 进行了一些压缩，测试了 5 组平均值(去一个最高，去一个最低)，估计加载的时候存在缓存，所以第一次读图片数据的时候耗时较大。

第一组用第一张 7.7 mb 的 jpeg 压缩后大小 1.1mb jpeg 7.43 2.77 1.46 1.9 2.14 2.00 【占用率 6 %】 hevc 41.0 3.45 3.35 2.62 2.92 2.66 【占用率 6 %】 webp 216.6 216.8 217.5 261.9 195.2 【占用率 21 %】

第二组用第三张 1.8 mb 的 tff，转换成 jpeg 之后大小为** 815 KB。** hevc 58.4 3.1 2.8 1.13 2.65 2.82 2.02 【 2% 】 jpeg 65.3 2.67 2.76 2.73 2.69 2.87 1.34 【 2% 】 webp 130.2 110.9 117.5 114.8 120.9 112.8 124.84 【 12% 】

第三组用的最后一张 243KB PNG ，转换成 JPEG 之后大小为 43 KB。

hevc 47 3.24 2.7 3.21 2.63 1.74 【 1 %】 jpeg 16 6.70 6.97 4.46 7.2 6.76 7.08 【 1% 】 webp 20.7 20.2 12.5 22.0 19.3 19.4 【 2 % 】

测试结果由于硬解码的支持，jpeg 和 hevc 解码速度和 CPU 占用率都比 webp 快和小很多，jpeg 和 hevc 不相伯仲，可见苹果内部对其优化也相当到位，才把它放到 iOS 11 中。

总结

相比 JPEG 来比很强大，毕竟是下一代技术，但是兼容性可想而知，在“最大效率”和“最大兼容”两者中间还是要根据使用场景进行权衡，目前的优势也只有最新的 iPhone 能体验到，但不久的将来可能所有的手机都去支持照片深度，动态照片，更广的色域等。HEVC 也许和推行 H.264 一样，逐渐成为了工业界的标准，但又可能和推行 acc 的处境一样，只是成为了苹果的标准而已，终究还是要看市场的反应了。