Представьте: вы с другом в детстве живете в разных домах, и окна ваших комнат выходят друг на друга. Вечером, когда вас зовут на ужин по домам, вы больше не можете общаться со своим другом, ведь ввиду возраста у вас еще нет телефонов (вот было время...)Читать полностью »
Началось с простого желания: чтобы Claude мог написать письмо коллеге, не заставляя меня переключаться в браузер. Готовые решения есть — Zapier, всякие облачные коннекторы. Но там моя переписка проходит через чужую инфраструктуру, а мне этого не хотелось. Значит, свой MCP‑сервер: пара сотен строк, Gmail API, за вечер.
Вечер растянулся на несколько дней и 300 тестов не потому что задача сложная, потому что почта оказалась минным полем, где каждая вторая мелочь ломает всё молча и не сразу.
Собрал грабли в кучу. Если будете делать что‑то похожее — сэкономите себе несколько вечеров.
Зачем на число 1 я в типах u8, u16, u32 и так далее переплачиваю 7, 15 и 31 бит? Это же бред.
Однозначность декодирования? Быстрая адресация? Сейчас распишу до чего я допёр.
Если биты лежат в потоке, то не совсем понятно что они значат без предварительной договорённости. Например:
1110101011
Что это? Одно число? Два? Бог его знает. Без какого-то знания начального подойти к данным не выйдет (я работаю над этим :D).
Не прошло и пяти лет, как в Java 18 докатилось небольшое, но очень ожидаемое и обсуждаемое изменение: теперь во всех стандартных API используется UTF-8 кодировка по умолчанию. Это изменение, которое сделает выражение «Write once, run anywhere» действительно правдой, так как теперь поведение приложения будет еще меньше зависеть от системы, где оно запущено.
На конференции Joker я рассказал, как развивались события в работе над JEP-400Читать полностью »
Нет лучшего времени, чтобы купить свой первый пейджер.
Как Unicode уничтожает большинство ваших предположений о том, как на самом деле работают строки
Когда речь идет о написании чего-то простого, мы, программисты, обычно действуем интуитивно. В случае с простыми вещами мы полагаемся на четкий набор предположений вместо конкретных знаний о том, как эти вещи работают. Например, мы предполагаем, что если b = a + 1, то b больше a, или что если мы применим функцию malloc для какого-то буфера, то получим необходимое количество памяти для записи. Мы не заглядываем в документацию всякий раз, когда имеем дело с мелочами.
Мы делаем так, потому что тотальная проверка замедлит работу. Однако если бы мы все-таки провели проверку, мы бы обнаружили, что обычно ошибаемся в своих предположениях. Существует арифметическое переполнение, в результате которого a + 1 может быть значительно меньше, чем a. Иногда malloc дает нам null вместо буфера и мы оказываемся в пролете.
Нам обычно приходится обжечься на таких вещах, чтобы хотя бы немного изменить свои предположения. И даже тогда мы обычно исправляем их весьма условно.
Столкнувшись с досадной ошибкой переполнения, мы можем скорректировать свое предположение о целых числах в виде «a + 1 больше a, если отсутствует вероятность, при которой a представляет собой очень большое число». И мы действуем исходя из этого, вместо того, чтобы обдумать четкие правила, по которым работает переполнение.
Уточненные предположения – это опыт. Чаще всего они позволяют нам работать быстрее и правильнее. Однако мы можем вообще переместить некоторые вещи, например, правильную обработку malloc, из нашей внутренней категории «простые вещи» во внутреннюю категорию «сложные вещи». И тогда мы действительно можем пойти и уточнить, как они работают.
Если вы разработчик и перед вами стоит задача выбора кодировки, то почти всегда правильным решением будет Юникод. Конкретный способ представления зависит от контекста, но чаще всего тут тоже есть универсальный ответ — UTF-8. Он хорош тем, что позволяет использовать все символы Юникода, не тратя слишком много байт в большинстве случаев. Правда, для языков, использующих не только латиницу, «не слишком много» — это как минимум два байта на символ. Можно ли лучше, не возвращаясь к доисторическим кодировкам, ограничивающим нас всего 256 доступными символами?
Ниже предлагаю ознакомиться с моей попыткой дать ответ на этот вопрос и реализацию относительно простого алгоритма, позволяющего хранить строчки на большинстве языков мира, не добавляя той избыточности, которая есть в UTF-8.Читать полностью »
Данная статья имеет цель собрать воедино и разобрать принципы и механизм работы кодировок текста, подробно этот механизм разобрать и объяснить. Полезна она будет тем, кто только примерно представляет, что такое кодировки текста и как они работают, чем отличаются друг от друга, почему иногда появляются не читаемые символы, какой принцип кодирования имеют разные кодировки.
Чтобы получить детальное понимание этого вопроса придется прочитать и свести воедино не одну статью и потратить довольно значительное время на это. В данном материале же это все собрано воедино и по идее должно сэкономить время и разбор на мой взгляд получился довольно подробный.
О чем будет под катом: принцип работы одно байтовых кодировок (ASCII, Windows-1251 и т.д.), предпосылки появления Unicode, что такое Unicode, Unicode-кодировки UTF-8, UTF-16, их отличия, принципиальные особенности, совместимость и несовместимость разных кодировок, принципы кодирования символов, практический разбор кодирования и декодирования.
Вопрос с кодировками сейчас конечно уже потерял актуальность, но все же знать как они работают сейчас и как работали раньше и при этом не потратить много времени на это думаю лишним не будет.
Читать полностью »
Привет! Двунаправленным письмом в наше время никого не удивить. Оно поддерживается управляющими символами Уникода, для него создан HTML-тег <bdo>. Но горизонтальные письменности – не единственные существующие и применяемые для записи человеческой речи. Кроме обычного слева-направо и справа-налево есть ещё два варианта вертикального письма. Первый – восточно-азиатский, использующийся в языках, основанных на китайском. В них иероглифы идут сверху-вниз, а строки — справа-налево. Этот стиль письма называется "татегаки" по-японски, "шупай" по-китайски и "чонсо" по-корейски. Отмечу, что европейский привычный нам стиль слева-направо в этих трёх языках так же применяется и называется соответственно "йокогаки" по-японски, "хенпай" по-китайски и "хинсо" по-корейски. Именно так, слева-направо, азиатские народы пишут и читают с использованием компьютеров на сегодняшний день. Второй вариант – монгольский, символы идут тоже сверху-вниз, но строки – слева-направо. В современной Монголии этот стиль письма давно заменён европейским, но в некоторых областях Китая до сих пор служит для записи монгольского языка. Так насколько же компьютеры поддерживают такое письмо? Давайте искать вертикальные артефакты в разных приложениях информационных технологий.
Читать полностью »
Как известно, HTTP 1.1 — это текстовой протокол передачи данных. HTTP сообщения закодированы, используя ISO-8859-1 (которую условно можно считать расширенной версией ASCII, содержащей умляуты, диакритику и другие символы, используемые в западноевропейских языках). При этом в теле сообщений можно использовать другую кодировку, которая должна быть обозначена в заголовке «Content-Type». Но что делать, если нам необходимо задать non-ASCII символы не в теле сообщения, а в самих заголовках? Наверное, самый распространенный кейс — это проставление имени файла в «Content-Disposition» заголовке. Это, казалось бы, довольно распространенная задача, но ее реализация не так очевидна.
TL;DR: Используйте кодировку, описанную в RFC 6266, для «Content-Disposition» и преобразуйте текст в латиницу (транслит) в остальных случаях.
Читать полностью »