Кодировка русских букв в html: Кодировка HTML-страницы — Структура HTML-документа

Содержание

java — В html странице выводятся знаки вопрос вместо русских букв

Вопрос задан 1 год 4 месяца назад

Изменён 1 год 4 месяца назад

Просмотрен 266 раз

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

Что я уже попробовал:

Убедился что консоль в ответ на запрос выдаёт 866
Также в параметрах регионального стандарта, во вкладке дополнительно я нажал кнопку «изменить язык системы» и там снял галку с параметра «Бета-версия: Использовать Юникод (UTF-8) для поддержки языка во всем мире.» Сохранил и перезагрузил.
В фалйах idea.exe.vmoptions и idea64.exe.vmoptions Добавил следующую строку: -Dfile.encoding=UTF-8

Так же добавил её в редакторе Idea > EditConfigurations > Tomcat > VM options Так же добавил её в редакторе Idea > Help > Edit Custom VM Options

Так же в настройках File > Settings > FileEncodings выставил Global Encoding в UTF-8 Project Encoding в UTF-8 Default encoding for project files: UTF-8 Create UTF-8 files with NO BOOM
В правом нижнем углу редактора так же выставил UTF-8
Проверил что в хедере моего index.html который я пытаюсь отобразить стоит <meta charset="UTF-8">
Так же пересохранил на всякий случай мой index.html с помощью блокнота с кодировкой UTF-8
Запустил саму страницу index.html двойным кликом в папке и она нормально отображает кнопку с руским языком, а так же тестовый текст с русским языком.
однако когда я нажимаю в idea кнопку run Tomcat почему то страница показывает знаки вопроса вместо русских букв

java
html
intellij-idea
tomcat

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки

Загружаю страницу html менеджером файлов, получаю вместо всех русских букв черные ромбики — Вопрос от Юрий Новиков

Вопросы
Горячие
Пользователи
Вход/Регистрация

Категории вопросов

Задать вопрос +

Основное

Вопросы новичков (16522)
Платные услуги (2132)
Вопросы по uKit (82)

Контент-модули

Интернет-магазин (1433)

Редактор страниц (236)
Новости сайта (499)
Каталоги (808)
Блог (дневник) (112)
Объявления (295)
Фотоальбомы (433)
Видео (255)
Тесты (60)
Форум (578)

Продвижение сайта

Монетизация сайта (220)
Раскрутка сайта (2455)

Управление сайтом

Работа с аккаунтом (5322)

Поиск по сайту (426)
Меню сайта (1765)
Домен для сайта (1533)
Дизайн сайта (13471)
Безопасность сайта (1483)
Доп. функции (1308)

Доп. модули

SEO-модуль (225)
Опросы (63)
Гостевая книга (99)
Пользователи (433)
Почтовые формы (318)
Статистика сайта (198)

Соц. постинг (212)
Мини-чат (91)

Вебмастеру

JavaScript и пр. (644)
PHP и API на uCoz (235)
SMS сервисы (10)
Вопросы по Narod. ru (429)
Софт для вебмастера (39)

…

DOCTYPE и кириллица — HTML и CSS — Форумы SitePoint

Форумы SitePoint | Сообщество веб-разработки и дизайна

танцы_матильда 22 сентября 2010 г., 7:05

Привет,
Хочу написать чистые xhtml страницы под кириллицу и не могу найти как какой DOCTYPT использовать и какой тег в шапке для языка.

Я просто меняю EN в DOCTYPE на RU?
Что лучше сделать понятным, что это кириллица в шапке страницы?

Спасибо за ответы и советы.
Танцующая Матильда

Ральф 22 сентября 2010 г., 7:20

танцующая_матильда:

Я просто меняю EN в DOCTYPE на RU?

Я думаю, что это правильно, но я не буду на этом ругаться. Я определенно видел это раньше:

 
[COLOR="Красный"][/COLOR]

Вот очень старая, но все еще полезная ветка на эту тему, которая может оказаться полезной:

Форумы SitePoint | Сообщество веб-разработки и дизайна

Сообщество веб-дизайнеров и разработчиков для обсуждения всего, от HTML, CSS, JavaScript, PHP до Photoshop, SEO и многого другого.

система 22 сентября 2010 г., 7:31

