SQLite 和 8+3 文件名

SQLite 的默认配置假定底层文件系统支持长文件名。

SQLite 不对数据库文件强加任何命名要求。SQLite 将愉快地处理具有任何文件扩展名或根本没有扩展名的数据库文件。当回滚日志或预写日志或其他类型的临时磁盘文件之一需要辅助文件时，辅助文件的名称通常通过在数据库文件名的末尾附加后缀来构造。例如，如果原始数据库名为“ app.db ”，那么回滚日志将被称为“ app.db-journal ”，而预写日志将被称为“ app.db-wal ””。这种辅助文件命名方法在支持长文件名的系统上效果很好。但是在强加 8+3 文件名限制的系统上，辅助文件不适合 8+3 格式，即使原始数据库文件符合。

更改文件系统

针对此问题的建议修复是选择不同的文件系统。如今，有大量支持长文件名的高性能、可靠、无专利的文件系统可供选择。在可能的情况下，建议嵌入式设备使用这些其他文件系统之一。这将避免兼容性问题和因使用 8+3 文件名不一致而导致数据库损坏的危险。

调整 SQLite 以使用 8+3 文件名

某些设备被迫使用具有 8+3 文件名限制的旧文件系统以实现向后兼容性，或者由于其他非技术因素。在这种情况下，可以强制 SQLite 使用符合 8+3 模式的辅助文件，如下所示：

使用编译时选项SQLITE_ENABLE_8_3_NAMES=1或 SQLITE_ENABLE_8_3_NAMES=2编译 SQLite 库。默认情况下，SQLite 不支持 8+3 文件名，因为它确实会引入一些开销。开销很小，但即便如此，我们也不希望给不需要 8+3 文件名支持的数十亿 SQLite 应用程序增加负担。
如果使用SQLITE_ENABLE_8_3_NAMES=1选项，则 SQLite 能够使用 8+3 个文件名，但该功能被禁用，并且必须在打开或附加数据库文件时使用URI 文件名为每个数据库连接单独启用，并包括URI 中的“ 8_3_names=1 ”查询参数。如果 SQLite 是用 SQLITE_ENABLE_8_3_NAMES=2编译的，那么默认启用 8+3 个文件名，这一步可以跳过。
确保数据库文件名遵循 8+3 文件名格式，并且它们没有空名称或扩展名。换句话说，数据库文件名的基本名称必须包含 1 到 8 个字符，扩展名必须包含 1 到 3 个字符。不允许空白扩展名。

使用上述步骤时，SQLite 将仅使用扩展名的最后 3 个字符来缩短文件扩展名。因此，例如，通常称为“ app.db-journal ”的文件被缩短为“ app.nal ”。同样，“ app.db-wal ”将变为“ app.wal ”，“ app.db-shm ”将变为“ app.shm ”。

请注意，数据库文件名具有某种扩展名非常重要。如果没有扩展名，则 SQLite 通过附加到文件的基本名称来创建辅助文件名。因此，名为“ db01 ”的数据库将有一个名为“ db01-journal ”的回滚日志文件。由于这个文件名没有扩展名可以缩短为 3 个字符，因此它将按原样使用，并且会违反 8+3 命名规则。

数据库损坏警告

如果使用 8+3 命名而不是默认的长文件名访问数据库文件，则每次打开时每个数据库连接都必须始终使用 8+3 命名访问它，否则存在数据库损坏的风险。辅助回滚日志和预写日志文件对于 SQLite 即将从崩溃中恢复至关重要。如果应用程序使用 8+3 名称并崩溃，那么从崩溃中安全恢复所需的信息将存储在扩展名为“ .nal ”或“ .wal ”的文件中。如果下次应用打开数据库时没有指定" 8_3_names=1" URI 参数，然后 SQLite 将使用长文件名来尝试定位回滚日志或预写日志文件。它不会找到它们，因为它们是由崩溃的应用程序使用 8+3 个名称保存的，因此数据库将无法正确恢复并且可能会损坏。

在某些情况下使用具有 8+3 个文件名的数据库文件，而在其他情况下使用长文件名等同于删除热日志。