Re[4]: PCRE, UTF-8 и wchar_t - C/C++. Прикладные вопросы

Не подскажет ли уважаемая общественность, как мне строки wchar_t закодированные как UTF-8 обрабатывать с помощью PCRE, в документации написано, что есть поддержка UTF-8, а функции принимают только строки char.

PS. Версия PCRE у меня 3.9. Новее нельзя. Никак.
PPS. Про boost::regex знаю, пробовал, все круто, но нельзя. Никак.

Dr.Offset пишет:

> Не подскажет ли уважаемая общественность, как мне строки wchar_t
> закодированные как UTF-8 обрабатывать с помощью PCRE, в документации
> написано, что есть поддержка UTF-8, а функции принимают только строки char.

UTF-8 -- это так называемый wide-character string, это char*, а не wchar_t*.

Так что с PCRE всё в порядке.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MasterZiv, Вы писали:

MZ>Dr.Offset пишет:

>> Не подскажет ли уважаемая общественность, как мне строки wchar_t
>> закодированные как UTF-8 обрабатывать с помощью PCRE, в документации
>> написано, что есть поддержка UTF-8, а функции принимают только строки char.

MZ>UTF-8 -- это так называемый wide-character string, это char*, а не wchar_t*.

Если в большинстве случаев UTF-8 можно читать в char*, это не значит, что во всех

MZ>Так что с PCRE всё в порядке.

Так я и не говорю, что не в порядке. Я спрашиваю как быть.

Здравствуйте, Dr.Offset, Вы писали:
DO>Если в большинстве случаев UTF-8 можно читать в char*, это не значит, что во всех

А как ты себе представляешь utf8 не в char*?

Здравствуйте, MasterZiv, Вы писали:

MZ>UTF-8 -- это так называемый wide-character string, это char*, а не wchar_t*.

Кстати, wide-string это как раз wchar_t.

UTF-8 это — [0..255]. Ясно, что в char не помещается. Зато помещается в unsigned char. Вопрос с PCRE по-прежнему открыт...

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Dr.Offset, Вы писали:
DO>>Если в большинстве случаев UTF-8 можно читать в char*, это не значит, что во всех

MC>А как ты себе представляешь utf8 не в char*?

Параллельную ветку смотри.

Здравствуйте, Dr.Offset, Вы писали:

DO>Здравствуйте, MasterZiv, Вы писали:

MZ>>UTF-8 -- это так называемый wide-character string, это char*, а не wchar_t*.

DO>Кстати, wide-string это как раз wchar_t.

DO>UTF-8 это — [0..255]. Ясно, что в char не помещается. Зато помещается в unsigned char. Вопрос с PCRE по-прежнему открыт...

Во-первых, то, что для Вас char по умолчанию тождественен signed char и Вы не предполагаете иного — уже показательно.

Во-вторых — а не будет ли любезен благородный дон показать пример, когда signed char не проходит для таких применений? Только, пожалуйста, на реальных платформах и без сферических извращений в вакууме.

Здравствуйте, netch80, Вы писали:

N>Во-первых, то, что для Вас char по умолчанию тождественен signed char и Вы не предполагаете иного — уже показательно.

Грубо выдирая твои слова из контекста, хочу отметить, что никогда char не тождественен signed char или unsigned char:

void foo(char)
{
}

void foo(signed char)
{
}

void foo(unsigned char)
{
}

template<typename T>
struct bar;

template<>
struct bar<char>
{
};

template<>
struct bar<signed char>
{
};

template<>
struct bar<unsigned char>
{
};

Т.е. это три совершенно разных человека.

Здравствуйте, netch80, Вы писали:

N>Во-первых, то, что для Вас char по умолчанию тождественен signed char и Вы не предполагаете иного — уже показательно.

TIGCC. Я не могу менять знаковость char только потому что мне так захотелось.

N>Во-вторых — а не будет ли любезен благородный дон показать пример, когда signed char не проходит для таких применений? Только, пожалуйста, на реальных платформах и без сферических извращений в вакууме.

Можно без сарказма и лишнего пафоса обойтись. Хамства вашего я ничем не заслужил.

Здравствуйте, Dr.Offset, Вы писали:

DO>Не подскажет ли уважаемая общественность, как мне строки wchar_t закодированные как UTF-8 обрабатывать с помощью PCRE, в документации написано, что есть поддержка UTF-8, а функции принимают только строки char.

Посмотри внутри у своего PCRE как он интерпретирует char как знаковый или нет.
То что он снаружи принимает char* вообще ни о чем не говорит.

Здравствуйте, Dr.Offset, Вы писали:

N>>Во-первых, то, что для Вас char по умолчанию тождественен signed char и Вы не предполагаете иного — уже показательно.
DO>TIGCC.

