MAC-адрес клиента (в смысле компьютера, выдавшего HTTP-запрос) перезаписывается каждым маршрутизатором между клиентом и сервером.
Клиентский IP-адрес обычно предоставляется сценарию в $_SERVER['REMOTE_ADDR']
. В некоторых сценариях, особенно если ваш веб-сервер находится за прокси-сервером (т. Е. Прокси-сервер кэширования), $_SERVER['REMOTE ADDR']
вернет IP-адрес прокси-сервера , и будет добавлено дополнительное значение, часто $_SERVER['HTTP_X_FORWARDED_FOR']
, который содержит IP исходного клиента запроса.
Иногда, особенно когда вы имеете дело с анонимным прокси, который вы не контролируете, прокси не вернет реальный IP-адрес, и все, на что вы можете надеяться, это IP-адрес прокси-сервера .
Начиная с Python 3.0, все строки по умолчанию являются юникодными, есть также байтовый тип данных ( документация Python ).
Разработчики python считают, что использование Unicode - хорошая идея, что он не используется повсеместно в python 2, в основном из-за обратной совместимости. Это также влияет на производительность.
В Python 2: Обычные строки (Python 2.x str
) не имеют кодировки: это необработанные данные.
В Python 3: Они называются «байтами», что является точным описанием, поскольку они представляют собой просто последовательности байтов, которые могут быть текстовыми, закодированными в любой кодировке (некоторые из них распространены!) или вообще нетекстовые данные.
Для представления текста вам нужны строки Unicode, а не байтовые строки. Под «строками Unicode» я подразумеваю экземпляры unicode
в Python 2 и экземпляры str
в Python 3. Строки Unicode - это последовательности кодовых точек Unicode, представленных абстрактно без кодирования; это хорошо подходит для представления текста.
Строки байтов важны, потому что для представления данных для передачи по сети или записи в файл или чего-то еще, у вас не может быть абстрактного представления Unicode, вам нужно конкретное представление байтов. Хотя они часто используются для хранения и представления текста, это, по крайней мере, немного непослушно.
Вся эта ситуация усложняется тем фактом, что, хотя вы должны превратить юникод в байты, вызвав encode
, и превратить байты в юникод, используя decode
, Python будет попробуйте сделать это автоматически, используя глобальную кодировку, которую вы можете установить, по умолчанию ASCII, что является наиболее безопасным выбором. Никогда не полагайтесь на это в своем коде и никогда не меняйте его на более гибкое кодирование - явно декодируйте, когда вы получаете байтовую строку, и кодируйте, если вам нужно отправить строку куда-то извне.
Привет! Я хотел бы добавить кое-что к другим ответам, к сожалению, у меня пока недостаточно репутации, чтобы сделать это должным образом: - (
FWIW, сообщение Майка Грэма довольно хорошее, и, вероятно, это то, что вам следует прочитать в первую очередь.
Вот несколько комментариев:
from __future__ import unicode_literals
# - * - coding: utf-8 - * -
. Для получения дополнительной информации см. PEP 0263 . Изменение исходной кодировки влияет на интерпретацию литералов Юникода (независимо от их префикса или отсутствия префикса, как указано в пункте 1). В Py3k кодировка файла по умолчанию - UTF-8. str
в py3k, unicode
в 2.x), потому что в какой-то момент нужно будет написать что-то на память. В идеале это никогда не будет очевидным для конечного пользователя. К сожалению, нет ничего идеального, и вы можете иногда сталкиваться с проблемами: особенно, если вы используете забавные волнистые линии за пределами Unicode Base Multilingual Plane. Начиная с Python 2.2, у нас были так называемые широкие сборки и узкие сборки; эти имена относятся к типу, используемому внутри для хранения кодовых точек Unicode. Широкие сборки используют UCS-4, который использует 4 байта для хранения кодовой точки Unicode. (Это означает, что размер кодовой единицы UCS-4 составляет 4 байта или 32 бита.) Узкие сборки используют UCS-2. UCS-2 имеет только 16 бит и поэтому не может точно кодировать все кодовые точки Unicode (это как UTF-16, за исключением суррогатных пар). Чтобы проверить, проверьте значение sys.maxunicode
. Если это 1114111
, у вас широкая сборка (которая может правильно отображать весь Юникод). Если меньше, не волнуйтесь слишком сильно.BMP (кодовые точки 0x0000
до 0xFFFF
) удовлетворяют потребности большинства людей. Для получения дополнительной информации см. PEP 0261 . какая кодировка нормальный питон строки используют?
В Python 3.x
str
- это Unicode. Это может быть UTF-16 или UTF-32, в зависимости от того, был ли ваш интерпретатор Python построен с использованием «узких» или «широких» символов Unicode.
Версия CPython для Windows использует UTF-16. В Unix-подобных системах предпочтение отдается UTF-32.
В Python 2.x
str
- это строковый тип байтов, например C char
. Кодировка не определяется языком, но является кодировкой по умолчанию в вашем регионе. Или любая другая кодировка MIME документа, который вы получили из Интернета. Или, если вы получаете строку от такой функции, как struct.pack
, это двоичные данные и вообще не имеет смысловой кодировки символов.
строки Unicode
в 2.x эквивалентны str
в 3.x.
и почему они не используют Unicode?
Потому что Python (немного) предшествует Unicode. И потому, что Гвидо хотел сохранить все основные обратно несовместимые изменения для версии 3.0. Строки в 3.x действительно используют Unicode по умолчанию.
Строки Python 2.x 8-битные, не более того. Кодировка может отличаться (хотя предполагается, что ASCII). Думаю, причины исторические. Некоторые языки, особенно языки прошлого века, сразу используют юникод.
В Python 3 все строки являются Unicode.
До Python 3.0 кодировка строк по умолчанию была ascii
, но ее можно было изменить. Строковые литералы Unicode были u "..."
. Это было глупо.