В какой кодировке показывает Chromium 126?
 

файл скрипта содержит русские комменты. Notepad++ показывает UNICODE , т.е. UTF-8
Эта кодировка принята с 1992 года. И должна заменить собой все остальные анахронизмы.
Вот результат отображения этого файла в браузере

const { numValue, unit } = getVolUnit("150px"); // �㘵匾煩棣菩銑觧菩� �箮解�郅郋赲��� �箮參���� 邽 �耨請解���

прошло 32 года, а Chromium чуть отстал.
да, я знаю прогу 2024 выпуска, которая генерит текстовые файлы в ANSI. И еще та прога берет правильный файл в UTF-8, выполняет свою работу, и убивает файл , делая его ANSI.
В принципе, кодировку браузер показывает всем одинаковую, конкретный файл не важен. У нее есть имя ?

Не в DevTools. А по Ctrl+U (посмотреть код страницы). Далее, нажать на внешний sсript.js
Нажмите на свой sсript.js, и расскажите ,что вы видите кв комментах на русском.

Вопрос: 1. Какую из древних кодировок до сих пор использует Chromium 126 ?
Вопрос: 2. Когда это кончится ?

seregadushka, я утверждать не буду, но может дело не в Хромиуме, а в функции getVolUnit?
Или это какая-то неизвестная доселе функция api Chromium?

Юмор оценил, я ж говорю это коммент, там же видно. Там написано "Функция отделения значения от единиц" . Не может быть , чтобы Хромиум не слышал про UTF-8, -16, -32. Я загуглил все, теперь я спец по всем кодировкам . все эти utf
-8. -16. -32. —— это 1 кодировка UNICODE . в старую uтf-8 даже влазит больше всего около 2000000 cимволов, остальные уже хоть разработаны позже, но уже не используется за ненадобностью. Все равно это все вместе 1 кодировка UNICODE. Я даже больше поверю, что не то, что хромиум не слышал UNICODE, а то, что уже изобрели какую-то новую кодировку ???
Но эти иероглифы у меня убивают.

Функцию getVolUnit () собрал cам из 5 строк. Так какие-то регулярные выражения для раздела входа на 2 части. Ничего нового. Я только про комменты. Так показывает браузер текст скрипта на русском. Форум же про скрипты :)
И сам браузер же должен где-то написать имя кодировки . Подбирает он их , выбирает из штук 30 , как 30 лет назад. Или все показывает ч одной кодировке ? Что , по сути, правильно.

UNICODE это не UTF-8, UTF-8 это UTF-8, notepad++ так и напишет.
Кодировок умеющих в юникод множество.

Кодировка должна быть одна на всех. Utf-8 позволяет водить 1900 000 символов, и что опасно ⛔ , уже ЗАНЯТО 15% !
Этот СТОП , подозреваю, это тоже utf-8
Яндексу с его эмодзями уже пора бы подсуетиться, китайцы не спят !

Нет, все перечисленное — это Unicode, у них общее пространство, общие коды. Разница в числе байт кодирования. Там есть различие ч служебных символах (BOM , LE, BE) , но это подробности. Utf-7, возможно , тоже.
Зачем гадать, все есть в Wiki
Notepad++ пишет более подробно, UNICODE — общее название для всех перечисленнвх

seregadushka, чувак, логику формальную подучи, я так и сказал.
utf8 входит в подмножество unicode, но unicode - это не только utf8. Notepad++ тебе должен явно написать, что файл у тебя именно utf8. Если файл в какой-то иной unicode кодировке, так артефакты в браузере вполне понятны.
Также помимо правильной кодировки самого файла ещё и сервер должен ставить правильные заголовки.
Если оба условия соблюдены, а артефакты всё равно есть - ты проверял сам файл? Может он изначально битый такой?
И уже после всего этого можно что-то вякать на хром, баги в котором тоже возможны, но с гораздо меньшей вероятностью, чем кривые руки лично у тебя.

похоже, ты тут и есть главный спамер -- множество, подмножество. Чему ты ты меня учишь , если сам путаешься в простейшем, даже в русском.
Ест правило , работающее всегда и везде " если кто-то тебе гонит на кривые руки, НИКОГДА далее ничего не последует ! " ни одной цифры, ни одной ссылки от тебя не будет.
ты уже показал, что путаешься в школьной программе.
Тогда я тебе покажу какой должен быть ответ на техническом форуме, а не твои жалкие "кривые руки".

Повторяю для тупых: файл создан в NOTEPAD++ v. 8.6.7 от 2024 года, в Windows 11-26100 DEV . Месяц назад вышла.

прежде чем писать сюда, я 10 раз нажал в NOTEPAD++ v. 8.6.7 от 2024 "преобразовать в UTF-8"

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