здесь речь идет о кодировке, а не о DTD.

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

, тогда вам нужно заставить сервер отправлять соответствующую информацию о кодировке: директивы AddType или AddDefaultCharset для Apache. при этом строка в заголовке HTTP будет выглядеть так: Content-Type: text/html; кодировка=utf-8. как вы увидите, также рекомендуется поместить эту информацию заголовка в раздел заголовка на вашей странице.

и, наконец, вы должны включить их на свою страницу:


<голова>

вы можете использовать более мелкую кириллицу, например, iso-8859-5 или windows-1251, но utf-8 является более безопасным вариантом.

Stomme_poes 22 сентября 2010 г., 7:36

noonope прав: и вы НЕ меняете «EN» в типе документа!
Это не часть набора символов. Вместо этого это связано с опубликованным языком DTD.

Держите тип документа таким же, как на любой западной, азиатской или любой другой странице, и установите свой язык, как сказал noonope: с атрибутом lang в теге HTML (или также с атрибутами xml: lang, если вы пишете XHTML), мета content-lang и, самое главное, на вашем сервере (если сервер и ваши метатеги конфликтуют, сервер побеждает).

Наконец, единственное, о чем noonope не упомянул, это сохранение вашего документа также в UTF-8 (или меньшей кодировке, если вы выберете другую кодировку — просто держите их все совместимыми друг с другом). Если редактор документа сохраняет в какой-то другой кодировке, а сервер пытается отправить в другой кодировке, пользователь увидит много ??? повсюду.

, вы можете использовать более узкую кодировку, например iso-8859-5 или windows-1251, но utf-8 является более безопасным вариантом.

Гораздо безопаснее… Я не использую Windows, поэтому мой компьютер не всегда хорошо справляется с кодировками только для Windows (1251, 1252).

танцующая_матильда 22 сентября 2010 г., 8:18

Большое спасибо за полезную информацию.
«Stomme poes»: ??? Заметил в браузере
Еще раз спасибо.

система 22 сентября 2010 г., 8:35

Stomme_poes:

Наконец, единственное, о чем noonope не упомянул, это сохранение вашего документа также в UTF-8 (или меньшей кодировке, если вы выберете какую-то другую кодировку — просто держите их все совместимыми друг с другом). Если редактор документа сохраняет в какой-то другой кодировке, а сервер пытается отправить в другой кодировке, пользователь увидит много ??? повсюду.

но я сделал…

сначала ваша страница должна быть написана и закодирована с использованием utf-8

Stomme_poes 22 сентября 2010 г., 8:47

Ах да… Я думаю об этом только как о «сохранении как», потому что в большинстве редакторов кодировка устанавливается при сохранении. Но это также может отличаться для каждого редактора.

система 22 сентября 2010 г., 10:47

я использую notepad++ для html и css. в нем вы можете изменить кодировку вашего файла на лету, используя параметры в меню «Кодировка». и я установил по умолчанию для нового файла в notepad++ значение UTF-8 без спецификации. так что не сохраняйте, как для меня:)

это важная часть для контента, отличного от ANSI, на вашей веб-странице: запуск документа в кодировке UTF-8 для вашей страницы, и поэтому я поставил его первым:

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

если вы обслуживаете такой файл как UTF-8 на стороне сервера, этого должно быть достаточно. на самом деле нет необходимости в lang=»ru» или charset=utf-8, по крайней мере, чтобы не гарантировать правильное отображение символов на вашем сайте

xhtmlcoder 22 сентября 2010 г. , 11:27

Я полагаю, вы имеете в виду, что хотели бы изменить человеческий язык, используемый на всей странице, а не использовать комбинацию языков на странице?

Например, азбука, ISO-8859-5, как упоминалось ранее, вы обычно устанавливаете параметр «charset» поля заголовка «Content-Type» протокола HTTP.

В противном случае в (x)html вы, вероятно, использовали бы объявления META Content-Type, которые должны появляться как можно раньше в элементе HEAD, то есть перед TITLE. В качестве окончательной защиты от сбоев вы можете использовать атрибут «charset».

. . .
«ru»>
. . .

Другими словами, если есть конфликт между несколькими объявлениями кодировки в XHTML, следует:

