Django 2.1.3 文档 开发进程 完整设置列表

不断更新中，更新完毕，删除本句。

警告
覆盖设置时要小心，特别是当默认值是非空列表或字典时，例如STATICFILES_FINDERS。确保保留您希望使用的Django功能所需的组件。

1. 核心设置

这是Django中可用的核心设置列表及其默认值。下面列出了应用程序提供的设置，然后是核心设置的主题索引。有关介绍性资料，请参阅 设置主题指南。

ADMINS

默认值:[]( 空列表）

获取代码错误通知的所有人员的列表。当 DEBUG=False而且在LOGGING中配置了AdminEmailHandler （默认配置），Django会邮件通知这些人在请求/响应周期内发生异常的细节。

列表中的每个项目都应该是(Full name, email address)的这种格式的二元组。例：

[('John', 'john@example.com'), ('Mary', 'mary@example.com')]

ALLOWED_HOSTS

默认值:[]( 空列表）

表示此Django站点可以提供服务的主机/域名的字符串列表。这是一种防止HTTP主机头攻击的安全措施，即使在许多看似安全的Web服务器配置下也是如此。

此列表中的值可以是完全限定名称（例如'www.example.com'），在这种情况下，它们将与请求的Host标头完全匹配（不区分大小写，不包括端口）。用了点开头的值可以用作一个子域通配符：'.example.com'将匹配 example.com，www.example.com以及任何其他 example.com的子域。值'*'将匹配任何东西; 在这种情况下，您有责任提供自己的Host标头验证（可能在中间件中;如果是这样，则必须首先在MIDDLEWARE配置中列出此中间件 ）。

Django还允许任何条目的 FQDN。有些浏览器在Host头中包含一个尾随点，Django在执行主机验证时会将其删除。

如果Host头（或者X-Forwarded-Host （如果 USE_X_FORWARDED_HOST已启用））与此列表中的任何值都不匹配，django.http.HttpRequest.get_host()方法将引发 SuspiciousOperation。

当DEBUG=True并且ALLOWED_HOSTS为空时，将验证主机['localhost', '127.0.0.1', '[::1]']。

ALLOWED_HOSTS进行测试时也会检查。

此验证仅适用于get_host(); 如果您的代码直接从request.META您访问Host头，则绕过此安全保护。

APPEND_SLASH

默认：True

设置为True时，如果请求URL与URLconf中的任何模式都不匹配，并且它不以斜杠结尾，则会向相同的URL发出HTTP重定向，并附加斜杠。请注意，重定向可能导致POST请求中提交的任何数据丢失。

APPEND_SLASH仅在CommonMiddleware安装时(默认安装)使用（​​请参阅中间件）。另见PREPEND_WWW。

1.1 缓存

CACHES

默认：

# The cache backends to use.
CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    }
}

包含Django使用的所有缓存的设置的字典。它是一个嵌套字典，其内容将缓存别名映射到包含单个缓存选项的字典。

必须配置default缓存; 还可以指定任意数量的附加缓存。如果您使用的是除本地内存缓存之外的缓存后端，或者您需要定义多个缓存，则还需要其他选项。以下缓存选项可用。

BACKEND