И что?

DO> Я не могу менять знаковость char только потому что мне так захотелось.

Так всё-таки — там что, байты другие? У них не 8 бит? И представление одной и той же текстовой строки в восьмибитной кодировке будет иначе интерпретировано как текст в зависимости от того, написано signed или unsigned? Я хочу на это посмотреть.;))

N>>Во-вторых — а не будет ли любезен благородный дон показать пример, когда signed char не проходит для таких применений? Только, пожалуйста, на реальных платформах и без сферических извращений в вакууме.
DO>Можно без сарказма и лишнего пафоса обойтись. Хамства вашего я ничем не заслужил.

Ну да, как вопрос по сути — так сразу "хамство". Так всё-таки расскажете? Пока что я не вижу никаких признаков того, что тут есть проблемы. Конверсия между строками типа char, unsigned char, signed char в ваших условиях возможна во все стороны без проблем для содержимого (хотя с очевидными проблемами для интерпретации в ряде случаев).

Здравствуйте, -MyXa-, Вы писали:

N>>Во-первых, то, что для Вас char по умолчанию тождественен signed char и Вы не предполагаете иного — уже показательно.
MX>Грубо выдирая твои слова из контекста, хочу отметить, что никогда char не тождественен signed char или unsigned char:

Поправка тут действительно нужна — следовало сказать "по поведению" и процитировать стандарт:

The implementation shall define char to have the same range,
representation, and behavior as either signed char or unsigned char.

(C99, пункт 6.2.5.15)

MX>

MX>void foo(char)
MX>{
MX>}

MX>void foo(signed char)
MX>{
MX>}
MX>

А вот это уже не совсем к месту — контекст данного треда — C, а не C++.

MX>Т.е. это три совершенно разных человека.

:)))

Здравствуйте, Dr.Offset, Вы писали:
DO>Параллельную ветку смотри.
Ты про это что-ли?

UTF-8 это — [0..255]. Ясно, что в char не помещается.

Utf8 пофиг на числа — биты и байты играют роль.

Здравствуйте, c-smile, Вы писали:

CS>Посмотри внутри у своего PCRE как он интерпретирует char как знаковый или нет.
CS>То что он снаружи принимает char* вообще ни о чем не говорит.

А можно в двух словах, каким образом знаковость влияет на работу PCRE?

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Dr.Offset пишет:

> MZ>UTF-8 -- это так называемый wide-character string, это char*, а не
> wchar_t*.
>
> Если в большинстве случаев UTF-8 можно читать в char*, это не значит,
> что во всех

Можно читать во всех случаях. Лишь бы буфер был достаточного размера.

>
> MZ>Так что с PCRE всё в порядке.
>
> Так я и не говорю, что не в порядке. Я спрашиваю как быть.

Не хранить UTF-8 строки в массивах wchar_t.

Posted via RSDN NNTP Server 2.1 beta

Dr.Offset пишет:

> MZ>UTF-8 -- это так называемый wide-character string, это char*, а не
> wchar_t*.
>
> Кстати, wide-string это как раз wchar_t.

Блин, конечно же, описался.

multi-byte character string , MBCS, MBS

Posted via RSDN NNTP Server 2.1 beta

Кодт пишет:

> CS>То что он снаружи принимает char* вообще ни о чем не говорит.
>
> А можно в двух словах, каким образом знаковость влияет на работу PCRE?

Да никаким не влияет.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Кодт, Вы писали:

К>А можно в двух словах, каким образом знаковость влияет на работу PCRE?

Да вот тебе пример из жизни:

#include <memory.h>

unsigned char u8text[] = { 0xEF, 0xBB, 0xBF, 'H', 'i', '!' };

bool has_bom( const char* u8text )
{
  return u8text[0] == 0xEF &&
         u8text[1] == 0xBB &&
         u8text[2] == 0xBF;
}

int main(int argc, char* argv[])
{
    printf("has UTF-8 BOM %d\n", has_bom((const char*)u8text) );
    return 0;
}

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, Кодт, Вы писали:

К>>А можно в двух словах, каким образом знаковость влияет на работу PCRE?

CS>Да вот тебе пример из жизни:

CS> return u8text[0] == 0xEF &&
CS> u8text[1] == 0xBB &&
CS> u8text[2] == 0xBF;

И что? Вижу пример, как знаковость влияет на плохо написанный код. Но не вижу, как она влияет на работу PCRE. Следует помнить, что это библиотека с длинной историей, богатой функциональностью и огромным накопленным опытом мультиплатформенного применения, и уж такими мелочами, как signed char, её не сломать.

Здравствуйте, c-smile, Вы писали:

К>>А можно в двух словах, каким образом знаковость влияет на работу PCRE?

