• Сделать удобную функцию конверсии из любой code page в любую на plain C — это пиздец задачка.
    И, нет, простой вызов iconv() — это не оно, увы. Интерфейс iconv()'а вообще пидоры придумали.
    Может плюнуть и вставить зависимость от icu? Но он такой большой!
    ♡ recommended by @O01eg

Replies (30)

  • @blacklion, а разве эта задача вообще решаемая на данный момент?
    мне казалось что даже конвертация из koi8 (или кирилической ut8? не помню уже точно) в транслит не работает ни там ни там.
  • @solhov, Хуй с ним с транслитом. Завершающий нолик добавить — и то поприседать надо. Потому что хуй знает сколько реально ноликов добавлять надо.
  • @solhov, Т.е. задачи «поддержзивать больше пар, чем iconv» даже не стоит. Стоит задача «реализовать поверх Win32API или iconv удобный API»
  • @blacklion, так формально эта пара есть, но не работает
  • @solhov, Ну вот это для меня не задача. Мне вообще только из/в utf-8 надо. Но удобно. Что бы размер заранее посчитать, что бы ноликом всегда завершить (сколькью ноликами?) что бы за входной буфер не вылезхти (т.е. не дальше нолика конвертировать, точнее — СКОЛИКИ ноликов?)
  • @blacklion, Проблемы линукса 2017
  • @lovesan, Проблемы Plain C-програмимрования <любой год>. Linux тут не причём, на Windows с его WideCharToMultibyte и MultbyteToWideChar та же фигня в точности
  • @blacklion, Я знаю две кодировки на 2017й год, для винды: UTF-8(передача строк туда-сюда), UTF-16(внутренняя). Остальные не используются. ANSI-кодировки не используются сто лет нормальными людьми. В C/C++ обычно ты получаешь откуда-то UTF-8 и дальше везде UTF-16, если надо куда-то в файл писать — ну кодируешь назад. В .Net вообще во всяких там asp.net итд все перекодирования за тебя делает фреймворк.
  • @lovesan, Увы, всё не так просто в жизни. Т.е. это покрывает 95% случаев, но не 100%. UTF-8 точно так же покрывает 95% жизни в Linux. Но опять же не 100%. А UTF-16 — это вообще пиздос. Ладно бы UCS-4. но UTF-16 сочетает в себе всё неудобство UTF-8 и UCS-4 одновременно.
  • @lovesan, Т.е. люди которые выбрали НЕ БАЙТОВЫЙ но НЕ ФИКСИРОВАННЫЙ формат для строк — они заслуживают отдельной дыбы. Это про UTF-16. И, да, в винде, например, надо в консольной программе печатать всякие сообщения пользователю в консоль. В какой кодировке их надо печатать, а? Подсказать?
  • @blacklion, В UTF-16, конечно. Потому что в Винде, в отличие от всякого древнего говна, есть понятие эмулятора тектового терминала.

    Самой же UTF-16 хватает на 99% случаев, если конечно не с китайцами общаться и не заниматься экзотической типографией, но в таком случае вообще насрать, хоть UTF-8 внутри, потому что токен юникода уже не буква, хоть тебе в UCS-4
  • @lovesan, Как-то когда программа мне пытается печатать в консоль wide char я обычно говно вижу. Даже английский не работает (что не удивительно). Не раз сталкивался.
  • @blacklion, проблемы кривых программ, которые не отличают терминал от stdout
  • @lovesan, А их для не-интерактивных программ и не надо отличать. И это правильно. Особенно если ты пишешь переносимую программу.
  • @blacklion, почему в PowerShell таких проблем нет? Потому что не надо пользоваться кривыми портами всякого говна
  • @lovesan,
    Я знаю две

    Вот ты тупой.
  • @blacklion, В UTF-16, а что?
  • @blacklion, recode_string_to_buffer ?
  • @tzirechnoy, вот ты тупой, не разобрался ни в винде, ни в кодировках, а пиздишь. Или ты контрамот? У тебя поди KOI8-R стоит везде?
  • @lovesan, Ты не переводи. Если ты чего-то не знаешь, и этим гордишься — то ты тупой. Точка.
  • @blacklion, Ну и да, на всякий случай: 99,99% шрифтов не выходят за план UTF-16
  • @tzirechnoy, Ты говноед-прыщеблядок очередной, я блядь вас наблюдаю с середины 2000х с ЛОРа еще, нихуя не умеете, нихуя не знаете, позиция одна — виндагавно, типа как рожи корчить в детстве, вот на том уровне развитие и остановилось.
  • @lovesan, Для справки: UTF-16 содержыт все символы последнего стандарта юникода.
    Включая всякие там private use. Так что за него не выходит значительно большый процэнт шрифтов, чем 99.99%.
  • @lovesan, Понимаещь, либо ты пишешь корректную программу и тогда по substr() условному ты не имеешь права порвать суррогатную пару даже если ты её никогда не видел и с китайцами не общаешься, или ты пишешь некорректную программу потому что «99,99% шрифтов не выходят за план UTF-16» (ты, видимо, хотел скзаать UCS-2, но сказал некорректную фразу, кстати, потому что UTF-16 покрывает весб юникод, до 0x10FFFF). И, да, не забываем модные нынче эмодзи.
  • @lovesan, Огнетушытель припаси, наблюдатель, а то от твоего стула ковёр у тебя займётся.
  • @blacklion,
    substr()
    Садись, два :)
    А вот если бы ты хотя бы icu заюзал, у тебя бы не было таких проблем
  • @blacklion, Постой, так ты что-то ещё разрывать надумал? Тогда хана, никаких recode, или icu (э-э-э. Кстати, не помню, есть ли там), или pango или свой парзер.
    Поскольку у любого символа можэт быть 0, 1, 2, -1, -2 знакоместа и у нас ещё состояние LR-RL как минимум есть.
  • @tzirechnoy, Нет, разрывать вроде в планах пока нет, к счастью. Да, я знаю про эти засады.
    Блин, вот авторы Perl 6, госспади прости, пошли правильным путём с их графемной нормализацией.
  • @tzirechnoy, Есть в icu все, многие высокоуровневые фреймворки/языки именно его используют для своих строк
  • @blacklion, Еще раз, я тебе сказал уже. Твое условное substr в вакууме — говно в вакууме, не нужное. Потому что одно дело если ты пишешь поиск на 99% кейсов, по техническим данным в основном, или вроде того, которые скорее всего в ascii вообще, или ладно там, ну в русском или других распространенных языках, ну там на 6-7 языков мира, у которых все буквы на кодпойнты UCS-2 матчатся. А другое дело что у тебя какой-то сраный CAD для типографов, или как там это называется, или работа с редкими языками(тут про китайский я припиздел выше, извиняюсь, оказывается и они в UCS-2), тогда у тебя кодпойнты юникода ВООБЩЕ не кладутся на символы, и ты не имеешь права даже с UCS-4 делать substr который по кодпойнтам сравнивает, и нужна полноценная нормализация и так далее.