информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыПортрет посетителяСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / beginners
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
Да нет, вот конкретно проблем с нулем у utf8 нет 02.10.09 11:25  Число просмотров: 2689
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> То, что помню на вскидку - &#0048; aka unicode-цифра 0;
> и т.п.
Это проблема "старших" utf-ов (от 16-ти). Но там без нарушения типизации и не получится обработать массиво wchar_t как массив однобайтовых char-ов.

> Да, это не обычно, но допустимо, судя по rfc. Я конечно
> могу ошибаться, но первый байт - определяет язык (в смысле
> набор символов) а нуль является дефолтом, который МОЖНО, но
> не обязательно пропускать.
Да, нет. Единственный код, который может привести к появлению байта-нуля в utf8 потоке - это сам L'\0'. Это достаточно очевидно из таблицы http://en.wikipedia.org/wiki/Utf-8#Description
Символы, меньше 128 кодируются самими собой. При кодировании символов больше или равно 128 первый байт всегда имеет старшие два бита в единицах, остальные - только один старший бит (это в частности сделано для возможности синхронизации потока с любого места) - байт со сброшенным старшим битом (в частности 0) появиться просто не может, следовательно если мы видим 0 в потоке utf8, мы можем достоверно утверждать, что это юникод символ с кодом 0, который является терминатором в asciiz (unicode-z или как он там называется в случае юникода).
<beginners>
в чем тут закон? серваки и utf 30.09.09 19:43  
Автор: !? <!?> Статус: Member
Отредактировано 30.09.09 19:44  Количество правок: 1
<"чистая" ссылка>
всегда полагал, что веб серваки ставятся на никсы, а те на utf. одкако сейчас увидел свои сообщения с юникодом и никак в толк не возьму - откуда конверт берётся?
не ожидал никак увидеть амперсанды и символы-инвалиды. думал, будут просто квадраты, как в телефоне вместо неопределённых символов.
тк значит на виндах таки всё стоит? или в разных там солярисах и других неизвестных мне системах тоже всё нетак с кодировками?

upd. с винды увидел, на никсовом маке всё ровно было, кроме имени моего аккаунта здесь.
я могу ошибаться, но опыт подсказывает, что 30.09.09 20:48  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
> всегда полагал, что веб серваки ставятся на никсы, а те на
> utf. одкако сейчас увидел свои сообщения с юникодом и никак
> в толк не возьму - откуда конверт берётся?
я могу ошибаться, но опыт подсказывает, что
1) далеко не все серваки - никсовые - посмотри сколько asp-шных движков?
2) большинство моноязычных сайтов не используют utf-8. Пара примеров: yandex.ru ; mail.ru , конечно же bugtraq.ru
Откуда берется конверт - мне точно не известно. Возможно - браузер, заметив что страница написана в win-1251 перекодирует, а может быть и код на сайте срезает.
> не ожидал никак увидеть амперсанды и символы-инвалиды.
> думал, будут просто квадраты, как в телефоне вместо
> неопределённых символов.
Могу сказать наверняка -- если при отправке формы используется кодировка отличная от той, которую ожидает сервер -- огромная вероятность того, что результат будет сильно отличаться от желанного эффекта.
Один из примеров: мелочь-мелочью, но utf-ки зачастую напичканы нулевыми байтами (\x0). в результате могут возникнуть (и иногда возникают) проблемы с функциями, определяющими конец строки по с-принципу: нулевому байту в конце.
В том числе и из-за этого многие программисты очень жестко обходятся с utf-строками, если не ожидают их получить: "не подходит под стандартные критерии?! Значит ня какая-то!"
> тк значит на виндах таки всё стоит? или в разных там
> солярисах и других неизвестных мне системах тоже всё нетак
> с кодировками?
Не факт. ОС web-сервера и кодировки на данный момент не связаны друг с другом.

