Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
jsonObj_t *__jsonLoad(const char *_str_json, size_t _len_str_json, jsonErr_t *_error) {
jsonObj_t *obj_json = NULL;
jsonObj_t *obj_json_children = NULL; // Тут будет зиждется объект
jsonObj_t *obj_json_tmp = NULL; // Тут будет зиждется объект
size_t index_in_json_str = 0;
size_t len_key = 0; // Размер извлекаемого ключа
size_t len_value = 0; // Размер извлекаемого значения
size_t count_hooks = 0; // Счётчик скобок, чтобы игнорировать их при чтении объекта
uint8_t flag_found_separator = 0; // Флаг чтения ключа
uint8_t flag_found_start = 0; // Флаг начало JSON-объекта
// uint8_t flag_found_end = 0; // Флаг окончания JSON-объекта
uint8_t flag_read_key = 0; // Флаг чтения ключа
uint8_t flag_read_force_read = 0; // Флаг-костыль для ситуаций, когда число последнее в массиве
uint8_t flag_read_value = 0; // Флаг чтения значения
uint8_t flag_read_array = 0; // Флаг чтения и обработки массива
uint8_t flag_want_value = 0; // Флаг ожидания значения
// (выставляется после успешно прочитанного ключа)
jsonErr_t json_err = JSON_OK;
int res = 0;
jsonValueType_t type_expected_value = JSON_VALUE_NONE; // Ожидаемы тип считываемого значения
char chr_open = '\0';
char chr_close = '\0';
const char *ptr_key = NULL; // Указатель на начало извлекаемого ключа
const char *ptr_value = NULL; // Указатель на начало извлекаемого значения
if (_error != NULL)
{
*_error = JSON_OK;
}
for (index_in_json_str = 0; index_in_json_str < _len_str_json; ++index_in_json_str)
{
// Если начало JSON-объекта не найдено, то пропускать
if (flag_found_start == 0)
{
// Поиск начала JSON-объекта
if (_str_json[index_in_json_str] == '{')
{
flag_found_start = 1;
}
if (_str_json[index_in_json_str] == '[')
{
flag_found_start = 1;
flag_read_array = 1;
flag_want_value = 1;
flag_found_separator = 1; // Сразу после знака "[" ожидается значение
}
continue;
}
// Обработка ключа
if ((flag_read_key == 0) &&\
(flag_read_value == 0) &&\
(flag_want_value == 0) &&\
(flag_read_array == 0))
{
if (((_str_json[index_in_json_str] == '\"') || (_str_json[index_in_json_str] == '\'')))
{
chr_close = _str_json[index_in_json_str];
flag_read_key = 1; // Флаг начало чтения ключа
if ((index_in_json_str + 1) != _len_str_json)
{
ptr_value = (const char *)(_str_json + index_in_json_str + 1);
len_value = 1;
}
else
{
if (_error != NULL)
{
*_error = JSON_ERR_BAD_JSON;
}
jsonFree(obj_json);
return (NULL);
}
}
continue;
}
// Обработка значения
if ((flag_want_value == 1) && (flag_read_value == 0))
{
// Поиск разделителя ключа и значения
if (flag_found_separator == 0)
{
if ((_str_json[index_in_json_str] == ']') && (flag_read_array == 1))
{
// flag_found_end = 1;
Либа продакшеновая, эта функция около 470 строк кода, всё не вместилось... Нет, индусов у нас нет, как и ответственного за качество кода тоже) и да это ещё один парсер. Опирается ли он на спецификацию JSON? Нет конечно же, боже упаси, зачем? Зато она прекрасно понимает TRUE как true и FALSE как false, а ваши жалкие либы такого не могут
Вай нот? При парсинге жсона нету особого смысла декодить utf-8, всякие кавычки да слеши всё равно однобайтовые и с теми же кодами, что и в ascii. Достаточно проверить, что битых и неканоничных последовательностей нету. Ну и \u и \x раскрыть в utf-8 последовательности.
Подстроки в utf-8 вполне нормально ищутся, если тебя binary collation устраивает. Да и клеятся норм.
А если дело до реальной поддержки юникода дойдёт, то перевод во всякие wchar_t ничем тебе не поможет. Всё равно понадобится какое-нибудь icu. А оно и utf-8 хавает.
Ну считай это вторым питоном. Там тоже str был пачкой байт, а юникод хранился в unicode. Просто кресты и няшная - не питон, они не могут себе позволить переименование.
З.Ы. Ну и что ты предлагаешь юзать вместо char'ов? wchar_t неизвестной длины? char16_t, в котором эмодзи два слота занимают? char32_t, который жрёт кучу места, а полноценной работы с юникодом всё равно не даёт?
A string begins and ends with
quotation marks. All Unicode characters may be placed within the
quotation marks, except for the characters that MUST be escaped:
quotation mark, reverse solidus, and the control characters (U+0000
through U+001F).
но в то же время
When all the strings represented in a JSON text are composed entirely
of Unicode characters [UNICODE] (however escaped), then that JSON
text is interoperable in the sense that all software implementations
that parse it will agree on the contents of names and of string
values in objects and arrays.
а я так понял, что interoperable считается только эскейпнутый (и у меня есть опыт с поджаренной задницей по этому поводу на стыке java(jackson) и json_decode из пшп)
Ну там было ещё старое rfc, где любые кодировки разрешались. Возможно, что какие-то парсеры, которые сделаны по старому rfc, брали кодировку из локали. Хуй знает.
Вай нот? При парсинге жсона нету особого смысла декодить utf-8, всякие кавычки да слеши всё равно однобайтовые и с теми же кодами, что и в ascii. Достаточно проверить, что битых и неканоничных последовательностей нету. Ну и \u и \x раскрыть в utf-8 последовательности.
А если дело до реальной поддержки юникода дойдёт, то перевод во всякие wchar_t ничем тебе не поможет. Всё равно понадобится какое-нибудь icu. А оно и utf-8 хавает.
strstr(s, u8"хуй") без проблем работает.
Тогда всё ок
* чары
* байты
конвертация между ними всегда происходит явно, и с указанием кодировки (чарсета).
Так что в этих языках я бы увидел там byte, и не триггернулся бы так)
Ну разве что icu::UnicodeString или QString.
это было заебись во времена однобаайтовых кодировок, но сейчас это путает питухов
вот у MS есть define чтобы char называть BYTE, это удобно.
Ну и правильно. Это же байт, а не число.
но немного пугает to_integer
A string begins and ends with
quotation marks. All Unicode characters may be placed within the
quotation marks, except for the characters that MUST be escaped:
quotation mark, reverse solidus, and the control characters (U+0000
through U+001F).
но в то же время
When all the strings represented in a JSON text are composed entirely
of Unicode characters [UNICODE] (however escaped), then that JSON
text is interoperable in the sense that all software implementations
that parse it will agree on the contents of names and of string
values in objects and arrays.
https://tools.ietf.org/html/rfc8259#section-7