вывод: для JS браузер меняет кодировку, с правильной UTF-8 , в которой есть места на все символы и смайлы мира (и еще 6 раз по столько же). но Хромиуму это мало, 1900000 недостаточно, надо изменить кодировку.


roland ,

"document.characterSet".

-- для HTML это UTF-8 , без сомнения.

т.е. выяснили: браузер знает про UTF-8 , но для JS он ее меняет.
Прошло 32 года, но это БАГ настоящий баг Хромиума , начиная с 1 его версии.
Сейчас занято 145000 символов, я думаю, там есть место для наших 33 буков.
Даже интересно , на какую кодировку он меняет, и почему там китайские иероглифы. Их много ,
Яндекс: "от 40 до 50 тыс" . Значит , эта кодировка, содержит 50 000 иероглифов, но места для русского там не нашлось.

Я думал , в браузере есть поле, где написана кодировка. Я не знаю где, думал , вы знаете.

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

У тотала есть средства просмотра в 16 виде. Не редактор, а просто просмотр.
В файле https://seregasmyfavoritesites.on.dr...test24/show.js нормальная utf-8 кодировка.
Нужен 16 вид.
Коды первых 128 букв совпадают.
Ну да. В этом режиме он почему то не берет utf-8 по умолчанию.

У Хрома нет средств менять кодировку страницы непосредственно в браузере. Они предлагают устанавливать плагины.

Вы хотите сказать, что, к примеру, в 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" с нужной кодировкой по умолчанию. Браузеры здесь ни при чём.

ну вот понятно ,спасибо.
Я всегда ставил (просто копировал)

<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 -- не видно для конечного юзера.
Но исследование такой мелочи проведено глобальное :)

Это скорее вина не сервера, а браузера. Когда кодировка не указана в заголовке, браузер сам как то пытается ее определить, использую эвристические алгоритмы. Ну и не может. В принципе одна и та же последовательность байт может встречаться как в big-5 так и d utf-8. Браузер отдает предпочтение big-5

В принципе, тема уже освещена полностью. Мелкие уточнения:
1. Utf-8 самая первая и самая емкая — в нее влазит около 1900000 символов, но она ограничена до 1200000 для совместимости со своими более молодыми версиями utf-16, utf-32. По-моему рекомендовано их не использовать. В utf -8 половина содержания - это служебные биты. Может, авторам они нужнее.

2. Я правильно понимаю, что в самом TXT JS нет указания на их кодировку ? Мои плагины HEX показывают что ни в начала , ни в конце в них нет ⛔ служебных байтов.

Все ваши советы по установке charset относятсятся к странице, а не текстовым файлам.
Откуда сервер знает 129 символ — это иероглиф или русская Ы ?
Расскажите уже на пальцах

Именно так.

Это относится ко всем HTTP-запросам данных, которые Вы хотите просматривать в браузере. Нужно понимать, что браузер - в первую очередь программа для просмотра HTML-файлов, а не "голых" текстовых данных с неизвестными кодировками.

Если Вы хотите использовать браузер для просмотра текстовых файлов, ему необходимо помочь с определением кодировки.
В первую очередь браузер ищет кодировку в значении директивы "charset" HTTP-заголовка ответа "content-type".
Если браузер директивы "charset" не находит, он пытается угадать кодировку.

В случае HTML-файлов, если директивы "charset" нет, браузер ищет кодировку в атрибуте "charset" элемента "meta". Обратите внимание, что у директивы "charset" HTTP-заголовка ответа "content-type" приоритет выше.

По этой причине, если хостинг чужой, директивы "charset" в заголовке ответа "content-type" для HTML-файлов быть не должно, чтобы у пользователя была возможность использовать HTML-файлы с любой желаемой кодировкой, которую он укажет в атрибуте "charset" элемента "meta".

HTTP-сервер не знает. У HTTP-сервера задача простая - отдавать биты данных и некоторую дополнительную информацию с помощью HTTP-заголовков. Определение кодировки - задача браузера, а помочь ему в этом - задача распространителя данных (директива "charset" для всех файлов или атрибут "charset" для HTML-файлов).


Я не знаю, зачем Вам понадобилось просматривать JS-файлы в "голом" текстовой виде в браузере вне DevTools, но в Вашем случае может помочь одно из расширений, которое позволяет указывать кодировку для отдельных доменов, чтобы все файлы отображались в желаемой (UTF-8) кодировке. Попробуйте поискать расширения по запросу "Character Encoding" или "Charset".

Что мешает прочитать документацию utf-8? https://datatracker.ietf.org/doc/html/rfc3629
Всего пару страниц текста и ненужно никаких фантазий с "освещена полностью" ...

MallSerg,
после 3 страниц этой тем давать ссылку на название стандарта utf-8? Даже в Wiki больше написано. Здесь нет разработчиков utf-9, подробности utf-8 не нужны, которых там и нет.
С utf-8 все понятно -- она уже ДАВНО стандарт.
Сам вопрос в том, почему в 2024 году всплывают еще другие колировки ? И всплывают неправильно. И своим застрявшим в прошлом существованием не дают жить единственной , имеющей право на жизнь , utf-8