28.07.2024, 07:02
|
|
Аспирант
|
|
Регистрация: 10.07.2024
Сообщений: 47
|
|
вывод: для JS браузер меняет кодировку, с правильной UTF-8 , в которой есть места на все символы и смайлы мира (и еще 6 раз по столько же). но Хромиуму это мало, 1900000 недостаточно, надо изменить кодировку.
roland ,
"document.characterSet".
-- для HTML это UTF-8 , без сомнения.
т.е. выяснили: браузер знает про UTF-8 , но для JS он ее меняет.
Прошло 32 года, но это БАГ настоящий баг Хромиума , начиная с 1 его версии.
Сейчас занято 145000 символов, я думаю, там есть место для наших 33 буков.
Даже интересно , на какую кодировку он меняет, и почему там китайские иероглифы. Их много ,
Яндекс: "от 40 до 50 тыс" . Значит , эта кодировка, содержит 50 000 иероглифов, но места для русского там не нашлось.
Я думал , в браузере есть поле, где написана кодировка. Я не знаю где, думал , вы знаете.
|
|
28.07.2024, 08:22
|
Аспирант
|
|
Регистрация: 02.11.2023
Сообщений: 30
|
|
Вам будет проще помочь, если Вы прикрепите все 3 файла к сообщению в виде вложений. Форум позволяет это сделать.
|
|
28.07.2024, 10:59
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,750
|
|
Сообщение от seregadushka
|
wlx_HexViewer_1.1.1.1_Beta.7z -- для Тотала
|
У тотала есть средства просмотра в 16 виде. Не редактор, а просто просмотр.
В файле https://seregasmyfavoritesites.on.dr...test24/show.js нормальная utf-8 кодировка.
Сообщение от seregadushka
|
Вот русские буквы :
|
Нужен 16 вид.
Сообщение от seregadushka
|
коды первых 256 буков совпадают.
|
Коды первых 128 букв совпадают.
Сообщение от seregadushka
|
но то т же браузер в "Просмотр кода страницы " уже не видит русский , это не UTF-8 .
|
Ну да. В этом режиме он почему то не берет utf-8 по умолчанию.
У Хрома нет средств менять кодировку страницы непосредственно в браузере. Они предлагают устанавливать плагины.
|
|
29.07.2024, 12:18
|
Аспирант
|
|
Регистрация: 02.11.2023
Сообщений: 30
|
|
Сообщение от seregadushka
|
Прошло 32 года, но это БАГ настоящий баг Хромиума , начиная с 1 его версии.
|
Вы хотите сказать, что, к примеру, в Firefox у Вас результаты другие? У меня на последней стабильной версии Firefox аналогичные с Chrome: на вашем хостинге JS - отображаются с неправильной кодировкой (Big5), а TXT - с правильной (UTF-8).
Из личного интереса было сделано то, что Вы и советовали:
Все 3 предоставленные файла были залиты на личный хостинг. И все 3 файла отображаются с правильной кодировкой (UTF-8).
Теперь к сути проблемы:
Ваш HTTP-сервер (или настройки Amazon CloudFront - Вам виднее) отдаёт JS-файлы с заголовком "content-type" без директивы "charset", а для TXT-файла - с директивой "charset" со значением "UTF-8".
Это единственная причина, почему TXT-файл на Вашем хостинге отображается в браузере в кодировке UTF-8.
Если директива "charset" для заголовка ответа "content-type" не определена, браузер будет использовать автоопределение кодировки (а не UTF-8 по умолчанию, в чём было моё ошибочное предположение). В данном случае, и Chrome, и Firefox ошибочно определили кодировку как Big5 (можете проверить значение document.characterSet). Возможно они даже используют одну и ту же библиотеку для этого.
Причина, по которой у меня на хостинге все три файла отображаются в браузере в UTF-8:
Мой HTTP-сервер всегда по умолчанию подставляет директиву "charset" со значением "UTF-8" для заголовка ответа "content-type".
Вы можете проверить сами, открыв ваши JS-файлы по прямой ссылке и переписать значение заголовка ответа "content-type", добавив директиву "charset" со значением "UTF-8" (Chrome это позволяет):
application/javascript; charset=UTF-8
Вывод: Если не хотите, чтобы браузеры угадывали кодировки Ваших текстовых файлов, настраивайте HTTP-сервер с подстановкой директивы "charset" с нужной кодировкой по умолчанию. Браузеры здесь ни при чём.
|
|
29.07.2024, 14:22
|
|
Аспирант
|
|
Регистрация: 10.07.2024
Сообщений: 47
|
|
ну вот понятно ,спасибо.
Я всегда ставил (просто копировал)
<meta http-equiv="Content-Type" content="text/html; />
а эта вещь стоит отдельно
<meta charset="utf-8">
и никогда не думал зачем это, если оно везде у всех одинаково.
но ведь это относится в HTML странице, а не моим файлам из Notepad++
Поэтому, я не понимал претензий ко мне, как я могу в .TXT или .JS вводить куски HTML.
Я занимаюсь только своими страницами, и не в курсе даже как посмотреть , что там отдает сервер, в каких протоколах.
Big5 -- она чисто для китайцев, кодирует максимум FFFF , т.е. 65536 буков китайского типа.
Я понял, что это вина сервера, которому какой-то узкоглазый записал эту кодировку. Чем его UTF-8 с 1900000 символами не устроила, не понятно.
Эта кодировка тоже не вчера придумана: в 1997 , потом была модернизация в 2003. Потом еще раз.
И за все эти разы в узкоглазой башке не появилась мысль -- удалить ее с сервера. Чтобы у того не было даже вариантов такой подставы вредительской.
Неeжели им проще разработать cвою кодировку, организовать ее принудительное внедрение на всех серверах страны и мира, чем отправить e-mail с кучкой своих иероглифов в контору UNICODE ?
Я раз за вас, что вы можете менять свои сервера. У меня хостинг -- это просто доcтуп по webdav. Протоколы менять там негде.
Конечно, никто ответы сервера менять не будет. Это же только комменты для JS -- не видно для конечного юзера.
Но исследование такой мелочи проведено глобальное
Последний раз редактировалось seregadushka, 29.07.2024 в 15:00.
|
|
29.07.2024, 18:40
|
|
Профессор
|
|
Регистрация: 03.02.2020
Сообщений: 2,750
|
|
Сообщение от seregadushka
|
Я понял, что это вина сервера, которому какой-то узкоглазый записал эту кодировку.
|
Это скорее вина не сервера, а браузера. Когда кодировка не указана в заголовке, браузер сам как то пытается ее определить, использую эвристические алгоритмы. Ну и не может. В принципе одна и та же последовательность байт может встречаться как в big-5 так и d utf-8. Браузер отдает предпочтение big-5
|
|
30.07.2024, 11:40
|
|
Аспирант
|
|
Регистрация: 10.07.2024
Сообщений: 47
|
|
В принципе, тема уже освещена полностью. Мелкие уточнения:
1. Utf-8 самая первая и самая емкая — в нее влазит около 1900000 символов, но она ограничена до 1200000 для совместимости со своими более молодыми версиями utf-16, utf-32. По-моему рекомендовано их не использовать. В utf -8 половина содержания - это служебные биты. Может, авторам они нужнее.
2. Я правильно понимаю, что в самом TXT JS нет указания на их кодировку ? Мои плагины HEX показывают что ни в начала , ни в конце в них нет ⛔ служебных байтов.
Все ваши советы по установке charset относятсятся к странице, а не текстовым файлам.
Откуда сервер знает 129 символ — это иероглиф или русская Ы ?
Расскажите уже на пальцах
|
|
30.07.2024, 15:08
|
Аспирант
|
|
Регистрация: 02.11.2023
Сообщений: 30
|
|
Сообщение от seregadushka
|
Я правильно понимаю, что в самом TXT JS нет указания на их кодировку ?
|
Именно так.
Сообщение от seregadushka
|
Все ваши советы по установке charset относятсятся к странице, а не текстовым файлам.
|
Это относится ко всем HTTP-запросам данных, которые Вы хотите просматривать в браузере. Нужно понимать, что браузер - в первую очередь программа для просмотра HTML-файлов, а не "голых" текстовых данных с неизвестными кодировками.
Если Вы хотите использовать браузер для просмотра текстовых файлов, ему необходимо помочь с определением кодировки.
В первую очередь браузер ищет кодировку в значении директивы "charset" HTTP-заголовка ответа "content-type".
Если браузер директивы "charset" не находит, он пытается угадать кодировку.
В случае HTML-файлов, если директивы "charset" нет, браузер ищет кодировку в атрибуте "charset" элемента "meta". Обратите внимание, что у директивы "charset" HTTP-заголовка ответа "content-type" приоритет выше.
По этой причине, если хостинг чужой, директивы "charset" в заголовке ответа "content-type" для HTML-файлов быть не должно, чтобы у пользователя была возможность использовать HTML-файлы с любой желаемой кодировкой, которую он укажет в атрибуте "charset" элемента "meta".
Сообщение от seregadushka
|
Откуда сервер знает 129 символ — это иероглиф или русская Ы ?
|
HTTP-сервер не знает. У HTTP-сервера задача простая - отдавать биты данных и некоторую дополнительную информацию с помощью HTTP-заголовков. Определение кодировки - задача браузера, а помочь ему в этом - задача распространителя данных (директива "charset" для всех файлов или атрибут "charset" для HTML-файлов).
Я не знаю, зачем Вам понадобилось просматривать JS-файлы в "голом" текстовой виде в браузере вне DevTools, но в Вашем случае может помочь одно из расширений, которое позволяет указывать кодировку для отдельных доменов, чтобы все файлы отображались в желаемой (UTF-8) кодировке. Попробуйте поискать расширения по запросу "Character Encoding" или "Charset".
|
|
30.07.2024, 15:43
|
|
Профессор
|
|
Регистрация: 07.03.2011
Сообщений: 1,138
|
|
Что мешает прочитать документацию utf-8? https://datatracker.ietf.org/doc/html/rfc3629
Всего пару страниц текста и ненужно никаких фантазий с "освещена полностью" ...
|
|
30.07.2024, 21:17
|
|
Аспирант
|
|
Регистрация: 10.07.2024
Сообщений: 47
|
|
MallSerg,
после 3 страниц этой тем давать ссылку на название стандарта utf-8? Даже в Wiki больше написано. Здесь нет разработчиков utf-9, подробности utf-8 не нужны, которых там и нет.
С utf-8 все понятно -- она уже ДАВНО стандарт.
Сам вопрос в том, почему в 2024 году всплывают еще другие колировки ? И всплывают неправильно. И своим застрявшим в прошлом существованием не дают жить единственной , имеющей право на жизнь , utf-8
|
|
|
|