Отправим тебя на Нобелевку с твоим видео , миллионы подписчиков обеспечено.

Какие артефакты ??? Ты в какой веке живешь до сих пор. Мы не про картинки здесь , проходи мимо.
Это не твои "артефакты" , это называет древний код, за который по твоему высеру ,я должен нести ответственность ???

Тебя спросили название кодировки. Не знаешь где браузер ее пишет , свободен. Нечего тут свою тупость прикрывать чужими "кривыми руками"

Просто посмотреть двоичный (шеснадцетеричный) код файла. Как там записаны кириллические буквы. Записаны ли они в utf-8.

Где показывает? В DevTools?
Браузер просто берет то, что пришло и смотрит на то, какая кодировка задана для страницы. Кодировка может быть задана либо в <meta>, либо в заголовках. Если ничего не задано, то по умолчанию считает, что это utf-8. В этой кодировке и показывает страницу.

коллеги, я четко написал ФАЙЛ. Это не страница. Это ФАЙЛ. с расширением JS !!!
Напомню вам, спецам, как выглядят комменты на HTML-странице
<!-- COMMENTS -->

а в 1 сообщении вот так
// COMMENTS
Эти 2 палки работают ТОЛЬКО в JS . Если вы до сих пор думаете, что // работают и в CSS . НЕТ , только в JS.

Если на подключенный ВНЕШНИЙ JS просто нажать в браузере при просмотре кода страницы, то я получаю именно , что показано в 1 посте.
Я четко все написал в 1 посте, нельзя меня упрекнуть , что я вводу всех в заблуждение.
Простейший вопрос -- в какой кодировке показывает браузер простой ТЕКСТ ?
не ТЕКСТ в HTML , а просто текст.
я не думаю, что здесь надо еще инетересоваться кодровкой сервера. Браузер скачивает файл, готовый.

у мня нет HEX-редактора, но сейчас я вам скажу, что он пишет

wlx_HexViewer_1.1.1.1_Beta.7z -- для Тотала
HEX-Editor для Notepad++
результат одинаковый: оба плагина НЕ показывает ничего, кроме текста самого скрипта. Скрипт начинается с function(), заканчивается ( ; )
Эти символы плагины и показывают/
Что посоветуете , чем смотреть ?

НЕТ . НЕ в DevTools. А по Ctrl+U (посмотреть код страницы)

пропустил видно. Нет, в начале файла НИЧЕГО про его кодировку нет . Файл начинается function()
Вот русские буквы :
да, не иероглифы, не думаю , что это поможет.

не знаю, когда мне дождаться специалиста по кодировкам.
Похоже ,я тут и есть тот самый спец по кодировкам.
В HEX-редакторе каждый символ кодируется ДВУМЯ символами., FF . Это ОДИН байт. макс 256. Именно так и кодировали буквы в 70-х годах.
И современная кодировка UNICODE с максимальными 2^21 символами , включает в себя эти древние ANSI или ASCI, коды первых 256 буков совпадают.
Поэтому спрашивать "какие коды у русских букв" бессмысленно -- они одинаковые в любой кодировке.

А в UNICODE 0 кодируется примерно "00000000 00000000 00000000 00000000"
В начале файла ничего про кодировки нет. И вопрос про браузер.
И как видно , у них разные кодировки, у HEX-редактора и браузера на Chromium 126
Уже есть результат исследования: У браузера точно не ANSI , и не UTF-8:) .

EDGE обновился до Chromium 127. Разумеется, ничего не изменилось. русский не видит. Это не UTF-8

Настолько все тупо и криворуко в этом 2024 году, через сто лет после выхода webkit- : в DevTools русский виден, возможно это и есть UTF-8 , но то т же браузер в "Просмотр кода страницы " уже не видит русский , это не UTF-8 .

seregadushka, возможно Вам бы помогли разобраться быстрее (предположим, что таковые ещё остались), если бы Вы приложили к сообщению сам файл, до и после манипуляций с кодировками в Notepad++, оставив в нём только одну строку, которая приведена в качестве примера в первом сообщении.

Предварительно:

Важно понимать, как Вы "открываете" файл в браузере. И не важно, через просмотр кода страницы это делается или по прямой ссылке на JS-файл. Что именно отдаёт Вам этот файл: HTTP-сервер или локальная ОС?

Если JS-файл отдаётся HTTP-сервером (локальным или нет), тогда нужно смотреть HTTP-заголовок ответа "Content-Type". Если кодировка не указана, Chrome по умолчанию будет использовать UTF-8.

Если вместо кириллицы Вы видите нечитаемый набор символов, значит кодировка файла не совпадает с кодировкой, в которой отдаёт файл HTTP-сервер (если не указана, значит с UTF-8 по умолчанию).