Заголовок HTTP Content-Type
метка порядка байтов (BOM)
XML-декларация
метаэлемент
атрибут кодировки ссылки

Как уже упоминалось, обычно UTF-8 обычно охватывает большинство вещей, хотя в некоторых случаях могут быть проблемы с отображением из-за шрифтов/глифов, в некоторых языках и т. д.

Unicode, как правило, не включает кириллические буквы с диакритическими знаками. Кодировка KOI8-R популярна для русского текста и используется чаще, чем ISO-8859-5, но поддержка Unicode замедляет их замену.

Не используйте только наборы символов Windows, они абсолютно злые!

Поэс, вероятно, имел в виду «символ замены» — (часто черный ромб с белым вопросительным знаком) символ, встречающийся в стандарте Unicode в кодовой точке U+FFFD в таблице Specials.

Stomme_poes 22 сентября 2010 г., 13:59

#10

lang=»ru»,
на самом деле не нужен

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

или кодировка=utf-8,

Я всегда включаю его по двум причинам:

проверка
У меня нет контроля над сервером, и я хочу, чтобы несоответствия появлялись, когда на сервере устанавливают дурацкие кодировки. Я также жестко кодирую все свои символы, отличные от ASCII, с десятичными объектами HTML для тех, которые всегда должны отображаться правильно.
Это правда, что если ваш сервер настроен правильно, метатеги не нужны, так как браузер их проигнорирует, но валидатор настаивает на этом.

Поэс, вероятно, имел в виду «замещающий символ» — (часто черный ромб с белым вопросительным знаком) символ, встречающийся в стандарте Unicode в кодовой точке U+FFFD в таблице Specials.

Я заметил, что Safari использует странный вариант, а в машине Doze просто пустые ящики.
Когда есть несоответствие символов, вы можете получить �, но если у вас нет шрифта в системе, по крайней мере, в Linux, вы получите поле с маленькими символами в нем.

система 22 сентября 2010 г., 14:02

#11

xhtmlcoder:

Юникод, как правило, не включает буквы кириллицы с диакритическими знаками.

провел небольшое исследование, и я думаю, что это стоит упомянуть:

Unicode не включает кириллические буквы с ударением, но их можно комбинировать, добавляя U+0301 («сочетание острого ударения») после ударной гласной (например, ы́ э́ ю́ я́). Некоторые языки, в том числе современный церковнославянский, до сих пор не полностью поддерживаются.

www.google.ru также использует utf-8. я думаю, можно с уверенностью предположить, что utf-8 можно использовать для кириллических страниц.

Stomme_poes 22 сентября 2010 г. , 14:07

#12

Unicode не включает кириллические буквы с ударением, но их можно комбинировать, добавляя U+0301 («сочетание острого ударения») после ударной гласной (например, ы́ э́ ю́ я́). Некоторые языки, в том числе современный церковнославянский, до сих пор не полностью поддерживаются.

Это проблема. Есть много персонажей, которые могут быть представлены либо как один персонаж, либо как комбинация двух. Там буква, я думаю, это была маленькая j, но с циркумфлексом вместо точки сверху? Или какая-то похожая буква, где была двухсимвольная комбинация для прописных букв, но не для строчных, или наоборот… Я читал об этой конкретной букве в книге по регулярным выражениям. Регулярные выражения могут блевать на эти различия. Почему я боюсь зайти слишком далеко в регулярных выражениях и юникоде!

Я думаю, можно с уверенностью предположить, что utf-8 можно использовать для кириллических страниц.

Я бы хотел.

система 22 сентября 2010 г., 14:09

№13

Stomme_poes:

На самом деле есть. Программы чтения с экрана и другие а11ы должны обращать внимание на атрибуты языка, и они это делают.
Я всегда включаю его по двум причинам:
проверка
У меня нет контроля над сервером, и я хочу, чтобы несоответствия появлялись, когда на сервере устанавливают дурацкие кодировки.

ты прав, но…

на самом деле нет необходимости в lang=»ru» или charset=utf-8, по крайней мере, чтобы не гарантировать правильное отображение символов на вашем сайте

я пытался убедиться, что OP понимает:

каковы минимальные требования для создания кириллической веб-страницы: текстовый файл, содержащий страницу, должен быть правильно закодирован и отправлен с заголовком соответствующего типа содержимого.
какие еще включения для: lang, meta