> upd. с винды увидел, на никсовом маке всё ровно было, кроме
> имени моего аккаунта здесь.
По поводу utf-ов 30.09.09 22:10  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Один из примеров: мелочь-мелочью, но utf-ки зачастую
> напичканы нулевыми байтами (\x0). в результате могут
Я utf8 не люблю за плавающую длину сивола (в utf16 она тоже формально плавающая, но фактически все на это забивают - даже CJK почти весь находится на BOM, а на остальных плевать), но справедливости ради стоит отметить, что 0 там может появиться только при кодировании символа с кодом 0. То есть в utf8 поиск конца asciiz строки тоже будет работать (другое дело, что количество символов, посчитанное функциями для работы с acsiiz будет неправильным).
Не соображу, как именно показать, но натыкался на проблемы с... 30.09.09 23:27  
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 30.09.09 23:38  Количество правок: 4
<"чистая" ссылка>
> > Один из примеров: мелочь-мелочью, но utf-ки зачастую
> > напичканы нулевыми байтами (\x0). в результате могут
> Я utf8 не люблю за плавающую длину сивола (в utf16 она тоже
> формально плавающая, но фактически все на это забивают -
> даже CJK почти весь находится на BOM, а на остальных
> плевать), но справедливости ради стоит отметить, что 0 там
> может появиться только при кодировании символа с кодом 0.
> То есть в utf8 поиск конца asciiz строки тоже будет
> работать (другое дело, что количество символов, посчитанное
> функциями для работы с acsiiz будет неправильным).
Не соображу, как именно показать, но натыкался на проблемы с "нулем". Если найду в архивах -- обязательно приведу еще пару примеров.

То, что помню на вскидку - &#0048; aka unicode-цифра 0; и т.п.
Да, это не обычно, но допустимо, судя по rfc. Я конечно могу ошибаться, но первый байт - определяет язык (в смысле набор символов) а нуль является дефолтом, который МОЖНО, но не обязательно пропускать.
Да нет, вот конкретно проблем с нулем у utf8 нет 02.10.09 11:25  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> То, что помню на вскидку - &#0048; aka unicode-цифра 0;
> и т.п.
Это проблема "старших" utf-ов (от 16-ти). Но там без нарушения типизации и не получится обработать массиво wchar_t как массив однобайтовых char-ов.

> Да, это не обычно, но допустимо, судя по rfc. Я конечно
> могу ошибаться, но первый байт - определяет язык (в смысле
> набор символов) а нуль является дефолтом, который МОЖНО, но
> не обязательно пропускать.
Да, нет. Единственный код, который может привести к появлению байта-нуля в utf8 потоке - это сам L'\0'. Это достаточно очевидно из таблицы http://en.wikipedia.org/wiki/Utf-8#Description
Символы, меньше 128 кодируются самими собой. При кодировании символов больше или равно 128 первый байт всегда имеет старшие два бита в единицах, остальные - только один старший бит (это в частности сделано для возможности синхронизации потока с любого места) - байт со сброшенным старшим битом (в частности 0) появиться просто не может, следовательно если мы видим 0 в потоке utf8, мы можем достоверно утверждать, что это юникод символ с кодом 0, который является терминатором в asciiz (unicode-z или как он там называется в случае юникода).
Признаю свою вину, меру степень, глубину. Понапутал я с нулем. 04.10.09 15:17  
Автор: kstati <Евгений Борисов> Статус: Elderman
<"чистая" ссылка>
до отображающего скрипта все уже доходит в таком виде 30.09.09 20:00  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Он только меняет &# на &amp;#. Если этого не делать, то все хитрые символы воспроизведутся, но будет разнобой, например, с rss, где замена & на &amp; обязательна.

Где проходит перекодировка, по пути от браузера, или при записи в таблицу, сходу сказать не могу. utf и юниксы вообще сбоку, как настроить конкретный сервис, так и будет. Сейчас mysql-таблицы не в utf, поскольку нет задачи поддерживать толпу языков, а разбухание на ровном месте в два раза ни к чему.
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach