Marcin Hagmajer развивает библиотеку для работы с однобайтными кодировками на JS

Implementation has no dependencies

Вот это он молодец.

А работать с однобайтом, когда вокруг мультибайт и сам язык этому способствует, как-то... а зачем?

Во-первых, не всем нужен юникод. Во-вторых, а как парсить, например, те же *.txt файлы, которые виндузятники сохраняют из блокнота (а при той же русскоязычной локали они, говорят, продолжают сохраняться в cp1251), а потом куда-то заливают?

Мало того, что с однобайтными кодировками, так еще и на йотэс.

Херню тебе говорят. В юникоде блокнот сохраняет.

Был уже один Марвин Химайер, которому тоже не нравились сложившиеся индустриальные порядки.

Ты пропагандируешь разведение помойки. Уймись, пока младшее поколение этого не начиталось.

Для особо упоротых случаев есть iconv.

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

Во-вторых, а как парсить, например, те же *.txt файлы, которые виндузятники сохраняют из блокнотаВо-вторых, а как парсить, например, те же *.txt файлы, которые виндузятники сохраняют из блокнота

Это проблема виндузятников

Marcin Hagmajer (предположительно Software Engineer из Польши) развивает библиотеку для работы с однобайтными кодировками на JS.

Тебе в желтую прессу надо идти. Тред должен был звучать так:

Никому неизвестный JS-джуниор разрабатывает что-то никому ненужное.

а при той же русскоязычной локали они, говорят, продолжают сохраняться в cp1251

говорят

Блажен, кто верует. Как оно там, в 98-м? OS/2 всё ещё полноценная альтернатива винде? Прыщавые дети как веруны, билли сакс винда мастдай!

Хорошо, допустим, что теперь в новых версиях винды блокнот сохраняет в UTF-16 или другой юникодной кодировке. Тогда получается, что новые текстовые файлы в cp1251 генерируют юзеры прежних версий винды, которые, получается, продолжают юзаться.

iconv, как выше было сказано, плюс ногой с разворота тому юзеру, который тебе это подсунул.

Вот нам только этого не хватает, вот этих вот однобайтных кодировок. Забыли уже про компоненты Дельфи, про геморрой с локализацией?

про геморрой с локализацией

Зачем локализация? Английского и ASCII хватит всем.

Во-вторых, а как парсить, например, те же *.txt файлы, которые виндузятники сохраняют из блокнота (а при той же русскоязычной локали они, говорят, продолжают сохраняться в cp1251), а потом куда-то заливают?

Встречный вопрос, а как вы локаль определите этого *.txt ? Если заведомо известно что это 1251 то как уже писали iconv в помощь. Если не известно, то вообще зачем оно?

а как вы локаль определите этого *.txt ?

Есть, например, enca.

зачем оно?

Чтобы работать с однобайтными текстами. Пример автора:

const fs = require('fs');
const { Encoder } = require('single-byte/stream');

fs.createReadStream('file-utf8.txt')
  .pipe(new Encoder('iso-8859-2'))
  .pipe(fs.createWriteStream('file-iso-8859-2.txt'));

Очень нужно.

Он может сохранять в юникоде, но новый текст сохранит в 1251. Пустой текстовый документ (ПКМ -> Создать -> Текстовый документ) тоже откроет по умолчанию в ANSI. Если новый документ пересохранить в юникоде, состояние дропдауна с кодировкой на новых файлах все-равно «ANSI».

Если из Блокнота сохранить в файл в юникоде, в начало будет записан BOM. Если такой файл попытаться открыть в Блокноте, он по умолчанию сообразит, что в файле юникодный текст.

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

Так что, говорят правильно, а ваша, lenin386, env, информация неточна.

Забавно читать бугурт фанатиков, которые за свободное ПО, но при этом яростно против «неправославных» кодировок.

Я сам использую UTF-8 (ибо деваться некуда), но понимаю, что она, мягко говоря, далека от совершенства из-за дискриминации языков с нелатинскими алфавитами.

new TextEncoder(«koi8»);
new TextDecoder(«koi8»);

Ты тупой лжец. Факт в том, что notepad.exe даже в самой последней венде в CP1251 сохраняет текст до сих пор.

Marcin Hagmajer развивает библиотеку для работы с однобайтными кодировками на JS
однобайтными
JS

Что я курил? Или автор что-то курил?

Обоснуй.

Зато ыксель экспортирует CSV в однобайтных кодировках. Не далее как в июне сего года делал прослойку для переноса и автозаполнения данных между программами, пришлось с таковыми работать. Ввиду черезжопности найденных библиотек для фронта не нашёл ничего лучше, чем перегонять однобайтный текст в base64, слать так на сервер, а конвертировать уже там.

Marcin Hagmajer развивает библиотеку для работы с однобайтными кодировками на JS

угадал автора по названию темы =)

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

А FreeDOS на этом форуме оффтопег? Там вообще CP866.

Английского и ASCII хватит всем.

а тебе мама в детстве не говорила чтоб ты не говорил за всех?

UTF-8
дискриминации языков с нелатинскими алфавитами.

щито?

Разным code point'ам разное кол-во байт - неравенство и дискриминация. Вот в UTF-32 дискриминации нет. Как и в однобайтных кодировках.

Что обосновывать? Сколько лет все мучались с помойкой из национальных кодировов, и наконец оно сдохло иет больше бНОПНЕЙ в моих интернетах. Но нет, находятся любители вытащить на свет б-жий раздутый и сгнивший труп.

Какой, 2003й?

Работать пробовал вместо того что бы байты в строках вручную считать?

Сколько лет все мучались

Экие неженки. А вот ТС с кодом должен мучаться, если перейдёт на этот ваш хрюникод. Видал, сколько libicu весит? Это явный оверкилл, чтобы просто работать с русскоязычным текстом.

иет больше бНОПНЕЙ в моих интернетах

Есть, плохо ищешь.

раздутый и сгнивший труп

Всё с вашими фетишами ясно.

Хз, какой там на десятке стоит, 2015-й вроде.

Не нужно ему мучаться (количество символов в строке считается функцией в 2 строчки) — ему нужно эпатировать публику.

количество символов в строке

Это лишь одна из многих задач работы с текстом. И ту ты предложил делать за O(n) вместо O(1) — на хрена?

На самом деле нет. Перебирать code point'ы по одному можно (при этом в функции будет больше строчек), НО среди них будут модификаторы. Чтобы корректно обрабатывать юникод с модификаторами нужно либо таскать таблицы модификаторов (а завтра в новом стандарте юникода могут добавить новые модификаторы), либо задействовать такие библиотеки как icu.

В С любая работа со строками O(n) из за отсутствия понятия массива в языке.

Это лишь одна из многих задач работы с текстом.

Да не смог он предложиь настоящей задачи. Даже выведение сплошной строки столбцами потребовало спецподготовки строки — т.е. её посимвольного разбора. Ага, табы выкидываем, длинные слова выкидываем и пр. Обычная склейка сртрок разбора не требует. А там где поиск — один хрен надо по символам ходить.

Не «массива», а «строки». Строки реализуются через массивы. При этом для юникодного code point'а есть тип wchar_t, который в линуксах 4 байта (что годно и для UTF-32). Однако, модификаторы никто не отменял. И если массив юникодных code point'ов, например, 27, то это совсем не значит, что там 27 символов. Там могут быть хоть 4 модификатора, хоть 26 модификаторов.

С однобайтными кодировками таких неопределённостей нет.

Строки реализуются через массивы

За тем исключением, что в C _нет_ встроенных в язык массивов.

Напиши мне поиск в строке, или хотя бы количество знакомест за O(1). Жду.

Есть.

To declare an array in C, a programmer specifies the type of the elements and the number of elements required by an array as follows −

type arrayName [ arraySize ];

Он не в куче.

А это уже другой вопрос. Для больших/динамических массивов есть malloc(). При этом для языка всё равно как был инициализирован массив.

При этом для языка всё равно как был инициализирован массив.

Нет. Это указатель на кусок памяти неизвестного размера.

До инициализации. А после инициализации уже нет. Даже в случаях произвольных массивов узнать их размер можно так:

n = sizeof(a)/sizeof(a[0]);

Только на стеке.

Действительно. В этом случае надо юзать malloc_usable_size().