Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
| | | |
Да нет, вот конкретно проблем с нулем у utf8 нет 02.10.09 11:25 Число просмотров: 3445
Автор: amirul <Serge> Статус: The Elderman
|
> То, что помню на вскидку - 0 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 будет неправильным).
Не соображу, как именно показать, но натыкался на проблемы с "нулем". Если найду в архивах -- обязательно приведу еще пару примеров.
То, что помню на вскидку - 0 aka unicode-цифра 0; и т.п.
Да, это не обычно, но допустимо, судя по rfc. Я конечно могу ошибаться, но первый байт - определяет язык (в смысле набор символов) а нуль является дефолтом, который МОЖНО, но не обязательно пропускать.
|
| | | |
Да нет, вот конкретно проблем с нулем у utf8 нет 02.10.09 11:25
Автор: amirul <Serge> Статус: The Elderman
|
> То, что помню на вскидку - 0 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>
|
Он только меняет &# на &#. Если этого не делать, то все хитрые символы воспроизведутся, но будет разнобой, например, с rss, где замена & на & обязательна.
Где проходит перекодировка, по пути от браузера, или при записи в таблицу, сходу сказать не могу. utf и юниксы вообще сбоку, как настроить конкретный сервис, так и будет. Сейчас mysql-таблицы не в utf, поскольку нет задачи поддерживать толпу языков, а разбухание на ровном месте в два раза ни к чему.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
