1
0
mirror of https://github.com/django/django.git synced 2025-10-23 21:59:11 +00:00

Refs #36485 -- Rewrapped docs to 79 columns line length.

Lines in the docs files were manually adjusted to conform to the
79 columns limit per line (plus newline), improving readability and
consistency across the content.
This commit is contained in:
David Smith
2025-07-25 10:24:17 +01:00
committed by nessita
parent 4286a23df6
commit f81e6e3a53
230 changed files with 3250 additions and 2914 deletions

View File

@@ -60,15 +60,15 @@ You can use normal strings or bytestrings (starting with a 'b').
If your code only uses ASCII data, it's safe to use your normal strings,
passing them around at will, because ASCII is a subset of UTF-8.
Don't be fooled into thinking that if your :setting:`DEFAULT_CHARSET` setting is set
to something other than ``'utf-8'`` you can use that other encoding in your
bytestrings! :setting:`DEFAULT_CHARSET` only applies to the strings generated as
the result of template rendering (and email). Django will always assume UTF-8
encoding for internal bytestrings. The reason for this is that the
:setting:`DEFAULT_CHARSET` setting is not actually under your control (if you are the
application developer). It's under the control of the person installing and
using your application -- and if that person chooses a different setting, your
code must still continue to work. Ergo, it cannot rely on that setting.
Don't be fooled into thinking that if your :setting:`DEFAULT_CHARSET` setting
is set to something other than ``'utf-8'`` you can use that other encoding in
your bytestrings! :setting:`DEFAULT_CHARSET` only applies to the strings
generated as the result of template rendering (and email). Django will always
assume UTF-8 encoding for internal bytestrings. The reason for this is that the
:setting:`DEFAULT_CHARSET` setting is not actually under your control (if you
are the application developer). It's under the control of the person installing
and using your application -- and if that person chooses a different setting,
your code must still continue to work. Ergo, it cannot rely on that setting.
In most cases when Django is dealing with strings, it will convert them to
strings before doing anything else. So, as a general rule, if you pass
@@ -209,8 +209,8 @@ In the first example, the UTF-8 characters are unquoted. In the second, the
percent-encodings remain unchanged because they lie outside the valid UTF-8
range or represent a reserved character.
Both ``iri_to_uri()`` and ``uri_to_iri()`` functions are idempotent, which means the
following is always true::
Both ``iri_to_uri()`` and ``uri_to_iri()`` functions are idempotent, which
means the following is always true::
iri_to_uri(iri_to_uri(some_string)) == iri_to_uri(some_string)
uri_to_iri(uri_to_iri(some_string)) == uri_to_iri(some_string)
@@ -272,8 +272,8 @@ setting. The built-in :py:mod:`~django.template.backends.django` backend
provides the ``'file_charset'`` option to change the encoding used to read
files from disk.
The :setting:`DEFAULT_CHARSET` setting controls the encoding of rendered templates.
This is set to UTF-8 by default.
The :setting:`DEFAULT_CHARSET` setting controls the encoding of rendered
templates. This is set to UTF-8 by default.
Template tags and filters
-------------------------
@@ -337,9 +337,10 @@ two fields will return their members as Unicode data. All other attributes and
methods of ``HttpRequest`` return data exactly as it was submitted by the
client.
By default, the :setting:`DEFAULT_CHARSET` setting is used as the assumed encoding
for form data. If you need to change this for a particular form, you can set
the ``encoding`` attribute on an ``HttpRequest`` instance. For example::
By default, the :setting:`DEFAULT_CHARSET` setting is used as the assumed
encoding for form data. If you need to change this for a particular form, you
can set the ``encoding`` attribute on an ``HttpRequest`` instance. For
example::
def some_view(request):
# We know that the data must be encoded as KOI8-R (for some reason).