Имеют ли расширения файлов какое-либо назначение (для операционной системы)?


73

Linux определяет тип файла с помощью кода в заголовке файла. Это не зависит от расширений файлов, позволяющих узнать, какое программное обеспечение следует использовать для открытия файла.

Это то, что я помню из моего образования. Пожалуйста, поправьте меня, если я ошибаюсь!

Работа немного с системами Ubuntu недавно: Я вижу много файлов на системах , которые имеют расширения , такие как .sh, .txt, .o,.c

Теперь мне интересно: эти расширения предназначены только для людей? Чтобы понять, что это за файл?

Или у них тоже есть какая-то цель для операционной системы?


5
Если вы не получили хорошего ответа, помните, что есть также unix.stackexchange.com
mchid

Связанные, почти дубликаты: askubuntu.com/questions/390015/…
Zzzach ...


5
В Windows они делают, в Linux / Unix они в основном не делают. Основное исключение является компрессионной-программой - gzip, bzip2, xz- и так далее. Эти программы используют суффиксы для отделения сжатой версии файла от несжатой версии, которую они заменяют. Программы сжатия часто будут жаловаться на неправильный суффикс, даже если файл на самом деле является сжатым файлом того типа, который должен обрабатывать.
Баард Копперуд

6
Я думаю, что часть проблемы с этим вопросом заключается в том, что «операционная система» не является четко определенной концепцией. Что является частью операционной системы, и что является приложением поверх нее? Не многим частям ОС (какой бы операционной системы мы ни говорили) не важно, какой тип файла - они просто делают то, что им говорят. Так что различия в том, как они знают, не имеют значения; они не делают ни того, ни другого. Applcations, с другой стороны, вполне может сделать одну или обе вещи.
IMSoP

Ответы:


39

Linux определяет тип файла с помощью кода в заголовке файла. Это не зависит от расширений файлов, чтобы знать, с помощью программного обеспечения использовать для открытия файла.

Это то, что я помню из моего образования. Пожалуйста, поправьте меня, если я ошибаюсь!

  • правильно помнил.

Эти расширения предназначены только для людей?

  • Да, но с

Когда вы взаимодействуете с другими операционными системами, которые зависят от того, какими расширениями они являются, разумнее использовать их.

В Windows открывающее программное обеспечение прикреплено к расширениям.

Открытие текстового файла с именем «файл» в Windows , сложнее , чем открыть тот же файл с именем «file.txt» (вам нужно будет переключить диалог открытия файла с *.txtв *.*каждый раз). То же самое касается TAB и текстовых файлов, разделенных точкой с запятой. То же самое касается импорта и экспорта электронной почты (расширение .mbox).

В частности, когда вы пишете программное обеспечение. Открытие файла с именем «software1», который является файлом HTML, и «software2», который является файлом JavaScript, становится более сложным по сравнению с «software.html» и «software.js».


Если в Linux есть система, в которой важны расширения файлов, я бы назвал это ошибкой. Когда программное обеспечение зависит от расширений файлов, это можно использовать. Мы используем директиву интерпретатора, чтобы определить, что это за файл («первые два байта в файле могут быть символами« #! », Которые составляют магическое число» (шестнадцатеричные 23 и 21, значения ASCII «#» и «! ") часто упоминается как Шебанг").

Самой известной проблемой с расширениями файлов была LOVE-LETTER-FOR-YOU.TXT.vbs в Windows. Это визуальный базовый скрипт, который отображается в проводнике как текстовый файл.

В Ubuntu, когда вы запускаете файл из Nautilus, вы получаете предупреждение о том, что он собирается делать. Выполнение скрипта из Nautilus, где он хочет запустить какое-то программное обеспечение, где предполагается открыть gEdit, является очевидной проблемой, и мы получаем предупреждение об этом.

В командной строке, когда вы выполняете что-то, вы можете визуально увидеть, что такое расширение. Если это заканчивается на .vbs, я начинаю подозревать (не то, что .vbs исполняется в Linux. По крайней мере, без дополнительных усилий;)).


