Base64 编码对文件名安全吗?

发布于 2024-09-27 08:08:33 字数 459 浏览 5 评论 0原文

Base64 编码在 Windows 和 Linux 系统上用于文件名是否安全?根据我的研究,我发现用 -_ 替换结果的所有 / 字符应该可以解决任何问题。

谁能提供更多详细信息吗?

目前在 Java 中我正在使用以下代码:

MessageDigest md5Digest = MessageDigest.getInstance("MD5");
md5Digest.reset();
md5Digest.update(plainText.getBytes());

byte[] digest = md5Digest.digest();

BASE64Encoder encoder = new BASE64Encoder();
hash = encoder.encode(digest);
hash.replace('/','_');

Is Base64 encoding safe to use for filenames on Windows and Linux systems? From my research I have found that replacing all / characters of the result with - or _ should resolve any issues.

Can anyone provide more details on this?

Currently in Java I am using the following peice of code:

MessageDigest md5Digest = MessageDigest.getInstance("MD5");
md5Digest.reset();
md5Digest.update(plainText.getBytes());

byte[] digest = md5Digest.digest();

BASE64Encoder encoder = new BASE64Encoder();
hash = encoder.encode(digest);
hash.replace('/','_');

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

猫九 2024-10-04 08:08:33

修改后的 Base64(当替换 /=+ 时)可以安全地创建名称,但由于许多名称不区分大小写,因此不能保证反向转换文件系统和 URL。

Base64 区分大小写,因此在不区分大小写的文件系统(所有 Windows 文件系统,忽略 POSIX 子系统情况)的情况下,它不能保证 1 对 1 映射。大多数 URL 也不区分大小写,从而防止一对一映射。

在这种情况下我会使用 Base32 - 你会得到更长一点的名称,但是 Base32 编码值对于文件/uri 使用来说是 100% 安全的,无需替换任何字符,并且即使在不敏感的环境(FAT /Win32 NTFS 访问)。

不幸的是,框架中通常没有对此编码的内置支持。另一方面,自己编写或在网上找到代码相对简单。

http://en.wikipedia.org/wiki/Base32

Modified Base64 (when /,= and + are replaced) is safe to create names but does not guarantee reverse transformation due to case insensitivity of many file systems and urls.

Base64 is case sensitive, so it will not guarantee 1-to-1 mapping in cases of case insensitive file systems (all Windows files systems, ignoring POSIX subsystem cases). Most urls also case insensitive preventing 1-to-1 mapping.

I would use Base32 in this case - you'll get names a bit longer, but Base32 encoded values are 100% safe for file/uri usage without replacing any characters and guarantees 1-to-1 mapping even in cases of insensitive environment (FAT/Win32 NTFS access).

Unfortunately there is usually no built-in support for this encoding in frameworks. On other hand code is relatively simple to write yourself or find online.

http://en.wikipedia.org/wiki/Base32.

〆一缕阳光ご 2024-10-04 08:08:33

RFC 3548 建议不仅要替换 /字符。 URL 和文件名安全字母表将:

  • 第 63 个 / 字符替换为下划线 _
  • 第 62 个:第 + > 字符带有减号 -

但也许你最好使用十六进制字符串。我已经有一段时间在文件名中存储哈希值了。我开始使用 Base64 字符串,但后来改用十六进制字符串。我不记得为什么要切换,也许是因为 Windows 没有区分“a”和“A”,正如 AndiDog 所说。

RFC 3548 suggests not only to replace the / character. The URL and Filename safe Alphabet replaces:

  • the 63:nd / character with the underscore _
  • the 62:nd + character with the minus -.

But maybe you better use a HEX-String. It is been a while, when i stored a hash value in a filename. I started with using Base64 String but switched to a Hex-String. I don't remember why i switched, maybe because Windows makes no difference between 'a' and 'A' as AndiDog said.

随遇而安 2024-10-04 08:08:33

我不确定您使用编码的目的,但请考虑百分比编码文件名。

  • 它适用于每个文件系统
  • 只要文件名在 ASCII 范围内,它就能使文件名保持可读性

I'm not sure what you are using the encoding for, but consider percent encoding file names.

  • It works in every file system
  • It keeps file names human readable as long as they're within the ASCII range
黑色毁心梦 2024-10-04 08:08:33

通常 MD5 哈希值(一般的哈希值)表示为十六进制字符串而不是 Base64,后者仅包含 [a-f0-9]。所有文件系统都支持这些名称。

如果您确实想使用 Base64,您的解决方案(替换斜杠)将无法正常工作,因为 Windows 文件系统不会区分“A”和“a”。也许您想改用 Base32?但请注意,Base32 由 4 位组成 8 位,因此仅采用十六进制表示会更容易。

一般来说,Windows 和/或 Linux 中不允许使用以下字符: \ / : * ? ” <> |

Usually MD5 hashes (hashes in general) are represented as hexadecimal strings instead of Base64, which then only contain [a-f0-9]. Those names would be supported by all filesystems.

If you really want to use Base64, your solution (replacing slashes) will not work correctly as Windows filesystems don't make a difference between 'A' and 'a'. Maybe you want to use Base32 instead? But mind that Base32 makes 8 bits out of 4, so it will be easier to just take the hexadecimal representation.

In general, the following characters are not allowed in Windows and/or Linux: \ / : * ? " < > |

挖个坑埋了你 2024-10-04 08:08:33

C# 的单行:

String filename = Convert.ToBase64String(new SHA256Managed().ComputeHash(Encoding.UTF8.GetBytes("UTF-8 string with snowmen"))).Replace("+", "_").Replace("/", "-").Replace("=","");

文件开头需要以下内容:

using System.Security.Cryptography
using System.Text

One-liner for C#:

String filename = Convert.ToBase64String(new SHA256Managed().ComputeHash(Encoding.UTF8.GetBytes("UTF-8 string with snowmen"))).Replace("+", "_").Replace("/", "-").Replace("=","");

Needs the following to the beginning of the file:

using System.Security.Cryptography
using System.Text
許願樹丅啲祈禱 2024-10-04 08:08:33

仅当您使用与 / 不同的字符时,Base64 创建的文件名才是安全的,因为 NTFS 不允许在文件名中使用该字符。只要你这样做,几乎所有常用的文件系统都可以正常使用。

但是,如果文件系统不区分大小写(如 Windows 上的情况),则可能会发生冲突,因为 Base64 字母表同时包含大写和小写。

您可能需要考虑使用 MD5 哈希值的十六进制表示形式,因为这是将这些哈希值表示为字符串的相当标准的方式。

A filename created by Base64 is only safe if you use a different character from /, which you do, as NTFS does not allow that character to be used in file names. As long as you do that, pretty much all commonly used file systems in common use will be OK.

However, if the filesystem is case-insensitive, as is the case on Windows, you can get collisions because the Base64 alphabet contains both upper and lower-case.

You might want to consider using the hexadecimal representation of your MD5 hash instead, since this is a fairly standard way of representing those as a string.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文