MatchPlayer77

Извините что ввёл в заблуждение. Уточняю: в момент самого обнаружения (grep пусто / php нашёл) файл между этими двумя командами не менялся - парадокс реальный. Изменился он позже, уже после того как баг был описан - его перезаписал отдельный скрипт, никак не связанный с этим тестом. Поэтому файл, который я проверял на локаль/кодировку - это уже более поздний снимок, не байт-в-байт тот самый. На нём grep и так работает при любой локали - это закрывает гипотезу "локаль мешает искать цифры" как общее объяснение, но проверить её именно на оригинальных байтах уже нельзя, оригинал не сохранился.

Проверил - не подтверждается. grep одинаково находит строку под LC_ALL=C, LC_ALL=C.UTF-8 и LC_ALL=POSIX, разницы нет вообще. Это и ожидаемо: 1627588 - это ASCII-цифры (байты 0x31–0x38), а они кодируются одинаково что в UTF-8, что в CP-1251, что почти в любой другой кодировке. Локаль влияет на вещи вроде классов символов ([[:alpha:]]), регистронезависимого сравнения или сортировки диапазонов [a-z] - но не на поиск буквальной последовательности цифр. Так что красиво, но мимо))

Коротко: JSON - текстовый формат, числа там и так хранятся как обычные символы (1627588 - это семь байт-цифр подряд в UTF-8), никакого бинарного кодирования чисел в JSON нет и быть не может по спецификации. В условии уже показан кусок самого файла - там видно "fixtureId": "1627588", обычная текстовая строка. Так что вопрос не "тупой", но ответ на него - "нет, это не так, и в самом условии это видно"

Коротко: это ничего не прояснит. Убрать -l - покажет не имя файла, а саму строку, но если совпадений нет, вывод всё равно будет пустым (разница только в формате результата, не в том, находит ли grep строку). Полный путь вместо относительного тоже не влияет на поиск по содержимому файла - если файл открылся правильно (а он открылся, раз file/php его читают), путь роли не играет. Сорри что так развернуто ответил.

Всем привет. Разбирал живую проблему на проде сайта aipredict.one (страница матча зависла со старыми данными) и наткнулся на побочную странность. На сервере (Ubuntu, GNU grep) искал число в JSON-файле с архивом матчей сайта: $ user@host:~/aipredict.one$ grep -l '1627588' data/archive/2026-08.json $ Пусто. Файл существует, права на чтение есть, опечаток в числе нет - проверял несколько раз. Тут же, для той же самой строки того же самого файла: $data = json_decode(file_get_contents('data/archive/2026-08.json'), true); foreach ($data as $rec) { if ((string)$rec['fixtureId'] === '1627588') { print_r($rec); // находит без проблем } } PHP находит запись сразу. Файл при этом один и тот же, между командами не менялся. Вопрос: почему grep мог не найти подстроку, которая физически есть в файле и успешно вычитывается другим инструментом? Дайте хотя бы 2-3 гипотезы, объясняющие такое поведение, и как проверить каждую.