31
Я совершенно не понимаю, что вы хотели сказать в вашем последнем предложении. Во-первых, проблема заключается в том, чтобы скрыть расширение, а не иметь его, во-вторых, эксплойт будет работать так же в Linux - вы называете двоичный файл readme.txtи делаете его исполняемым. Если пользователь выполнил его, он не открывает редактор, но запускает код. В этом отношении создание расширений важно (но не скрывает их) более безопасно и легче для объяснения для неопытных пользователей. Существуют и другие отличия (в частности, не выполняются файлы из текущего каталога), но они не имеют ничего общего с расширениями.
Techraf

4
@techraf На самом деле файловый менеджер , вероятно, попытается открыть readme.txtфайл в текстовом редакторе. Я только что попробовал с dolphin в KDE, создав сценарий оболочки, добавив исполняемый файл, сохранив его как .txtи нажав на него, и он откроется в Kate. Если я переименую его, .shто щелчок по нему запускает его.
Бакуриу

9
Linux: поскольку make построен на основе правил, которые зависят от расширения файла, разве это не сделает (без каламбура) расширения, предназначенные не только для людей?
Болов

15
Это монументально неправильный ответ. Некоторые части Linux используют магические числа для определения типов файлов. Выполнение файлов в командной строке. Но другие огромные части системы используют расширения файлов, чтобы знать, на что обращать внимание, будь то динамический компоновщик (для которого нужны файлы .so), modprobe, системы сборки, плагины, библиотеки для python, ruby ​​и т. Д. Многие файлы не не имеет магических чисел, fileосновано на эвристике, не определено.
Алан Шутко

3
"Linux определяет тип файла через код в заголовке файла" "правильно" WTF? Какой "код в заголовке файла"? Нет такого кода, и нет такого общего "заголовка файла" в Linux.
leonbloy

68

Здесь нет 100% черного или белого ответа.

Обычно Linux не полагается на имена файлов (и расширения файлов, т.е. часть имени файла после обычно последнего периода), а вместо этого определяет тип файла, изучая первые несколько байтов его содержимого и сравнивая его со списком известных магических чисел. ,

Например, все файлы растровых изображений (обычно с расширением имени .bmp) должны начинаться с букв BMв первых двух байтах. Скрипты в большинстве языков сценариев, таких как Bash, Python, Perl, AWK и т. Д. (В основном все, что обрабатывает строки, начинающиеся с #комментария), могут содержать шебанг, как #!/bin/bashв первой строке. Этот специальный комментарий сообщает системе, с помощью какого приложения открывать файл.

Поэтому обычно операционная система полагается на содержимое файла, а не на его имя, чтобы определить тип файла, но заявить, что расширения файлов никогда не нужны в Linux, - это только половина правды.


Приложения могут, конечно, осуществлять свои проверки файлов по своему усмотрению, включая проверку имени и расширения файла. Примером является Eye of Gnome ( eogстандартный просмотрщик изображений), который определяет формат изображения по расширению файла и выдает ошибку, если он не соответствует содержимому. Будь то ошибка или особенность, можно обсудить ...

Однако даже некоторые части операционной системы полагаются на расширения имен файлов, например, при разборе исходных файлов вашего программного обеспечения /etc/apt/sources.list.d/- *.listанализируются только файлы с расширением, все остальные игнорируются. Возможно, он в основном используется не для определения типа файла, а для включения / отключения анализа некоторых файлов, но это все еще расширение файла, которое влияет на то, как система обрабатывает файл.

И, конечно, прибыль пользователей человека большинство из расширений файлов , как это делает тип файла очевидного , а также позволяет использовать несколько файлы с тем же базовым именем и различные расширения , такими как site.html, site.php, site.js, site.cssрасширение и т.д. Недостатком является то, конечно , этим файлом и фактическим Тип файла / содержание не обязательно должны совпадать.

Кроме того, это необходимо для межплатформенного взаимодействия, например, Windows не будет знать, что делать с readmeфайлом, а только a readme.txt.


Вы немного себе тут противоречите: если стандартному средству просмотра изображений требуется имя файла, оканчивающееся на .bmp, какая часть ОС, по вашему мнению, зависит от содержимого файла, начинающегося с «BM»? AFAIK, единственные «магические числа, о которых заботится ядро, - это исполняемые типы, включая особый случай #!. Все остальное зависит от решения какого-либо приложения.
IMSoP

@IMSoP Я не знаю точную реализацию, eogи я не знаю, почему они вообще заботятся об имени файла. Это ошибка на мой взгляд. И, конечно, если файл называется «bmp», но его формат содержимого не совпадает, конечно, также будет ошибка. Конечно, каждое приложение решает, как проверять файлы, но в целом приложения Linux не должны полагаться на имя. Кстати, вы можете использовать filecommend для проверки типов файлов по их содержимому.
Byte Commander

1
Предложение, которое я оспариваю, таково: «Linux ... определяет тип файла, анализируя первые несколько байтов». Какое определение «Linux» вы используете в этом предложении? Существование fileутилиты на самом деле ничего не доказывает; это полезный инструмент, который может существовать в любой ОС. Какая фундаментальная часть ОС делает работу fileболее «правильной», чем использование имени файла?
IMSoP

Обратите внимание, что файлы без расширения могут быть связаны с программой.
Исана

24

Как уже упоминалось другими, в Linux используется метод директивы интерпретатора (сохранение некоторых метаданных в файле в виде заголовка или магического числа, чтобы правильному интерпретатору можно было прочитать его), а не метод ассоциации расширения имени файла, используемый Windows.

Это означает, что вы можете создать файл с почти любым именем, которое вам нравится ... с несколькими исключениями

тем не мение

Я хотел бы добавить слово предостережения.

Если в вашей системе есть файлы из системы, в которой используется сопоставление имен файлов, файлы могут не иметь этих магических чисел или заголовков. Расширения имен файлов используются для идентификации этих файлов приложениями, которые могут их прочитать, и вы можете столкнуться с некоторыми неожиданными эффектами, если переименовать такие файлы. Например:

Если вы переименуете файл My Novel.docв My-Novel, Libreoffice все равно сможет его открыть, но он откроется как «Без названия», и вам придется снова присвоить ему имя, чтобы сохранить его (Libreoffice добавляет расширение по умолчанию, так что вы должны иметь два файла My-Novelи My-Novel.odt, которые могут быть раздражающими)

Если серьезно, если вы переименуете файл My Spreadsheet.xlsx в My-Spreadsheet, то попробуйте открыть его вместе с xdg-open My-Spreadsheetвами, и вы получите следующее (потому что это на самом деле сжатый файл):

И если вы переименуете файл My Spreadsheet.xlsв My-Spreadsheet, когда xdg-open My-Spreadsheetвы получите сообщение об ошибке

Ошибка открытия местоположения: ни одно приложение не зарегистрировано для обработки этого файла

(Хотя в обоих случаях это работает нормально, если вы делаете soffice My-Spreadsheet)

Если переименовать файл extensionless к My-Spreadsheet.odsс mvи попытаться открыть его , вы получите это:

(ремонт не удается)

И вам придется снова установить оригинальное расширение, чтобы правильно открыть файл (затем вы можете преобразовать формат, если хотите)

TL; DR:

Если у вас есть неродные файлы с расширениями имени, не удаляйте расширения, если все будет в порядке!


4
Новый документ MS Office (docx, xlsx, pptx и т. Д.) Без расширения файла открывается в диспетчере архивов, поскольку эти типы файлов на самом деле представляют собой обычные сжатые файлы ZIP, которые содержат все документы XML и файлы мультимедиа, необходимые для определения содержимого документа. Кстати, формат файла ZIP-архива довольно распространен.
Байт-командир

1
Уже много хороших ответов, но я заметил еще один специфический для libreoffice. Вы создаете файл с разделенными запятыми значениями (CSV) и сохраняете его как «test.csv», откроется окно с вопросом, какой тип разделителя вы используете (например, libreoffice Calc). Если вы, например, переименуете этот файл в «test.cs», то Writer libreoffice откроет его. Таким образом, помимо приведенного выше примера ZIP, похоже, что libreoffice использует расширение файла.
Рэй

3
Файловая система linux ничего не делает в отношении типов файлов. Это все до программ, работающих поверх него.
Питер Грин

@PeterGreen Да, но тот факт, что программы действительно присваивают ему значение, означает, что это не «просто для людей», как это было, например, у классического MacOS [там были четырехбайтовые поля «тип файла» и «приложение-создатель», которые не были t часть имени файла, поэтому ОС и приложения имели всю необходимую информацию, не
обращая внимания

3
@PeterGreen Файловая система Windows также ничего не делает с типами файлов. Графическая оболочка (Windows Explorer) использует расширение файла, чтобы выбрать действие для двойного щелчка, но технически это просто программа, работающая поверх операционной системы, как и Nautilus. Было бы вполне возможно написать файловый менеджер Linux с таким поведением или Windows, который проверял содержимое файла.
IMSoP

20

Я хотел бы использовать другой подход к этому из других ответов и оспорить идею о том, что «Linux» или «Windows» имеют какое-либо отношение к этому (терпите меня).

Понятие расширения файла может быть просто выражено как «соглашение для идентификации типа файла на основе части его имени». Другие общие соглашения для определения типа файла сравнивают его содержимое с базой данных известных сигнатур (подход «магического числа») и сохраняют его как дополнительный атрибут в файловой системе (подход, используемый в оригинальной MacOS) ,

Поскольку каждый файл в системе Windows или Linux имеет как имя, так и содержимое, процессы, которые хотят знать тип файла, могут использовать подходы «расширение» или «магическое число» по своему усмотрению. Подход метаданных обычно недоступен, так как в большинстве файловых систем нет стандартного места для этого атрибута.

В Windows существует сильная традиция использовать расширение файла в качестве основного средства идентификации файла; Наиболее заметно, что графический файловый браузер (File Manager в Windows 3.1 и Explorer в современной Windows) использует его, когда вы дважды щелкаете файл, чтобы определить, какое приложение запустить. В Linux (и, в более общем случае, в системах на основе Unix), существует больше традиций для проверки содержимого; в частности, ядро ​​смотрит на начало файла, который выполняется непосредственно, чтобы определить, как его запустить; Файлы сценариев могут указывать на использование интерпретатора, начиная с имени, #!за которым следует путь к интерпретатору.

Эти традиции влияют на дизайн пользовательского интерфейса программ, написанных для каждой системы, но есть множество исключений, потому что у каждого подхода есть свои плюсы и минусы в разных ситуациях. Причины использования расширений файлов вместо изучения содержимого включают в себя:

  • проверка содержимого файла довольно затратна по сравнению с проверкой имен файлов; так, например, «найти все файлы с именем * .conf» будет намного быстрее, чем «найти все файлы, первая строка которых соответствует этой подписи»
  • содержимое файла может быть неоднозначным; многие форматы файлов на самом деле представляют собой просто текстовые файлы, обрабатываемые особым образом, многие другие представляют собой специально структурированные zip-файлы, и определение точных сигнатур для них может быть сложным
  • файл действительно может быть действительным как более одного типа; HTML-файл также может быть допустимым XML, ZIP-файл и GIF, объединенные вместе, остаются действительными для обоих форматов.
  • совпадение магических чисел может привести к ложным срабатываниям; формат файла без заголовка может начинаться с байта "GIF89a" и быть неверно идентифицирован как изображение GIF
  • переименование файла может быть удобным способом пометить его как «отключенный»; например, изменив «foo.conf» на «foo.conf ~», чтобы указать, что резервное копирование проще, чем редактирование файла, чтобы закомментировать все его директивы, и более удобно, чем перемещение его из каталога с автозагрузкой; аналогично, переименование файла .php в .txt скажет Apache, чтобы он служил своим источником в виде простого текста, а не передавал его движку PHP.

Примеры программ Linux, которые используют имена файлов по умолчанию (но могут иметь другие режимы):

  • gzip и gunzip имеют специальную обработку любого файла, оканчивающегося на ".gz"
  • gcc будет обрабатывать файлы ".c" как C, а ".cc" или ".C" как C ++

В Windows также существует сильная традиция скрывать расширение, если оно «хорошо известно», и даже DOS позволяет командам пропускать .COM, .BAT и .EXE, автоматически ища их, чтобы определить, какую именно программу следует выполнить. В * nix такой традиции нет.
Монти Хардер

Это гораздо лучший ответ, но есть одна фактическая ошибка ... сценарий нельзя сделать исполняемым, поместив его #!в начале. Любой файл с его набором исполняемых битов может быть выполнен одним из нескольких способов. #!/bin/bashи подобные подписи просто указывают, какой интерпретатор использовать. Если такая подпись не указана, подразумевается интерпретатор оболочки по умолчанию. Файл, содержащий только два слова «Hello World», но с установленным битом выполнения, при запуске попытается найти команду «Hello».
DocSalvager

1
@DocSalvager Хороший улов, это была неуклюжая формулировка так же, как и все остальное. Я немного перефразировал это, чтобы прояснить, что шебанг не делает сценарий исполняемым, он просто меняет способ его выполнения.
IMSoP

15

На самом деле, некоторые технологии действительно полагаться на расширениях файлов, так что если вы используете эти технологии в Ubuntu, вам придется полагаться на расширениях тоже. Несколько примеров:

  • gccиспользует расширения, чтобы различать файлы C и C ++. Без расширения их практически невозможно дифференцировать (представьте себе файл C ++ без классов).
  • много файлов ( docx, jar, apk) только особенно структурированы ZIP архивы. Хотя вы обычно можете определить тип по содержимому, это не всегда возможно (например, Java Manifest не является обязательным в jarфайлах).

Не использовать расширения файлов в таких случаях будет возможно только с помощью хакерских обходных путей и, вероятно, будет очень подвержен ошибкам.


Хорошо, что вы упомянули программирование, но вы ошиблись в большинстве деталей. gccявляется внешним интерфейсом для файлов C, для файлов C ++ вам нужен либо внешний g++интерфейс, либо переключатель командной строки для указания языка. Более важной является makeпрограмма, которая решает, использовать ли gccили g++создать конкретный файл, и makeполностью зависит от шаблонов имен файлов (в основном, от расширений) для соответствия правилам.
Бен Фойгт

@BenVoigt При компиляции файла с .ccрасширением gccон действительно будет скомпилирован как C ++, и это задокументировано в man gcc: «Для любого входного файла суффикс имени файла определяет, какой тип компиляции выполняется:», за которым следует список расширения и как они рассматриваются.
2016 года

1
@hvd Тогда, может быть, это набор библиотек по умолчанию, который идет ужасно неправильно, если вы не используете правильный интерфейс. В любом случае, make является основным примером, потому что все, что он делает, основано на расширении файла.
Бен Фойгт

1
@BenVoigt makeтакже хороший пример, но он gccтакже сильно зависит от имен файлов. Вот пример, более понятный, чем .cvs .cc: Для C gccиспользует суффиксы, чтобы указать, является ли его первым шагом preprocess ( .c), compile ( .i), assembly ( .s) или link ( .o). Здесь я использую -E, -Sи -cсказать , gccгде остановиться , но он использует имена файлов , чтобы знать , где начать . gcc something.ccне будет ссылаться на нужные библиотеки для C ++, но будет рассматривать файл как C ++, поэтому многих пользователей смущают сообщения об ошибках, которые они получают при совершении этой ошибки.
Элия ​​Каган

7

Ваше первое предположение верно: расширения в Linux не имеют значения и полезны только для людей (и других не-Unix-подобных ОС, которые заботятся о расширениях). Тип файла определяется первыми 32 битами данных в файле, которые известны как магическое число. Вот почему сценариям оболочки требуется #!строка - чтобы сообщить операционной системе, какой интерпретатор вызывать. Без него сценарий оболочки - это просто текстовый файл.

Что касается файловых менеджеров, они хотят знать расширения некоторых файлов, таких как .desktopфайлы, которые в основном совпадают с версией ярлыков Windows, но имеют больше возможностей. Но что касается ОС, она должна знать, что находится в файле, а не в его названии.


3
Это не совсем так. Есть программы, которые ожидают определенного расширения. Наиболее часто используемый пример, вероятно gunzip, не распаковывает файл, если он не вызывается foo.gz.
Тердон

Это реализация конкретного программного обеспечения. По большей части утилиты в Unix-подобных системах не ожидают расширения.
Сергей Колодяжный

7
По большей части они этого не делают. Ваше первое предложение, однако, утверждает, что они никогда не используются и имеют значение только для людей. Это не совсем так. gunzipэто один пример, eogэто другой. Кроме того, многие инструменты не будут автозаполнять имена без правильного расширения. Все, что я говорю, это то, что это немного сложнее, чем «расширения всегда не имеют значения».
Тердон

1
1 маленькая проблема: ОП спросил об операционной системе. 'gunzip' и 'eog' не являются операционной системой, но решили создать свои собственные ограничения (в случае gunzip) или метод (eog). "типы пантомимы" все же.
Rinzwind

1
@ Serg Конечно, вы можете узко определить ОС и получить тривиальный ответ на вопрос. Это не особенно полезный ответ, потому что подавляющее большинство того, что пользователь делает с компьютером, связано с программным обеспечением, которое вы исключили. Обратите внимание, что этот вопрос противопоставлен «только для людей» против «операционной системы»; Я не думаю, что они имели в виду «ядро».
IMSoP

6

Это слишком большой ответ на комментарий.

Имейте в виду, что даже «расширение» имеет много, если разные значения.

То, о чем вы говорите, похоже, состоит из 3 букв после. DOS сделал формат 8.3 по-настоящему популярным, и в Windows по сей день используется часть .3.

В Linux есть много файлов, таких как .conf или .list или .d или .c, которые имеют значение, но на самом деле не являются расширениями в смысле 8.3. Например, Apache ищет директиву конфигурации в /etc/apache2/sites-enabled/website.conf. В то время как система использует MIME-типы и заголовки содержимого, а не то, чтобы определить, что это текстовый файл, Apache (по умолчанию) по-прежнему не будет загружать его без окончания в .conf.

.c еще один замечательный. Да, это текстовый файл, но gcc зависит от main.c, который становится main.o и, наконец, main (после связывания). Система ни разу не использует расширение .c, .o или no, чтобы иметь какое-либо значение для содержимого, но для содержимого после. действительно имеет какое-то значение. Вы, вероятно, настроите свой SCM на игнорирование main.o и main.

Дело в том, что расширения не используются так, как в окнах. Ядро не выполнит файл .txt, потому что вы удалите часть имени .txt. Также очень рад выполнить файл .txt, если установлено разрешение на выполнение. При этом, они имеют значение, и все еще используются на «компьютерном уровне» для многих вещей.


1
Окна также не привязаны к x.3схеме именования больше, вы получили больше расширений там, а как .doxc, .torrent, .partи т.д. Это просто , что многие форматы файлов и расширения уже были определены еще в то время , когда 8,3 именование было еще вещь , и позже форматы в основном просто адаптировали соглашение использования до 3 букв.
Byte Commander

Я не вижу, как «.conf», «.c» и т. Д. Являются «иным значением», чем «смысл 8.3». Понятие расширения файла может быть просто выражено как «соглашение для идентификации типа файла на основе части его имени». Даже DOS / Win3.1 не требовали правильного расширения (вы можете вызвать документ Word «STUPIDN.AME» и открыть его с помощью Ctrl-O в WinWord). Просто некоторые системы (например, двойной щелчок по Windows, gzipваш Makefile и т. Д.) Могут быть написаны для использования этого соглашения, чтобы делать предположения о правильном действии для каждого файла.
IMSoP

@ByteCommander Это правда, но расширение все еще определяет используемое приложение. Я не уверен, как отредактировать ответ, чтобы отразить это.
Coteyr

1
@coteyr Опять же, все зависит от того, что мы подразумеваем под «ОС». Файловый менеджер , безусловно , искать ключ реестра для «AME», и скажет мне , что «foo.txt» представляет собой текстовый файл. Но запуск dirиз командной строки не скажет мне ничего подобного; это просто не волнует. Выполнение файлов, безусловно, является исключением в обеих ОС; если бы вопрос был ограничен этими вопросами, то ответом было бы то, что DOS / Windows заботится только о имени, а Unix / Linux - только разрешение на выполнение и первые байты файла. Помимо этого, всегда есть какое-то приложение, выбирающее соглашение, которому нужно следовать.
IMSoP

1
@coteyr Вы забыли * .scr (бинарная заставка) в Windows 3.1 и выше. Тем не менее, расширение файла даже в системах DOS / Windows, даже для исполняемых файлов, по- прежнему просто удобство. Специфика очень сильно зависит от того, где вы проводите линию «операционной системы», но вы всегда можете загрузить двоичный файл в память и самостоятельно перейти к нему, выполняя работу, которую обычно просят ОС. В MS-DOS, если вы посмотрите на command.com, я почти уверен, что есть список, такой как EXE COM, который вы можете редактировать так, чтобы он искал другие расширения, если они не указаны (не говоря уже о том, что это будет хорошей идеей, имейте ввиду).
CVn
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.