iPhone的DCIM目录中的所有随机文件夹有什么用?


17

我的照片散布在iPhone 5的DCIM目录中的17个看似随机命名的文件夹中。

我对此一无所知,在所有这些目录中查找我要找的照片是非常痛苦的。

我的设备为什么要这样做,我可以使其停止吗?

DCIM


3
坦白说,你不是故意的。您应该让iTunes或iPhoto [Mac]照片库[Win]来照顾它。
Tetsujin 2014年

您甚至如何从Windows资源管理器访问iPhone?我的没有出现。iPhone 5
Xonatron

Answers:


15
  • 只需将自己放在DCIM文件夹中,然后选择搜索即可。
  • 搜索 *.*
  • 选择一些拇指指甲视图
  • 按名称排序结果

您将按顺序看到所有图片,并且可以轻松找到所需的图片。


我发现这是一个很好的解决方法- *按日期搜索和排序,将最新照片放在顶部。不理想,但是比必须使用导入软件从手机中取出一张照片更好。
米奇2015年

4

这些“随机命名的文件夹”与Apple和所有现代数码相机使用的相机文件系统(DCF)设计规则一致。

摘自DCF上Wikipedia文章:(强调我自己)

目录和文件结构

数码相机中的文件系统包含一个DCIM(数码相机图像)目录,该目录可以包含多个名称为“ 123ABCDE”的子目录,这些目录由一个唯一的目录号(范围为100…999)和五个字母数字字符组成。是自由选择的,通常是指相机制造商。这些目录包含名称为“ ABCD1234.JPG”的文件,其中包含四个字母数字字符(通常为“ DSC _”,“ DSC0”,“ DSCF”,“ IMG _” /“ MOV_”或“ P000”),后跟一个数。

我的索尼数码相机会创建一个101MSDCF默认的目录,我可以手动创建更多,如果我愿意的话,它的名字102MSDCF103MSDCF等等。而我的iPad似乎为每个30天期限的文件夹。(?)

如果iPad作为“ USB大容量存储设备”安装,则您应该在Windows资源管理器中看到此目录结构。但是,如果使用其他应用程序或“协议”,则可能不会。例如,我可以使用Paint.NET(Windows)通过“图片传输协议”(PTP)从iPad“获取”照片-使用此方法可以隐藏基础目录结构。


3

您的信息存储在文件中,但也存储在数据库中。在某个地方有一个数据库,该数据库保存描述某个事件的元数据,并将该事件与文件位置桥接。对您来说,它看起来是随机的:但是对于手机来说,只要文件在数据库中具有条目,它就不在乎文件的存储位置。

认为数据库是“目录”的一种-信息页面可以存在于书中的任何位置,并且读者可能不关心在哪里,只要他们能找到它。

简而言之,您正在看的东西对电话有意义,但绝不意味着对您有意义,因为您不应从这种观点看它。您应该通过其他应用程序来查看它(有人提到Photo Gallery-我不知道那是不是真的,但这听起来可能)。


实际上,当您将照片从手机复制到PC时,Apple的指示是通过文件浏览器进行访问。因此,您应该这样看。
杰森·凯利

3

我也很困惑,试图弄清最近几个月的文件夹/目录命名。

这些文件夹的名称总是奇怪的,但并不是随机的-从过去查看我的各种iOS设备(我目前有3个)开始,所有这些文件夹似乎都在按照某种预定义的顺序进行操作,文件夹名称(在我的情况下)在Windows 8.1中的Win Explorer下提供。这些“文件夹”中的每一个都以8个字母数字字符的名称命名,在继续进行下一个之前,最多可包含1000张图像。

随后出现了iOS8。首先,它们似乎允许预定义的文件夹(通过iOS)变得越来越大,而不仅仅是1000张照片。某一时刻,我在其中一个文件夹中有3500。然后,iOS 8.1或8.1.1(我忘记了)改变了事情,因此每个月的图片都包含在一个单独的文件夹中。在我的iPhone 4s和iPad Mini 2上,它们仍按预定义的标题运行(即,它们使用相同的文件夹名称,并排比较,因此不是随机的)。在iPhone 5c上,每次插入手机时,文件夹的标签都会有所不同,因此看起来确实是随机的。我同意您的看法,即创建了无数文件夹。即使您在12个月内每月只拍摄一张照片,您也会在每个日历月中看到12个文件夹(我相信)。

我的4s,Mini 2和5c都运行iOS 8.1.2。我不知道为什么5c会有不同的表现。总而言之,每个月的照片都会创建8位数字的命名文件夹,但是每次拔出插头并将其重新插入USB端口时,只有5c随机执行。正如上面其他人所说,iPhone使用某种轻型SQL数据库来存储和指示各种事物,而且我认为文件夹是从此“虚拟”生成的,因此该数据库上一定存在某种奇怪的现象。我的5c(以及您所描述的设备的性能),可能只有Apple才能回答.....

我希望以某种方式有所帮助,如果没有其他同意,您不是这里的唯一困惑!:-)


1

当我通过USB将iPhone 4s(运行最新的iOS 8)通过USB连接到WIN7 PC时,我还看到那些随机的DCIM子文件夹,每次将iPhone重新连接到PC时,它们都会更改其名称(这确实很奇怪!)。

好消息:我发现每个子文件夹仅包含特定月份的照片。但是,随机子文件夹的文件名(3位数字,5个字母)与任何日期都不相关,因此很难找到最新的照片,例如

坏消息:不幸的是,当我使用Windows资源管理器通过USB直接访问iPhone照片时,我也不知道如何解决给定的问题。

有趣的是,对于同一个iPhone WIN XP,所有照片都显示在一个文件夹中,可以按常规方式查看和排序所有照片。

较旧的iPhone 4(不支持iOS 8)也在单个子文件夹中显示所有照片(日期不同,尤其是月份和年份不同)。

更新2015/10/06(由Hardy开发):更新到iOS 9.0.2后,DCIM文件夹又回到单个DCIM子目录,例如,Windows资源管理器现在显示子目录100APPLE,用于所有IMG_0999.JPG的照片,子目录101APPLE中的图片以IMG_1000.JPG开头,依此类推。


连接到PC时是否看到所有文件夹都可能归因于所使用的协议(和应用程序)?如果安装为USB大容量存储设备,则可能会看到文件夹。但是,如果使用“图片传输协议”,则应该只看到照片。
MrWhite 2015年

0

这不是随机的-我在运行i0S 7.1.2的iPhone 5C中也遇到相同的情况。起初我还以为它也是随机的,尤其是因为文件夹的名称,但是后来我意识到,每次拍摄照片时,它都会为其命名一个下一个序列号,并且每个文件夹的名称都不同,为1000。一个文件夹的编号为0001-0999 ,然后是1000-1999、2000-2999等。由于您删除了照片,因此无法获得从0001到0999,从1000到1999的所有数字,但是每次启动新的数千个数字时,都会创建一个新文件夹。因此,您可以按“名称”进行排序,它将按数字顺序排列,并因此按照它们被采用的顺序排列。证据:我通过以下方式对此进行了测试:1)检查每个DCIM子文件夹,以查看每个子文件夹是否来自同一组1000,和2)拍摄几张照片并检查文件夹,看看它们是否按顺序命名。还有一个文件夹似乎也有我从朋友那里保存的图像。为什么会这样呢?我不确定文件夹为什么有奇怪的名称,但是我相信存档可能与iCloud备份有关。如果您更换手机并从备份中加载,则它不会帮助手机从0001开始重新启动,而是从上一手机获取的最后一个号码继续。我怎么知道它会从以前的手机继续使用?好吧,我将iPhone 4更换了两次,然后购买了5C,并从以前的备份中加载了所有这些照片,而且照片从未恢复到0001的状态。将它们成千上万的分组可能有助于减少上载和/或损坏过程中的损坏。或者如果发生腐败,那就是


这没有解决有关目录名称的问题,而不是照片的文件名。
伊恩·C

0

在我查看过DCIM文件夹的数十个iOS设备中,这些文件夹从未出现过。较新的iOS似乎更容易累积文件夹,因此您可能需要适应这种情况。

如果要查看这是否是操作系统,请对手机进行完整备份,然后使用设置应用程序将其删除以擦除所有内容和设置。届时,请勿还原备份,而只需运行正常的iOS应用并拍照一两张即可。

您应该看到DCIM/带有Just .MISC100APPLESub文件夹的典型文件夹。然后,您可以跟踪第三方应用程序还是仅仅是各种照片的累积导致文件夹结构的增长。


1
不幸的是,这种“过多文件夹”行为的确似乎是“正常”的,从iOS 8.1开始(据我所知)。我有一个3个月大的iPad,并且看到了相同的文件夹-每30天大约1个文件夹。(其他人建议较早的版本每1000张照片仅创建一个新文件夹。)此目录结构(3位数字+ 5个字母数字)仍然符合DCF文件系统(数码相机标准)。
MrWhite 2015年

@ w3d你是正确的。我的经验是基于较旧的设备和较旧的操作系统。我将编辑我的帖子以反映您的敏锐点。
bmike

0

苹果似乎已经在iOS9上采取了更为合理的方法-文件夹的生成频率要低得多,并且它们被顺序命名,因此您可以轻松导航。在此设备上更新到iOS9,将我在原始问题中显示的文件夹重组为以下内容:

iOS9 DCIM文件夹

如果您使用的是iOS的早期版本,则其他人建议的解决方法效果很好。只需执行通配符搜索(*),然后按文件名对结果进行排序。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.