и ваши дополнения были действительно необходимы, чтобы сделать вещи еще более ясными, есть случаи, когда это необходимо.

Хроникмастер1 22 сентября 2010 г., 23:39

№14

Для тех, кто хочет перейти к делу, вот код, который я использую неукоснительно. Я использую XHTML, поэтому мне нужно включить атрибуты lang и xml:lang в тег html. Вы определяете набор символов в метатеге следующим образом.



     <голова>

« 0″ encoding=»UTF-8″?>» до того, как тип документа будет технически правильным для определения набора символов. Однако это приводит к тому, что IE (или, по крайней мере, некоторые версии) плавится в маленькие лужицы нефункциональной слизи, поэтому я никогда не использовал его и не рекомендую. Я не использовал метатег для определения языка, однако, не зная какой-либо ключевой причины для его включения, определение любого параметра в нескольких местах является плохой практикой. Как только один обновится, а другой нет, ваша страница будет противоречить сама себе, что может привести к проблемам.

полдень:

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

Я думаю, мы должны вернуться к этому. Это настоящая причина, по которой вы используете utf-8. Существуют всевозможные тонкие сбои, которые могут возникнуть, если вы попытаетесь закодировать одну страницу в одной кодировке, а другую страницу на том же сайте — в другой. Попытка использовать два разных языка на одной странице может сработать в зависимости от того, какие именно символы вы используете, и от того, доступны они или нет… ха-ха… попробуйте следить за ЭТОЙ частью обслуживания на страницах вашего веб-сайта. Это кошмар, из-за которого люди в первую очередь создали Unicode, и я постоянно использую его на всех своих страницах на всех своих веб-сайтах. В редких случаях может возникнуть небольшая проблема, но это ничто по сравнению с попытками управлять альтернативами, особенно если вы создаете веб-сайт для международного использования.

Обратите внимание, что это не означает, что вы всегда будете получать хорошее отображение при использовании Unicode. Использование Unicode просто означает, что когда HTTP-ответ, который вы отправляете в браузеры посетителей, с большей вероятностью будет понят, чем при использовании любого другого метода. К сожалению, отрисовка символов ТАКЖЕ зависит от поддержки шрифтов на компьютере посетителя. Поэтому, если вы используете Unicode, но на вашем компьютере нет шрифтов, содержащих эти глифы, вы увидите вопросительные знаки, или маленькие прямоугольники, или квадраты с четырехзначным кодированием Unicode, или любой другой подстановочный знак, который использует ваша ОС. Это не вина Unicode, это проблема со шрифтом. Другой набор символов не будет лучше отображаться, потому что проблема заключается в отсутствии поддержки шрифтов; плюс у вас есть дополнительная проблема, заключающаяся в том, что набор символов, скорее всего, вызовет проблемы.

Вы также можете сделать все правильно, но если ваш веб-хост обслуживает заголовки контента, в которых указан другой набор символов, он переопределит настройки в вашем XHTML. Вам нужно будет связаться с вашим веб-хостингом, чтобы исправить эту ситуацию (и есть некоторые веб-хосты, которые отказываются). К счастью, это гораздо реже, чем раньше, потому что Unicode наконец-то становится доминирующим стандартом.

Также ВСЕГДА следует указывать язык документа. Вероятно, есть какая-то логика, которая по умолчанию использует английский или что-то в этом роде, но вы можете вызвать серьезные проблемы с удобством использования и доступностью, особенно для небраузерных интерфейсов. Поработав в Институте Брайля, я могу привести пару случаев, когда не указание языка или его неправильное выполнение приводило к полной тарабарщине для некоторых пользователей.

Программы голосового вывода читают пользователям содержимое экрана. У них совершенно разный код, записи, акценты и т. д. в зависимости от указанного вами языка. Если вы сделаете это неправильно, он попытается прочитать английский как французский, русский как английский и т. д. Результат обычно неразборчив.
Дисплеи Брайля отображаются совершенно по-разному в зависимости от языка; это даже не проблема конкретной технологии, а проблема шрифта Брайля. Символы Брайля совершенно разные в каждом языке. Кто-то может выучить английский шрифт Брайля и читать книги по Брайлю; однако, если они возьмут в руки книгу, написанную французским шрифтом Брайля, все, что они смогут разобрать, — это тарабарщина, даже если они свободно говорят по-французски, символы на самом деле означают совершенно разные комбинации букв. А если английский и французский несовместимы, то можно понять проблемы для неевропейских языков.