CS>Да вот тебе пример из жизни:

Я понимаю, как можно самому накосячить со знаковостью. Интересно другое: есть ли такие косяки именно в PCRE?
Не обязательно детские, типа того, который ты привёл. А, например, такое
"/[\x70-\x90]/" — поддержка диапазонов, пересекающих черту ASCII

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, c-smile, Вы писали:

CS>>Здравствуйте, Кодт, Вы писали:

К>>>А можно в двух словах, каким образом знаковость влияет на работу PCRE?

CS>>Да вот тебе пример из жизни:

CS>> return u8text[0] == 0xEF &&
CS>> u8text[1] == 0xBB &&
CS>> u8text[2] == 0xBF;

N>И что? Вижу пример, как знаковость влияет на плохо написанный код. Но не вижу, как она влияет на работу PCRE. Следует помнить, что это библиотека с длинной историей, богатой функциональностью и огромным накопленным опытом мультиплатформенного применения, и уж такими мелочами, как signed char, её не сломать.

Я собственно не про PCRE а про то что unsigned char как тип эта та соломка которую подстилают при работе с utf-8.
Чтобы не было таких косяков на пустом месте.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, c-smile, Вы писали:

К>>>А можно в двух словах, каким образом знаковость влияет на работу PCRE?

CS>>Да вот тебе пример из жизни:

К>Я понимаю, как можно самому накосячить со знаковостью. Интересно другое: есть ли такие косяки именно в PCRE?
К>Не обязательно детские, типа того, который ты привёл. А, например, такое

Там блин вест файл был написан не по детски т.е. все нормально было со знаковостью ибо был изначальный каст на unsigned char*
но вот одно такое место (как я привел) привело к не детским последствиям.

К>"/[\x70-\x90]/" — поддержка диапазонов, пересекающих черту ASCII

Это вот как раз очевидный test case. Гораздо интереснее будет скажеи вот такое "/[\x70-\xC3]/"

Здравствуйте, c-smile, Вы писали:

К>>Я понимаю, как можно самому накосячить со знаковостью. Интересно другое: есть ли такие косяки именно в PCRE?
К>>Не обязательно детские, типа того, который ты привёл. А, например, такое

CS>Там блин вест файл был написан не по детски т.е. все нормально было со знаковостью ибо был изначальный каст на unsigned char*
CS>но вот одно такое место (как я привел) привело к не детским последствиям.

В смысле, ты процитировал исходники PCRE?! Тогда — вау!

К>>"/[\x70-\x90]/" — поддержка диапазонов, пересекающих черту ASCII

CS>Это вот как раз очевидный test case. Гораздо интереснее будет скажеи вот такое "/[\x70-\xC3]/"

А здесь что за заподло? Имеется в виду, что 0xC3 — это голова мультибайта, или что?

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, Кодт, Вы писали:

К>>>"/[\x70-\x90]/" — поддержка диапазонов, пересекающих черту ASCII

CS>>Это вот как раз очевидный test case. Гораздо интереснее будет скажеи вот такое "/[\x70-\xC3]/"

К>А здесь что за заподло? Имеется в виду, что 0xC3 — это голова мультибайта, или что?

А вот

что оно такое в свете PCRE и utf-8 support. Т.е. там не только проверка диапазона start < end но еще и коллизии с запрещенными utf-8 комбинациями. Вообще PCRE внутри должен оперировать uchar_t который есть uint21.

Здравствуйте, c-smile, Вы писали:

N>>И что? Вижу пример, как знаковость влияет на плохо написанный код. Но не вижу, как она влияет на работу PCRE. Следует помнить, что это библиотека с длинной историей, богатой функциональностью и огромным накопленным опытом мультиплатформенного применения, и уж такими мелочами, как signed char, её не сломать.

CS>Я собственно не про PCRE а про то что unsigned char как тип эта та соломка которую подстилают при работе с utf-8.
CS>Чтобы не было таких косяков на пустом месте.

Ну это и так понятно. Но я бы акценты сместил: я вообще не понимаю, какого аккредитива и зачем был введён и используется signed char, а тем более кто и зачем включает его по умолчанию. Это же постоянные грабли на ровном месте.

	От:	Dr.Offset
	Дата:	07.09.09 17:23
	Оценка:

	От:	MasterZiv
	Дата:	07.09.09 18:18
	Оценка:

	От:	Dr.Offset
	Дата:	07.09.09 18:30
	Оценка:

	От:	Mr.Cat
	Дата:	07.09.09 18:36
	Оценка:

	От:	Dr.Offset
	Дата:	07.09.09 18:39
	Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	07.09.09 19:09
Оценка:	+1

От:	c-smile	http://terrainformatica.com
Дата:	07.09.09 20:26
Оценка:	2 (1)