Если же Вы откроете JS-файл в браузере (локально, перенеся файл в окно браузера, чтобы адрес начинался с "file://"), тогда браузер попытается перед показом определить кодировку файла автоматически.

Если в этом случае кириллица отображается корректно, посмотреть кодировку, в которой Chrome читает файл, можно через консоль DevTools с помощью команды "document.characterSet".

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

Хорошо, я как автор темы должен предоставить все исходники. Хотя они ничем не отличаются от ваших.

Исходный файл. Возможно, я его скачал с чужого сайта , в комплекте со со всем остальным. Но комменты мои , в простом Notepad++, который его пересохраняет в UTF-8.
https://seregasmyfavoritesites.on.dr...um/UTF/show.js

Чистый файл после сложнейшей операции в Notepad++ : "File- New ... .TXT"
https://seregasmyfavoritesites.on.dr...m/UTF/TEST.txt

Он же после замены расширения на .JS
https://seregasmyfavoritesites.on.dr...um/UTF/TEST.js

Он же после замены расширения на .JS и перекодировать в Notepad в "UTF-8 с BOM"
https://seregasmyfavoritesites.on.dr...TF/TEST-BOM.js

вывод: для 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

seregadushka,
Не существует никакой единственной кодировки на все случаи жизни, у всех есть какие-то недостатки. В случае UTF-8 - это переменная длина символов, что сильно осложняет работу: чтоб скопировать 1000 символов, нельзя просто взять 1000*X байт, нужно прямо посимвольно читать весь текст. И то же самое для простого перехода к 100500-му символу.

От того, что UTF-8 стала стандартом, остальные кодировки не перестали быть такими же стандартами:

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

Белый шум, не ожидал такую древность сейчас услышать.

коллеги, я слышал про эти разговоры , про переменную длину символов , еще когда интернет был по телефону ! Это тогда кодировали по 1 байту ради экономии на дискетах.
Я даю тебе гарантию . что сейчас нет никакой последовательного чтения.
UTF-8, -16, -32 имеет 4 байта на каждый символ. У всех троих одинаково. Это мы имеем 2^32 буков максимально, в теории это 4,3 млрд штук.

В UTF-32 просто нет служебных отдельных символов и места под них. Все загнано в коды самих символов, по 4 байта на каждый, а внутри уже там как-то распределяетя. Место на все хватает, с запасом.
все кратко в Wики есть. может, я неправильно понимаю, У UTF-8 вроде как ограничение на 2^21 буков. Но и так понятно, что как ни ограничивай на все языки места хватит.
Разница в в количестве служебных символов. Условно UTF-8 из этого 2^32 половина приходится на служебные биты.
как они их там используют - это уже их дело. Понятно, что оставшихся 2^16 битов нам на буквы за глаза хватит.

Я про то, что даже тогда , в 1991 году уже понимали, что экономия на спичках, на переменной длине символов -- это тупик и глупость. А сейчас тем более, никто эту переменную длину не поддерживает.

Если в Wiki на странице UTF-8 нет такой последовательности букв "последовательное чтение" -- значит, нет.
И не надо тянуть эти старые вредные теории и заблуждения через поколения дальше.
А то распугаете молодежь с форума.

Все . коллеги. Я ПЕРВЫЙ ! победил эту тему.
Я вас 3 раза отправлял в Wiki. Вы сопротивлялись . Я сам туда сходил сейчас и прочитал уже получше, чем только заголовки.

Смотрим раздел:

Единственный, кто в этой теме был максимально близок к решению -- это voraa !
Его цитата : Я опять искал в Тотале просмотрщик HEX -- нет его там. Плагины показывают правильно -- что нет служебных символов.
Что в Wiki написано ? ТРИ БАЙТА. Я делаю "Кодировать в UTF-8 с BOM" и файл увеличивается на ТРИ БАЙТА. Это победа !
Я уже все понял . Сразу его на хостинг . Смотрим новую редакцию

Все прекрасно ! Сервер видит BOM и ставит правильную кодировку.

Свои способности по вычислению всех кодировок мира -- оцените сами :) . Эта тема разрослась на 4 страницы -- это ваша вина :)
Аплодисменты voraa и мне немного :)

:facepalm:
Почитай ещё википедию дальше заголовков, знаток кодировок )))

Это просто шедевр :lol:

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

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

А хамство вообще отбивает всякое желание общаться, не то что помогать.

У меня есть. Открываем просмотрщик файла по F3. Далее меню -> вид -> шеснадцатеричный

Весь вопрос в том, будет ли файл js не только показываться, но и работать с этим маркером?utf-8 переменное число байт на символ. От 1 до 4.
Так же и Big-5. 1 или 2 байта на символ.