фелгалл 23 сентября 2010 г., 2:14

№15

Хроникмастер1:

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

Единственными версиями IE, которым не нравится этот тег, являются версии, которые вообще не поддерживают XHTML. У него нет проблем ни в одном браузере, который на самом деле поддерживает XHTML.

Самая ранняя версия IE, действительно поддерживающая XHTML, — IE9. Во всех более ранних версиях вы не можете использовать страницу как XHTML и отображать ее в Internet Explorer (она будет предложена для загрузки, если вы попробуете), поэтому вам придется загружать ее как HTML, если вы хотите, чтобы страница отображалась. Это утверждение недействительно для HTML, но только IE6 действительно имеет какие-либо проблемы с его наличием.

Stomme_poes 23 сентября 2010 г., 6:26

№16

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

К сожалению, у меня нет нидерландского голоса на моей копии JAWS (если только я не хочу платить около тысячи евро). Для тестирования JAWS любой из моих рабочих страниц это означает, что я должен перевести все, что хочу протестировать, на английский язык. За голландским, произносимым как английский, очень сложно следить.

Дисплеи Брайля отображаются совершенно по-разному в зависимости от языка; это даже не проблема конкретной технологии, а проблема шрифта Брайля. Символы Брайля совершенно разные в каждом языке. Кто-то может выучить английский шрифт Брайля и читать книги по Брайлю; однако, если они возьмут в руки книгу, написанную французским шрифтом Брайля, все, что они смогут разобрать, — это тарабарщина, даже если они свободно говорят по-французски, символы на самом деле означают совершенно разные комбинации букв. А если английский и французский несовместимы, то можно понять проблемы для неевропейских языков.

Классная информация. Мне всегда было интересно, похоже ли это на язык жестов (разные на разных языках).

Этот оператор недействителен для HTML, но только у IE6 есть какие-либо проблемы с его наличием.

Да, они научили IE7 игнорировать XML-тег, хотя другие комментарии перед типом документа переводят 7 в Quirks Mode.

танцующая_матильда 23 сентября 2010 г., 6:48

# 17

Большое спасибо за приведенное выше обсуждение, многому научился из него

Я посмотрел настройки сервера и могу выбрать 3 варианта:

k 018-r
окна-1251
x-mac-кириллица

Насколько я понял выше (и понял), лучше всего выбрать вариант «k 018-r».
В html-документе я начинаю с (и удаляю красный код, как объяснил felgall):

Stomme_poes 23 сентября 2010 г. , 8:23

# 18

Ну уж точно не хотите lang=»en» на русскоязычном сайте!

Но вам нужны lang=»ru» и xml:lang=»ru»!

Примечание: почему переходный тип документа? Используйте строго! : )

Примечание 2: наши теги кода (и другие теги) используют квадратные скобки

xhtmlcoder 23 сентября 2010 г., 10:02

# 19

Стивен пошутил о том, что большинство живых версий M$IE не могут обрабатывать XHTML, поэтому, вероятно, выступал за HTML 4.01.

 
   
   [B][/B]
     <голова>
       
       <название>
         Жадный волшебник
       
     
     <тело>

Если вы пишете грамматику XHTML, необходимо, чтобы у вас было пространство имен xml, и обычно рекомендуется добавить значения xml:lang и lang. XHTML обычно использует по умолчанию UTF-8 в отсутствие других протоколов более высокого уровня и т. д.

система 23 сентября 2010 г., 10:12

#20

должно быть, насколько я понимаю, у вас есть

а у вас должно быть

или

подробнее об этом здесь.

следующая страница →

`URL-Кодировка «кириллицы» — Онлайн`

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

URL-кодирование, также известное как «процентное кодирование», представляет собой механизм кодирования информации в универсальном идентификаторе ресурса (URI). Хотя это известно как URL-кодирование, на самом деле оно более широко используется в основном наборе унифицированных идентификаторов ресурсов (URI), который включает в себя как унифицированный указатель ресурса (URL), так и унифицированное имя ресурса (URN). Как таковой он также используется при подготовке данных медиа-типа «application/x-www-form-urlencoded», который часто используется при отправке данных формы HTML в HTTP-запросах.