默认值:''( 空字符串）

后端要使用的缓存。

内置缓存后端	针对类型
'django.core.cache.backends.db.DatabaseCache'	数据库
'django.core.cache.backends.dummy.DummyCache'	开发调试
'django.core.cache.backends.filebased.FileBasedCache'	文件
'django.core.cache.backends.locmem.LocMemCache'	内存
'django.core.cache.backends.memcached.MemcachedCache'	python-memcached模块
'django.core.cache.backends.memcached.PyLibMCCache'	pylibmc模块

您可以通过设置BACKEND为缓存后端类的完全限定路径（即mypackage.backends.whatever.WhateverCache）来使用Django未附带的缓存后端。

译者注：比如使用redis缓存

KEY_FUNCTION

包含函数（或任何可调用函数）的虚拟路径的字符串，用于定义如何将前缀，版本和密钥组合为最终缓存密钥。默认实现等同于函数：

def make_key(key, key_prefix, version):
    return ':'.join([key_prefix, str(version), key])

您可以使用任何所需的key功能，只要它具有相同的参数签名即可。

有关更多信息，请参阅缓存文档。

KEY_PREFIX

默认值:''( 空字符串）

一个字符串，将自动包含（默认情况下预先添加）到Django服务器使用的所有缓存的key中。

有关更多信息，请参阅缓存文档。

LOCATION

默认值:''( 空字符串）

要使用的缓存的位置。这可能是文件系统缓存的目录，memcache服务器的主机和端口，或者只是本地内存缓存的标识名称。例如：

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': '/var/tmp/django_cache',
    }
}

OPTIONS

默认： None

传递给缓存后端的额外参数。可用参数因缓存后端而异。
有关可用参数的一些信息可以在 缓存参数 文档中找到。有关更多信息，请参阅后端模块自己的文档。

TIMEOUT

默认：300

高速缓存项被认为是过期的秒数。如果此设置的值为None，则缓存项不会过期。

VERSION

默认： 1

Django服务器生成的缓存key的默认版本号。

有关更多信息，请参阅缓存文档。

CACHE_MIDDLEWARE_ALIAS

默认： default

用于缓存中间件的缓存连接。

CACHE_MIDDLEWARE_KEY_PREFIX

默认值:''( 空字符串）

一个字符串，它将作为缓存中间件生成的缓存key的前缀。此前缀与KEY_PREFIX组合设置 ; 它不会取代它。

请参阅Django的缓存框架。

CACHE_MIDDLEWARE_SECONDS

默认： 600

缓存一个缓存中间件页面的默认秒数。

请参阅Django的缓存框架。

1.2 安全

译者注：
csrf 部分都需要一个form表单和一个{% csrf_token %}，现定义如下：

<form action="{% url 'polls:index' %}" method="post">
    {% csrf_token %}
    用户名：<input type="text" name="username"/>
    <input type="submit" value="提交"/>
</form>

CSRF_COOKIE_AGE

默认值:31449600( 大约1年，以秒为单位）

CSRF cookie的时限，以秒为单位。

设置很长的到期时间的原因是为了避免在用户关闭浏览器或为页面添加书签然后从浏览器缓存加载该页面时出现问题。如果没有持久性cookie，表单提交在这种情况下将失败。

某些浏览器（特别是Internet Explorer）可能会禁止使用持久性cookie，或者可能会将磁盘上的cookie的索引损坏，从而导致CSRF保护检查（有时间歇性地）失败。将此设置更改None的含义是使用基于会话的CSRF cookie，它将cookie保留在内存中而不是持久存储中。

译者实例：
  a. 通过form表单提交任意数据
  b. 查看HTTP响应中的CSRF cookie，其过期时间是2019.12.04（当前是2018.12.05）。

  c. 在settings.py文件中添加设置

CSRF_COOKIE_AGE = 60 * 60

  d. 重复a 操作的结果如下，过期时间变为一小时之后

CSRF_COOKIE_DOMAIN

默认： None

设置CSRF cookie时要使用的域。这对于轻松允许跨子域请求从正常的跨站点请求伪造保护中排除非常有用。它应设置为一个字符串，"example.com"允许来自另一个子域的视图接受来自一个子域上的表单的POST请求。

请注意，此设置的存在并不意味着默认情况下Django的CSRF保护不会受到跨子域攻击 - 请参阅 CSRF限制部分。

CSRF_COOKIE_HTTPONLY

默认： False

是否在CSRF cookie上使用标志HttpOnly。如果设置为 True，则客户端JavaScript将无法访问CSRF cookie。

将CSRF cookie指定为HttpOnly不提供任何实际保护，因为CSRF仅用于防止跨域攻击。如果攻击者可以通过JavaScript读取cookie，那么就浏览器所知，他们已经在同一个域中，所以无论如何他们都可以做任何他们喜欢的事情。（XSS比CSRF更具威胁。）

虽然这种设置几乎没有什么实际效益，但安全审核员有时会要求它。

如果启用此功能并需要使用AJAX请求发送CSRF token的值，则JavaScript必须从隐藏的CSRF token表单输入而不是从cookie中提取值。

有关详情，请参阅SESSION_COOKIE_HTTPONLY中的 HttpOnly。

译者实例：
  a. 通过form表单提交任意数据
  b. 在客户端js中访问cookie，代码和输出如下所示

    $(".button").click(function () {
        console.log(document.cookie);
    })
# 控制台输出结果
csrftoken=3yNfXGBrrGvCtfqXm5bMnH5fEslIFeaipGVIOeDDT9nk2l0E9ltPYpYHOSs39rEc1

  c. 修改设置文件，增加

CSRF_COOKIE_HTTPONLY = True

  d. 重复b操作，控制台输出结果是空白，查看cookie，多了一个标志

  e. 非 csrf 相关的cookie依然可以访问到（例如，我自己添加的hello）。

CSRF_COOKIE_NAME

默认： 'csrftoken'

用于CSRF身份验证令牌的cookie的名称。这可以是您想要的任何内容（只要它与您应用程序中的其他cookie名称不同）。请参阅 跨站请求伪造保护。

译者实例：
  a. 修改设置文件，增加

CSRF_COOKIE_NAME = 'guess-me'

  b. 通过form表单提交任意数据
  c. 查看cookie，名称发生了变化。

CSRF_COOKIE_PATH

默认： '/'

CSRF cookie上设置的路径。这应该与Django安装的URL路径匹配，或者是该路径的父路径。

如果您在同一主机名下运行多个Django实例，这将非常有用。他们可以使用不同的cookie路径，每个实例只能看到自己的CSRF cookie。

译者实例：

  a. 在8000端口上开启服务，通过form表单提交任意数据，查看cookie如下：

  b. 修改配置文件，增加

CSRF_COOKIE_PATH = '/newi/'

  c. 在9000端口上再开启一个服务，通过form表单提交任意数据，查看cookie如下：

CSRF_COOKIE_SAMESITE

Django 2.1中的新功能：
默认：'Lax'

CSRF cookie上的SameSite标志的值。此标志可防止cookie在跨站请求中发送。

有关SameSite详情，请参阅SESSION_COOKIE_SAMESITE。

CSRF_COOKIE_SECURE

默认： False

是否为CSRF cookie使用安全cookie。如果设置为True，则cookie将被标记为“安全”，这意味着浏览器可以确保cookie仅通过HTTPS连接发送。

CSRF_USE_SESSIONS

默认：False

是否将CSRF token存储在用户的会话中而不是cookie中。它需要使用django.contrib.sessions(INSTALLED_APPS中默认安装)。

将CSRF token存储在cookie中（Django的默认值）是安全的，但将其存储在会话中是其他Web框架中的常见做法，因此有时需要问一下安全审计员。

译者实例：
  a. 首先将我的django_session表清空
  c. 在settings.py文件中设置CSRF_USE_SESSIONS=True
  d. 构建一个form表单添加{% csrf_token %}并提交
  e. 在django_session中多出一条记录,session_data列的内容为base64编码之后的内容
  f. 将base64内容进行解码，得到

2330bd978b9e64884c55824f40ae39949c0beb3f:{"_csrftoken":"M99bIEOy9ICmtuO5vHHdpVRyXIoJjO0hIvR6uMiP7pINgPzu306PjuKbKfFtCJQd"}

  7. 此时查看浏览器的cookie，如下:

（7）在settings.py文件中设置CSRF_USE_SESSIONS=False，并且重复c操作
,并且再次查看浏览器的cookie，如下：

CSRF_FAILURE_VIEW

默认： 'django.views.csrf.csrf_failure'

当CSRF保护拒绝传入请求时要使用的视图函数的虚拟路径。该函数应具有此中形式：

def csrf_failure(request, reason=""):
...

...

其中reason是一条短消息（用于开发人员或日志记录，而不是最终用户），指示请求被拒绝的原因。它应该返回一个HttpResponseForbidden。

django.views.csrf.csrf_failure()接受附加参数template_name, 默认的'403_csrf.html'。如果存在具有该名称的模板，则它将用于呈现页面。

---

译者实例：
其实此设置的功能就是自定义csrf token丢失的提示页面。

  a. 构建一个form表单，不提供{% csrf_token %}，提交请求之后的页面如下所示：

  b. 在设置文件中添加

CSRF_FAILURE_VIEW = 'polls.utils.my_csrf_failure'

  c. my_csrf_failure函数的定义如下

from django.http import HttpResponseForbidden
from django.template import Context, Engine, TemplateDoesNotExist, loader
from django.utils.translation import gettext as _


CSRF_FAILURE_TEMPLATE = """
<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
{{title}}<br>
<h1> CSRF 403 FORBIDDEN</h1>
{{reason}}<br>
</body>
</html>
"""
CSRF_FAILURE_TEMPLATE_NAME = "403_csrf.html"

def my_csrf_failure(request, reason="", template_name=CSRF_FAILURE_TEMPLATE_NAME):
    """
    Default view used when request fails CSRF protection
    """
    c = {
        'title': _("Forbidden"),
        'reason': reason,
    }
    try:
        t = loader.get_template(template_name)
    except TemplateDoesNotExist:
        if template_name == CSRF_FAILURE_TEMPLATE_NAME:
            # If the default template doesn't exist, use the string template.
            t = Engine().from_string(CSRF_FAILURE_TEMPLATE)
            c = Context(c)
        else:
            # Raise if a developer-specified template doesn't exist.
            raise
    return HttpResponseForbidden(t.render(c), content_type='text/html')

  e. 重复 a 操作后，看到的页面如下所示：

CSRF_HEADER_NAME

默认： 'HTTP_X_CSRFTOKEN'

用于CSRF身份验证的请求头的名称。

与request.META中的其他HTTP头一样，从服务器接收的请求头名称将所有字符转换为大写，用下划线替换任何连字符，并为名称添加前缀'HTTP_'·来规范化。例如，如果您的客户端发送'X-XSRF-TOKEN'头，则设置应为'HTTP_X_XSRF_TOKEN'。

译者实例：
  a. 追溯了一下源码，如下所示，能看出来此标志的作用，就是在POST表单中如果获取不到csrfmiddlewaretoken的值，就去CSRF_HEADER_NAME里面找：

# django.middleware.csrf.py
    def process_view(self, request, callback, callback_args, callback_kwargs):
    	...
           if request.method == "POST":
                try:
                    request_csrf_token = request.POST.get('csrfmiddlewaretoken', '')
                except IOError:
                    pass

            if request_csrf_token == "":
                # Fall back to X-CSRFToken, to make things easier for AJAX,
                # and possible for PUT/DELETE.
                request_csrf_token = request.META.get(settings.CSRF_HEADER_NAME, '')

            request_csrf_token = _sanitize_token(request_csrf_token)
            ...

  b. 让我们用form表单提交POST数据，抓包看下请求内容是什么：

  可以在请求体里看到多了一个django自己添加的csrfmiddlewaretoken键值对，有了这个就不会报403错误了。
  c. 让我们去掉这个csrfmiddlewaretoken重新发送，结果毫无意外地403：

  d.在设置文件中添加

CSRF_HEADER_NAME = 'HTTP_X_XSRF_TOKEN'

  e.让我们用form表单提交POST数据，同时增加一个HTTP头为
X-XSRF-TOKEN，值同csrfmiddlewaretoken（请求体中去掉csrfmiddlewaretoken键值对）。

  f.观察结果，没有403出现了，相应结果正常。

CSRF_TRUSTED_ORIGINS

默认值:[]( 空列表）

主机列表，它是不安全请求的可信来源（例如POST）。对于一个不安全的HTTPS请求，Django的CSRF保护机制要求该请求中地Referer 头和Host头同源。例如，这可以防止来自subdomain.example.com的POST能成功请求api.example.com（译者注：去了解下同源策略）。如果您需要通过HTTPS进行跨源地不安全请求，请继续该示例，添加"subdomain.example.com"到此列表。该设置还支持子域，因此您可以添加".example.com"，这样允许从所有example.com的子域进行访问。

译者注：有关同源策略的例子和绕过方法，请见 网友实例。

1.3 数据库

DATABASE

默认值:{}( 空字典）

包含Django要使用的所有数据库的设置的字典。它是一个嵌套字典，其内容将数据库别名映射到包含单个数据库选项的字典。

必须配置default数据库; 还可以指定任意数量的附加数据库。

最简单的设置文件是使用SQLite进行单一数据库设置。可以使用以下配置：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

连接到其他数据库后端（如MySQL，Oracle或PostgreSQL）时，将需要其他连接参数。请参阅下面的ENGINE设置，了解如何指定其他数据库类型。这个例子适用于PostgreSQL：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mydatabase',
        'USER': 'mydatabaseuser',
        'PASSWORD': 'mypassword',
        'HOST': '127.0.0.1',
        'PORT': '5432',
    }
}

可以使用以下内部选项来进行更复杂的配置：

ATOMIC_REQUESTS

默认： False

将其设置为True，将包装数据库中某个事务的每个视图。请参阅将 事务绑定到HTTP请求。

AUTOCOMMIT

默认： True

如果要禁用Django的事务管理并实现自己的事务管理，请将此设置为False。

ENGINE

默认值:''( 空字符串）

要使用的数据库后端。内置的数据库后端是：

• ‘django.db.backends.postgresql’
• ‘django.db.backends.mysql’
• ‘django.db.backends.sqlite3’
• ‘django.db.backends.oracle’

您可以通过设置ENGINE为完全限定的路径（即mypackage.backends.whatever）来使用Django未附带的数据库后端 。

HOST

默认值:''( 空字符串）

连接到数据库时使用哪个主机。空字符串表示localhost。不与SQLite一起使用。

如果此值以正斜杠（/）开头并且您正在使用MySQL，则MySQL将通过Unix套接字连接到指定的socket。例如：

"HOST": '/var/run/mysql'

如果您正在使用MySQL并且此值不以正斜杠开头，则假定此值为一个主机。

如果您正在使用PostgreSQL，默认情况下（空HOST），与数据库的连接是通过UNIX域套接字（pg_hba.conf中的‘local’行）完成的。如果您的UNIX域套接字不在标准位置，请使用与postgresql.conf中相同的unix_socket_directoryfrom 值。如果要通过TCP套接字连接，请设置HOST为“localhost”或“127.0.0.1”（pg_hba.conf中的‘host’行）。在Windows上，您应该始终定义HOST，因为UNIX域套接字不可用。

NAME

默认值:''( 空字符串）

要使用的数据库的名称。对于SQLite，它是数据库文件的完整路径。指定路径时，始终使用正斜杠，即使在Windows上（例如C:/homes/user/mysite/sqlite3.db）。

CONN_MAX_AGE

默认： 0

数据库连接的生命周期，以秒为单位。0表示在每个请求结束时关闭数据库连接 - Django的历史行为 - 设置为None无限持久连接。

OPTIONS

默认值:{}( 空字典）

连接到数据库时要使用的额外参数。可用参数因数据库后端而异。

有关可用参数的一些信息可以在 Database 后端文档中找到。有关更多信息，请参阅后端模块自己的文档。

PASSWORD

默认值:''( 空字符串）

连接数据库时使用的密码。不与SQLite一起使用。

PORT

默认值:''( 空字符串）

连接到数据库时使用的端口。空字符串表示默认端口。不与SQLite一起使用。

TIME_ZONE

默认： None

表示存储在此数据库中的日期时间的字符串（假设它不支持时区）或None。该DATABASES内的这个TIME_ZONE选项与后面的TIME_ZONE设置使用相同的值 。

这允许与以当地时间而不是UTC存储日期时间的第三方数据库进行交互。为避免DST更改出现问题，不应为Django管理的数据库设置此选项。

如果USE_TZ=True且数据库不支持时区（如SQLite的，MySQL和Oracle）。这一句没翻译懂，自己看下(Django reads and writes datetimes in local time according to this option if it is set and in UTC if it isn’t).

如果USE_TZ=True且数据库支持时区（如PostgreSQL），设置这个选项是个错误的。

如果USE_TZ=False，设置这个选项是错误的。

DISABLE_SERVER_SIDE_CURSORS

默认： False

如果要禁用QuerySet.iterator()中的服务器端游标，请将此设为True。事务池和服务器端游标 描述了用例。

这是PostgreSQL特定的设置。

USER

默认值:''( 空字符串）

连接数据库时使用的用户名。不与SQLite一起使用。

TEST

默认值:{}( 空字典）

测试数据库的设置字典; 有关测试数据库的创建和使用的更多详细信息，请参阅测试数据库。

以下是测试数据库配置的示例：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'USER': 'mydatabaseuser',
        'NAME': 'mydatabase',
        'TEST': {
            'NAME': 'mytestdatabase',
        },
    },
}

TEST字典中的以下键可用：

CHARSET

默认： None

用于创建测试数据库的字符集编码。此字符串的值直接传递到数据库，因此其格式是特定于后端的。

由PostgreSQL和MySQL后端支持。

COLLATION

默认： None

创建测试数据库时要使用的排序顺序。此值直接传递给后端，因此其格式是特定于后端的。

仅支持mysql后端（有关详细信息，请参阅MySQL手册）。

DEPENDENCIES

默认值：['default']，对于除了没有依赖项的default之外的所有数据库，。

数据库的创建顺序依赖关系。有关详细信息，请参阅有关控制测试数据库的创建顺序的文档。

MIRROR

默认： None

此数据库在测试期间应镜像的数据库的别名。

此设置用于允许测试多个数据库的主/副本（由某些数据库称为主/从）配置。有关详细信息，请参阅有关测试主/副本配置的文档 。

NAME

默认： None

运行测试组件时要使用的数据库的名称。

如果默认值（None）与SQLite数据库引擎一起使用，则测试将使用内存驻留数据库。对于所有其他数据库引擎，测试数据库将使用名称'test_' + DATABASE_NAME
。
请参阅测试数据库。

SERIALIZE

布尔值，用于控制默认测试运行器是否在运行测试之前将数据库序列化为内存中的JSON字符串（如果没有事务，则用于在测试之间恢复数据库状态）。如果没有任何带有serialized_rollback = True的测试类，可以将其设置为False以加快创建时间。

TEMPLATE

这是PostgreSQL特定的设置。

用于创建测试数据库的模板（例如’template0’）的名称。

CREATE_DB

默认： True

这是Oracle特定的设置。

如果设置为False，则测试表空间不会在测试开始时自动创建，也不会在结束时删除。

CREATE_USER

默认： True

这是Oracle特定的设置。

如果设置为False，则测试用户将不会在测试开始时自动创建，并在结束时删除。

USER

默认： None

这是Oracle特定的设置。

连接到将在运行测试时使用的Oracle数据库的用户名。如果没有提供，Django将使用'test_' + USER。

PASSWORD

默认： None

这是Oracle特定的设置。

连接到运行测试时将使用的Oracle数据库的密码。如果没有提供，Django将生成一个随机密码。

TBLSPACE

默认： None

这是Oracle特定的设置。

运行测试时将使用的表空间的名称。如果没有提供，Django将使用'test_' + USER。

TBLSPACE_TMP

默认： None

这是Oracle特定的设置。

运行测试时将使用的临时表空间的名称。如果没有提供，Django将使用test_ + USER + _temp。

DATAFILE

默认： None

这是Oracle特定的设置。

用于TBLSPACE的数据文件的名称。如果没有提供，Django将使用TBLSPACE + .dbf。

DATAFILE_TMP

默认： None

这是Oracle特定的设置。

用于TBLSPACE_TMP的数据文件的名称。如果没有提供，Django将使用TBLSPACE_TMP + .dbf。

DATAFILE_MAXSIZE

默认：'500M'

这是Oracle特定的设置。

DATAFILE允许增长到的最大大小。

DATAFILE_TMP_MAXSIZE

默认：'500M'

这是Oracle特定的设置。

DATAFILE_TMP允许增长到的最大大小。

DATAFILE_SIZE

Django 2.0 中的新功能：
默认：'50M'

这是Oracle特定的设置。

DATAFILE的初始大小。

DATAFILE_TMP_SIZE

Django 2.0 中的新功能：
默认： '50M'

这是Oracle特定的设置。

DATAFILE_TMP的初始大小。

DATAFILE_EXTSIZE

Django 2.0 中的新功能：
默认： '25M'

这是Oracle特定的设置。

当需要更多空间时，DATAFILE的扩展量。

DATAFILE_TMP_EXTSIZE

Django 2.0中的新功能：
默认：'25M'

这是Oracle特定的设置。

当需要更多空间时，DATAFILE_TMP的扩展量。

DATABASE_ROUTERS

默认值:[]( 空列表）

将用于确定在执行数据库查询时使用哪个数据库的路由器列表。

请参阅有关多数据库配置中的自动数据库路由的文档。

1.4 HTTP

DATA_UPLOAD_MAX_MEMORY_SIZE

默认值:2621440( 即2.5 MB）。

引发SuspiciousOperation（RequestDataTooBig）之前请求体可能的最大大小（以字节为单位 ）。检查发生在碰到request.body或request.POST的时候， 并且不包括任何文件上传数据的大小来计算。您可以将其设置None禁用检查。预计会收到异常的使用大型表单帖子的应用程序应调整此设置。

请求数据量与处理请求所需的内存量相关，并填充GET和POST字典。如果不加以检查，大请求可以用作拒绝服务攻击向量。由于Web服务器通常不执行深度请求检查，因此无法在该级别执行类似检查。
另见 FILE_UPLOAD_MAX_MEMORY_SIZE。

译者实例：
  a. 还是用我们在上面定义的form表单，提交一个2.52M大小的内容到input框中，浏览提提示连接被重置，服务端错误如下：

  b. 修改DATA_UPLOAD_MAX_MEMORY_SIZE 大小为2.6M

DATA_UPLOAD_MAX_MEMORY_SIZE = 2.6 * 1024 * 1024

  c. 重复a操作，结果都正常。

DATA_UPLOAD_MAX_NUMBER_FIELDS

默认： 1000

引发SuspiciousOperation（TooManyFields）之前可通过GET或POST接收的最大参数的个数 。您可以将其设置为None禁用检查。预计会收到异常大量表单字段的应用程序应调整此设置。

请求参数的数量与处理请求和填充GET和POST词典所需的时间量相关。如果不加以检查，大请求可以用作拒绝服务攻击向量。由于Web服务器通常不执行深度请求检查，因此无法在该级别执行类似检查。

译者测试：
  a. 还是用我们在上面定义的form表单，提交一个包含1200个参数的url到GET请求中，服务端错误如下：

  b. 修改DATA_UPLOAD_MAX_MEMORY_SIZE 为None

DATA_UPLOAD_MAX_NUMBER_FIELDS = None

  c. 重复a操作，结果都正常。

1.5 全球化（i18n/ l10n）

DATE_FORMAT

默认值:'N j, Y' （例如Feb. 4, 2003)

用于在系统的任何部分中显示日期字段的默认格式。请注意，如果USE_L10N=True，则区域设置指定的格式具有更高的优先级，并替代使用。见 允许使用的date格式。

另见DATETIME_FORMAT，TIME_FORMAT和SHORT_DATE_FORMAT。

译者实例：
  a. 为模型增加一个字段

date = models.DateField(auto_now=True)

  b. 在后台查看显示的结果：

  c. 在设置文件中做如下修改：

USE_L10N = False
DATE_FORMAT = 'Y年n月j日'

  d. 在后台查看显示的结果：

DATE_INPUT_FORMATS

默认：

[
    '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06'
    '%b %d %Y', '%b %d, %Y',            # 'Oct 25 2006', 'Oct 25, 2006'
    '%d %b %Y', '%d %b, %Y',            # '25 Oct 2006', '25 Oct, 2006'
    '%B %d %Y', '%B %d, %Y',            # 'October 25 2006', 'October 25, 2006'
    '%d %B %Y', '%d %B, %Y',            # '25 October 2006', '25 October, 2006'
]

在日期字段上输入数据时将接受的格式列表。将按顺序尝试格式并使用第一个有效的格式。请注意，这些格式字符串使用Python的datetime模块语法，而不是date过滤器中的格式字符串。

当USE_L10N=True时，区域设置的规定格式具有更高的优先级，将被代替使用。

另见DATETIME_INPUT_FORMATS和TIME_INPUT_FORMATS。

DATETIME_FORMAT

默认值:'N j, Y, P' ( 例如Feb. 4, 2003, 4 p.m）

用于在系统的任何部分中显示日期时间字段的默认格式。请注意，如果USE_L10N=True，则区域设置指定的格式具有更高的优先级，并替代使用。见 允许使用的date格式。

另见DATE_FORMAT，TIME_FORMAT和SHORT_DATETIME_FORMAT。
例子同DATE_FORMAT。

DATETIME_INPUT_FORMATS

默认：

[
    '%Y-%m-%d %H:%M:%S',     # '2006-10-25 14:30:59'
    '%Y-%m-%d %H:%M:%S.%f',  # '2006-10-25 14:30:59.000200'
    '%Y-%m-%d %H:%M',        # '2006-10-25 14:30'
    '%Y-%m-%d',              # '2006-10-25'
    '%m/%d/%Y %H:%M:%S',     # '10/25/2006 14:30:59'
    '%m/%d/%Y %H:%M:%S.%f',  # '10/25/2006 14:30:59.000200'
    '%m/%d/%Y %H:%M',        # '10/25/2006 14:30'
    '%m/%d/%Y',              # '10/25/2006'
    '%m/%d/%y %H:%M:%S',     # '10/25/06 14:30:59'
    '%m/%d/%y %H:%M:%S.%f',  # '10/25/06 14:30:59.000200'
    '%m/%d/%y %H:%M',        # '10/25/06 14:30'
    '%m/%d/%y',              # '10/25/06'
]

在日期时间字段上输入数据时将接受的格式列表。将按顺序尝试格式并使用第一个有效的格式。请注意，这些格式字符串使用Python的datetime模块语法，而不是date过滤器中的格式字符串。

当USE_L10N=True时，区域设置的规定格式具有更高的优先级，将被代替使用。

另见 DATE_INPUT_FORMATS 和TIME_INPUT_FORMATS。

DECIMAL_SEPARATOR

默认值:'.'( 点）

格式化十进制数时使用的默认小数分隔符

请注意，如果USE_L10N=True，则区域设置指定的格式具有更高的优先级，并将替代应用。

另见NUMBER_GROUPING，THOUSAND_SEPARATOR和 USE_THOUSAND_SEPARATOR。

译者实例：

DECIMAL_SEPARATOR = '点'

效果图：

FIRST_DAY_OF_WEEK

默认值:0( 星期日）

代表一周第一天的数字。这在显示日历时特别有用。仅当不使用格式国际化时，或者无法找到当前语言环境的格式时，才使用此值。

该值必须是0到6之间的整数，其中0表示星期日，1表示星期一，依此类推。

FORMAT_MODULE_PATH

默认： None

Python包的完整Python路径，包含项目区域设置的自定义格式定义。如果非None，Django将 在名为当前语言环境的目录下检查formats.py文件，并将使用此文件中定义的格式。

例如，如果FORMAT_MODULE_PATH设置为mysite.formats，并且当前语言是en（英语），Django将构想一个目录树，如：

mysite/
    formats/
        __init__.py
        en/
            __init__.py
            formats.py

您还可以将此设置设置为Python路径列表，例如：

FORMAT_MODULE_PATH = [
    'mysite.formats',
    'some_app.formats',
]

当Django搜索某种格式时，它将遍历所有给定的Python路径，直到找到实际定义给定格式的模块。这意味着在列表中靠近顶层的包中定义的格式将优先于底层的包中的相同格式。

可用格式为：

可用格式
DATE_FORMAT
DATE_INPUT_FORMATS
DATETIME_FORMAT
DATETIME_INPUT_FORMATS
DECIMAL_SEPARATOR
FIRST_DAY_OF_WEEK
MONTH_DAY_FORMAT
NUMBER_GROUPING
SHORT_DATE_FORMAT
SHORT_DATETIME_FORMAT
THOUSAND_SEPARATOR
TIME_FORMAT
TIME_INPUT_FORMATS
YEAR_MONTH_FORMAT

INSTALLED_APPS

默认值: []( 空列表）

指定在此Django安装中启用的所有应用程序的字符串列表。每个字符串应该是一个虚拟的Python路径，可以通过如下两种方式之一指定：

• 应用程序配置类（首选），

INSTALLED_APPS = [
    # ...
    'polls.apps.PollsConfig',
]

• 包含应用程序的包。

INSTALLED_APPS = [
    # ...
    'polls',
]

详细了解应用程序配置。

使用应用程序注册表进行内省
您的代码永远不应该直接访问INSTALLED_APPS。请 改用django.apps.apps。

from django.apps import apps as mapp
print(mapp.app_configs)
# 输出结果
    OrderedDict([('admin', <AdminConfig: admin>), ('auth', <AuthConfig: auth>), ('contenttypes', <ContentTypesConfig: contenttypes>), ('sessions', <SessionsConfig: sessions>), ('messages', <MessagesConfig: messages>), ('staticfiles', <StaticFilesConfig: staticfiles>), ('tour', <TourConfig: tour>), ('polls', <PollsConfig: polls>)])

应用程序名称和标签在INSTALLED_APPS中必须是唯一的
应用程序 names- 应用程序包的虚拟Python路径 - 必须是唯一的。没有办法包括相同的应用程序两次，没有在另一个名称下复制其代码。

应用程序labels- 默认情况下，名称的最后部分 - 也必须是唯一的。例如，您不能同时包含django.contrib.auth和myproject.auth。但是，您可以使用定义不同的自定义配置重新标记应用程序label。

无论是INSTALLED_APPS 引用应用程序配置类还是应用程序包，这些规则都适用。↑

当多个应用程序提供相同资源的不同版本（模板，静态文件，管理命令，转换）时，在INSTALLED_APPS中首先列出的应用程序具有优先权。

TIME_ZONE

默认： 'America/Chicago'

# django.conf.global_settings.py 默认全局设置文件
TIME_ZONE = 'America/Chicago'

表示此安装的时区的字符串。查看完整的时区列表。

注意

由于Django首次发布时TIME_ZONE设置为'America/Chicago'，所以全局设置（如果在项目中settings.py没有定义它）仍然是'America/Chicago'，它是向后兼容的。新项目模板默认为'UTC'。↑

请注意，这不一定是服务器的时区。例如，一个服务器可以为多个Django供电的站点提供服务，每个站点都有一个单独的时区设置。

如果USE_TZ设置为False，Django在此时区上存储所有日期时间。如果USE_TZ设置为True，这是Django会使用此项显示模板日期时间，并解释在表单中输入的日期时间的默认时区是什么。

在Unix环境（实现time.tzset()），Django将os.environ['TZ']变量设置为 您在TIME_ZONE设置中指定的时区 。因此，您的所有视图和模型将自动在此时区中运行。然而，如果你使用 手动配置选项 中所描述的进行手动配置设置，Django将不设置TZ 。如果Django没有设置TZ 环境变量，那么您可以确保您的进程在正确的环境中运行。

注意
Django无法在Windows环境中可靠地使用备用时区。如果您在Windows上运行Django，则TIME_ZONE必须设置为匹配系统时区。↑

USE_I18N

默认： True

一个布尔值，指定是否应启用Django的翻译系统。这提供了一种简单的方法来关闭它，以提高性能。如果设置为 False，Django将进行一些优化，以便不加载翻译机制。

另见LANGUAGE_CODE，USE_L10N和USE_TZ。

注意
为方便起见，由django-admin startproject创建的默认settings.py文件包含了USE_I18N = True 。↑

USE_L10N

默认：False

一个布尔值，指定默认情况下是否启用数据的本地化格式。如果设置为True，Django将使用当前语言环境的格式显示数字和日期。

另见LANGUAGE_CODE，USE_I18N和USE_TZ。

注意
为方便起见，由django-admin startproject创建的默认settings.py文件包含了USE_L10N = True 。↑

1.4 USE_TZ

默认：False

一个布尔值，指定默认情况下日期时间是否为时区感知。如果设置为True，Django将在内部使用时区感知日期时间。否则，Django将在本地时间使用纯日期时间。

另见TIME_ZONE，USE_I18N和USE_L10N。

注意
为方便起见，由django-admin startproject创建的默认settings.py文件包含了USE_TZ = True 。

---

译者实例：
（1）定义了一个模型：

class TZC(models.Model):
    name = models.CharField(max_length=32,default='utc')
    dt = models.DateTimeField(verbose_name='测试日期时间',auto_now=True)
        def __str__(self):
        return str(self.dt)

（2）当前settings.py文件的设置如下：

TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True

（3）在后台插入一条TZC的实例：
a. 我机器当前时间为 下午16点12分30秒
b. 数据库显示

c. 后台显示数据

（4）修改 TIME_ZONE = 'Asia/Shanghai'
后台显示数据：

（5）修改USE_TZ=False：
后台显示数据（和（3）一样）：

从上面的例子能看出USE_TZ的作用（主要在第5点，设置为False的时候，时间不会进行区域感知，也就是不管你设置的时区是什么，都不会做调整）。

---