Кодировки и веб-страницы

[@lorc]

Мне кажется что самый правильный способ сократить время отладки и сберечь нервы — хранить всё в utf8, как пытается делать весь современный софт.
Я бы хотел посмотреть, как вы в cp1251 запишите имя одного известного физика — Erwin Rudolf Josef Alexander Schrödinger, или известнгого теоретика марксизма Máo Zédōng (он же 毛澤東).

[@Evengard]

Тоже удивился. cp1251 в 2015 году отдаёт архаизмом.

[@webkumo]

1. Все исходники перетаскиваем на UTF (имейте же совесть! зачем заниматься чепухой с cp1251 на java? Это вам не php!)
2. Все подключения/сессии db переключаем на utf
3. Настраиваем контейнер приложения, опять же на utf
И получаем редкие проблемы отсутствующих в utf символов, которые не касаются ни символов русского языка, ни символов как минимум большинства европейских языков. При полной нативной поддержке со стороны java.

[@Stalker_RED]

А если был бы php, то есть смысл связываться с cp1251? Не расскажете подробнее, зачем?

[@Borz]

у строковых методов проблемы с многобайтовыми строками — надо использовать mb_* аналоги, что делают не все.

[@sergey-b]

Вот вы смеетесь, а в SQL Server-е до сих пор надо перед каждой строкой ставить буковку N, например: N'Cъешь еще этих мягких булок'. Иначе строка будет храниться в кодировке Cp1251.

[@grossws]

Да, когда данных много (хотя бы единицы терабайт), экономия в 2 раза становится довольно интересно. И тут однобайтные кодировки и BOCU-1 выходят на сцену. В случае явы всё не так радужно, если держать в памяти явовские строки (они в utf16), но это уже обмен mem/cpu. Аналогично можно использовать какой-нибудь snappy/lz4.

[@sergey-b]

Вот это шедевр

String db_string = new String(MyValue.getBytes(«cp1251»),«utf-8»);

Благодаря таким вот «костылям», когда вы наконец обновите настройки своего ПО, и у вас строка MyValue станет содержать нормальный текст, то вся система посыпется.

[@sergey-b]

восстановить ссылки на источники нет возможности

Естественно, потому что так уже давно никто не делает.

[@grossws]

За encoding="cp1251" в xml надо бить линейкой по пальцам.

Насчёт utf8 в базе дело спорное. Иногда лучше однобайтную (если данные позволяют) или BOCU-1 (в среднем близко к 1 байту на то, что можно представить в однобайтной кодировке), но с её поддержкой есть некоторая проблема, имя которой — IBM.

[@webkumo]

Хм… так utf8 тоже однобайтовая (правда расширяемая до 4х байтов в зависимости от конкретного символа), при этом в однобайтовом представлении включает весь нижний ряд ASCII-таблицы (первые 128 символов), если я правильно помню… Какие проблемы-то? а вот cp1251 на немецком сломается.

[@grossws]

В той части, где utf-8 кодируется в один байт (0x00-0x7f, но это не делает её однобайтной), она неотличима от cp1251, latin-1 и т. п.

Когда я говорю «данные позволяют», я и имею ввиду, что данные в рамках одной группы (например, чисто европейские языки в latin-1, тогда можно и французкий, и английский, и немецкий кодировать в 1 байт).

Если у вас данные исключительно на русском, то в utf-8 каждый символ будет занимать 2 байта, и вы от этого оверхеда нукуда не уйдёте. Пока данных мало — всё хорошо, а когда разговор о том, чтобы влезть в 256 GiB RAM против, грубо, 512 GiB или на один 800 GB SSD против двух, то этот вопрос встаёт в полный рост.

BOCU-1 же позволяет использовать всю мощь юникода, при этом давая компактый выхлоп при использовании относительно длинных последовательностей символов одной группы Юникода. Т. е. если у вас 100 символов кириллицы, то вы получите, например, 103 байта, что уже не такой серьёзный оверхед.

[@webkumo]

На всякий случай, обращаю ваше внимание — статья про Java, а она, опять же насколько я помню, в принципе хранит _все_ строки в памяти в своём UTF16. Т.е. выигрыша по памяти так не достичь.
Да и по дисковой подсистеме — не очень убедительный довод. Бинарные данные обычно куда больше место съедают, нежели строковые…

[@grossws]

На всякий случай, обращаю ваше внимание — статья про Java, а она, опять же насколько я помню, в принципе хранит _все_ строки в памяти в своём UTF16.

Я в курсе, см. комментарий выше. Не обязательно держать все данные в виде строк. Ява вполне позволяет держать byte[] и ByteBuffer в памяти. А распаковывать в utf-16 строки только по необходимости. Это и есть memory/cpu trade-off, о котором я говорил выше.

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

Это очень сильно зависит от специфики данных и области деятельности.

[@webkumo]

И заниматься n раз перекодированием байт-буфер<->строка? Поясните свою мысль, пожалуйста, пока она кажется как минимум сомнительной.

[@Devid_Nezdeshniy]

Вопрос не в перегоне именно в cp1251, она как пример взята. Вместо неё можно подставить любую нужную кодировку.