Дополнительные параметры

Набор символов: Наш веб-сайт использует набор символов UTF-8, поэтому ваши входные данные передаются в этом формате. Измените этот параметр, если вы хотите преобразовать данные в другой набор символов перед кодированием. Обратите внимание, что в случае текстовых данных схема кодирования не содержит набора символов, поэтому вам может потребоваться указать соответствующий набор в процессе декодирования. Что касается файлов, то по умолчанию используется двоичный вариант, который исключает любое преобразование; эта опция необходима для всего, кроме обычных текстовых документов.
Разделитель новой строки: В системах Unix и Windows используются разные символы разрыва строки, поэтому перед кодированием любой вариант будет заменен в ваших данных выбранным параметром. Для раздела файлов это частично не имеет значения, так как файлы уже содержат соответствующие разделители, но вы можете определить, какой из них использовать для функций «кодировать каждую строку отдельно» и «разбить строки на куски».
Каждую строку следует кодировать отдельно: Даже символы новой строки преобразуются в их процентно-кодированные формы. Используйте эту опцию, если вы хотите закодировать несколько независимых записей данных, разделенных разрывами строк. (*)
Разделить строки на части: Закодированные данные станут непрерывным текстом без пробелов, поэтому отметьте этот параметр, если хотите разбить его на несколько строк. Применяемое ограничение на количество символов определено в спецификации MIME (RFC 2045), в которой указано, что длина закодированных строк не должна превышать 76 символов. (*)
Режим реального времени: Когда вы включаете эту опцию, введенные данные немедленно кодируются встроенными функциями JavaScript вашего браузера, без отправки какой-либо информации на наши серверы. В настоящее время этот режим поддерживает только набор символов UTF-8.

  (*) Эти параметры нельзя включить одновременно, так как результирующий вывод не будет действителен для большинства приложений.   Надежно и надежно 
 Вся связь с нашими серверами осуществляется через безопасные зашифрованные соединения SSL (https). Мы удаляем загруженные файлы с наших серверов сразу после обработки, а полученный загружаемый файл удаляется сразу после первой попытки загрузки или 15 минут бездействия (в зависимости от того, что короче). Мы никоим образом не храним и не проверяем содержимое отправленных данных или загруженных файлов. Ознакомьтесь с нашей политикой конфиденциальности ниже для получения более подробной информации.
  Совершенно бесплатно 
 Наш инструмент можно использовать бесплатно. Отныне вам не нужно скачивать какое-либо программное обеспечение для таких простых задач.
  Подробная информация о кодировке URL 
  Типы символов URI 
 Символы, разрешенные в URI, являются либо зарезервированными, либо незарезервированными (или символ процента как часть процентного кодирования). Зарезервированные символы — это символы, которые иногда имеют особое значение. Например, символы косой черты используются для разделения разных частей URL-адреса (или, в более общем смысле, URI). Незарезервированные символы не имеют такого специального значения. Используя процентное кодирование, зарезервированные символы представляются с помощью специальных последовательностей символов. Наборы зарезервированных и незарезервированных символов, а также обстоятельства, при которых определенные зарезервированные символы имеют специальное значение, немного меняются с каждой новой редакцией спецификаций, регулирующих URI и схемы URI.
 
 
 Другие символы в URI должны быть закодированы в процентах.  Зарезервированные символы с процентным кодированием 
 Когда символ из зарезервированного набора («зарезервированный символ») имеет особое значение («зарезервированное назначение») в определенном контексте, и схема URI говорит, что необходимо использовать этот символ для какой-либо другой цели, то символ должен быть закодирован в процентах. Процентное кодирование зарезервированного символа означает преобразование символа в соответствующее ему байтовое значение в ASCII, а затем представление этого значения в виде пары шестнадцатеричных цифр. Цифры, которым предшествует знак процента («%»), затем используются в URI вместо зарезервированного символа. (Для символа, отличного от ASCII, он обычно преобразуется в последовательность байтов в UTF-8, а затем каждое значение байта представляется, как указано выше.)
 Зарезервированный символ «/», например, если он используется в компоненте «путь» URI, имеет особое значение, поскольку он является разделителем между сегментами пути. Если в соответствии с заданной схемой URI в сегменте пути должен быть символ «/», то в сегменте должны использоваться три символа «%2F» (или «%2f») вместо «/».
 
 Зарезервированные символы, которые не имеют зарезервированного назначения в конкретном контексте, также могут быть закодированы в процентах, но семантически не отличаются от других символов. В компоненте «запрос» URI (часть после символа «?»), например, «/» по-прежнему считается зарезервированным символом, но обычно не имеет зарезервированного назначения (если не указано иное в конкретной схеме URI). Символ не нужно кодировать в процентах, если он не имеет зарезервированного назначения.
 URI, отличающиеся только тем, является ли зарезервированный символ процентным кодированием или нет, обычно считаются неэквивалентными (обозначающими один и тот же ресурс), за исключением случаев, когда рассматриваемые зарезервированные символы не имеют зарезервированного назначения. Это определение зависит от правил, установленных для зарезервированных символов отдельными схемами URI.
  Незарезервированные символы с процентным кодированием 
 Символы из незарезервированного набора никогда не нуждаются в процентном кодировании.
 URI, отличающиеся только тем, является ли незарезервированный символ процентным кодированием или нет, эквивалентны по определению, но на практике процессоры URI не всегда могут обрабатывать их одинаково. Например, потребители URI не должны рассматривать «%41» иначе, чем «A» («%41» — это процентное кодирование «A») или «%7E» иначе, чем «~», но некоторые это делают. Поэтому для обеспечения максимальной совместимости производителям URI не рекомендуется использовать процентное кодирование незарезервированных символов.
  Процентное кодирование символа процента 
 Поскольку символ процента («%») служит индикатором октетов с процентным кодированием, он должен быть закодирован как «%25», чтобы этот октет можно было использовать в качестве данных в URI.
  Процентное кодирование произвольных данных 
 Большинство схем URI включают представление произвольных данных, таких как IP-адрес или путь к файловой системе, в виде компонентов URI. Спецификации схемы URI должны, но часто не обеспечивают явное сопоставление между символами URI и всеми возможными значениями данных, представленными этими символами.
  Двоичные данные 
 После публикации RFC 1738 в 1994 г. было указано, что схемы, обеспечивающие представление двоичных данных в URI, должны делить данные на 8-битные байты и кодировать каждый байт в процентах в так же, как указано выше. Значение байта 0F (шестнадцатеричное), например, должно быть представлено как «%0F», но значение байта 41 (шестнадцатеричное) может быть представлено как «A» или «%41». Использование незакодированных символов для буквенно-цифровых и других незарезервированных символов обычно предпочтительнее, поскольку это приводит к более коротким URL-адресам.
  Символьные данные 
 Процедура процентного кодирования двоичных данных часто экстраполируется, иногда неуместно или без полного уточнения, для применения к символьным данным. В годы становления World Wide Web при работе с символами данных в репертуаре ASCII и использовании соответствующих им байтов в ASCII в качестве основы для определения последовательностей с процентным кодированием эта практика была относительно безвредной; многие люди предполагали, что символы и байты сопоставляются один к одному и взаимозаменяемы. Однако потребность в представлении символов за пределами диапазона ASCII быстро росла, и схемы и протоколы URI часто не могли обеспечить стандартные правила подготовки символьных данных для включения в URI. Следовательно, веб-приложения начали использовать различные многобайтовые кодировки, кодировки с отслеживанием состояния и другие кодировки, несовместимые с ASCII, в качестве основы для процентного кодирования, что привело к неоднозначности, а также к трудностям с надежной интерпретацией URI.
 Например, многие схемы и протоколы URI, основанные на RFC 1738 и 2396, предполагают, что символы данных будут преобразованы в байты в соответствии с некоторой неуказанной кодировкой символов, прежде чем они будут представлены в URI незарезервированными символами или байтами с процентным кодированием. Если схема не позволяет URI предоставить подсказку о том, какая кодировка использовалась, или если кодировка конфликтует с использованием ASCII для процентного кодирования зарезервированных и незарезервированных символов, то URI нельзя надежно интерпретировать.