Что только что произошло с этим текстом? и как мне это исправить?

Итак, клиент работает с MoodleCloud, и кажется, что каждый раз, когда мы загружаем файл, формат немного отличается от предыдущего.

Последний — это список в виде обычного текста, но я предполагаю, что кодировка utf другая. В текстовом редакторе текст выглядит нормально Когда я отлаживаю импорт, все выглядит нормально Но когда я просматриваю источник отладки, я вижу это

 \0\0m\0o\0w\0o\0g\0

Код (разметка): становится

 m o w o g

Код (разметка): и помещенный в запрос, он становится

 mowog

Код (разметка): Как мне с этим справиться?

В итоге я поместил его в электронную таблицу, а затем экспортировал в формате CSV, чтобы получить чистую копию.

Это процесс, который выполняется раз в месяц для одного файла, так что я могу с этим жить.

Загружено через обычную форму. И да, быстро придя к пониманию того, что касается Moodle, но это не мое решение, я просто занимаюсь загрузкой и выгрузкой студентов.

Разве \0 не является конечным символом, добавленным в конце полей char и varchar в базах данных?

Если персонаж присутствует в необработанном загруженном файле, его можно удалить следующим образом:

$c= //ваши данные

$c= str_replace( "\0", "", $c );

Я думаю, что рассматриваемый сервер готовит файл по 1 байту за раз, что может быть причиной проблемы.

Хотя не уверен.

Просто чтобы лучше проиллюстрировать нулевое завершение и различия MySQL char и varchar:

"тест" VARCHAR(8) == 0x04 0x74 0x65 0x73 0x74

«тестовый» CHAR(8) == 0x74 0x65 0x73 0x74 0x00 0x00 0x00 0x00 0x00

Хотя на практике varchar, скорее всего, также резервирует 9 байт, поскольку длина указывается первой, не имеет значения, что там находится, ни один код никогда не должен пытаться получить доступ к длине, превышающей эту длину.

При нулевом завершении общепринятой практикой является заполнение всего поля нулем.

Это означает запись большего количества данных, чем вам нужно, и это означает, что если на уровне C или ASM вы облажаетесь с проверкой на ноль, вы начнете перезаписывать любые переменные, которые появятся после.

Это буквально УМОЛЯЕТ об ошибках типа «переполнение буфера». Как и все другие глупые ошибки, синтаксические языки C и C ЛЮБЯТ поощрять. Вот почему я говорю, что Керниган может пойти и пососать яйцо. C не мой любимый язык программирования.

Почти наверняка это несоответствие кодировки, но трудно сказать, какая именно.



Правильно ли установлена кодировка в заголовках http? Правильно ли оно было загружено? Была ли кодировка принятия несоответствующей настройкам сервера, если она была загружена через http? Если он был загружен через FTP, был ли он настроен на двоичную передачу, а не на автоматическое обнаружение текста по умолчанию, который ВСЕГДА искажал вещи и должен быть полностью удален с FTP?

Тем не менее, недавно у меня был клиент на Moodle, где это было просто сломанное и неуправляемое дерьмо.

Это симпатичный инструмент обучения, но пытаться использовать его для живых веб-сайтов в лучшем случае безрассудно, а в худшем — жалкая шутка.

Первое, что я бы попробовал, — это перейти на более традиционный стек разработки и хостинг, даже просто для тестирования. Особенно учитывая это дерьмовое шоу, их тошнит и они имеют явную наглость называть HTML.

Все признаки «глазных банок haz teh intarweb duvalupmunt» — незнание самых основных аспектов создания сайтов, где «Для людей, которые ничего не знают о веб-сайтах, людьми, которые НИЧЕГО о веб-сайтах не знают» — это не рецепт успеха.

Просто просмотрите исходный код любого сайта, созданного с его помощью, чтобы получить достаточное доказательство этого.

Просто еще одна афера, питающаяся надеждами и принятием желаемого за действительное, СОЗДАННАЯ людьми, не имеющими квалификации для работы в этой отрасли, не говоря уже о том, чтобы учить других, как что-то делать.

@sarahk

Не заменяйте "\0" двойными кавычками.

Замените '\0' одинарными кавычками.

«\0» — это одиночный нулевой символ для PHP,

но если вы видите этот символ в блокноте и т. д., это означает, что это два отдельных символа: «\» и «0».

'\0' заменит их.

Но я думаю, что поскольку вы присвоили ему тип строки, PHP уже выполнил преобразование '\0' в нулевой "\0", и именно поэтому это сработало.

Это называется «нулевое завершение», и это действительно дерьмовый способ обработки строк. Следовательно, это строковый тип по умолчанию, а также многие другие потоки данных в C, и это лишь часть того, почему C и большинство вещей, основанных на нем, являются тупицами.



Обычно большинство SQL-движков, таких как MySQL, НЕ используют нулевое завершение, предпочитая быть «ограниченными по длине», что означает, что целое число без знака, хранящееся в виде байта, слова, двойного слова или даже qword, используется, чтобы сказать, как долго строка находится в самом начале.



начало данных, чтобы вы знали, где они заканчиваются, ПРЕЖДЕ ЧЕМ дойдете до конца.

Иногда это называют строками в стиле Паскаля. Они позволяют более эффективно и быстро выполнять строковые операции, по крайней мере, на архитектурах на базе Intel. Вот почему в MySQL типы tinytext/tinybob имеют ограничение в 255 байт, но занимают 256, то есть 8 бит.



text/blob использует длину серии 16 бит, поэтому максимальная длина составляет 65534, поскольку из размера структуры данных необходимо отнять два байта (65536/0x010000). То же самое для среднего текста/среднего блоба, которые имеют размер 24 бита, поэтому предел на 3 байта меньше, или для длинного текста/длинного блоба, который на 4 байта меньше 32-битного беззнакового предела, поскольку для хранения длины используются 4 байта.

Хотя, думаю, я знаю, что это такое, благодаря тому, что @JEET поднял эту тему.

Они, вероятно, используют CHAR вместо VARCHAR в своей базе данных, что действительно приводит к добавлению в строку экранированного нуля, поскольку CHAR - единственная строка с нулевым завершением в MySQL.

(Я думаю, не цитируйте меня по этому поводу). Отчасти поэтому CHAR предназначен для дураков и, как известно, несет в себе всевозможный хаос, включая переполнение буфера и эксплойты выполнения... почему? Потому что нулевое завершение — это тупое дерьмо. Вероятно, это помехи нулевого завершения, а НЕ проблема с кодировкой, поэтому я беру обратно свой предыдущий пост и часть «почти наверняка»! Я почти полностью забыл, что CHAR - это дерьмо "I canz teh prugram?" подход к обработке строк с нулевым завершением; пережиток мэйнфреймов 1970-х годов, который должен был там остаться. Но вместо этого программисты на C думают, что все строки должны работать.

Проходит месяц, и я снова возвращаюсь к этой задаче. Код, который, кажется, работает - сама по себе строка str_replace не работала, мне тоже нужно было ее (строку).

 $email = str_replace(['"',"\0"],'', (string) $details[1]);

PHP: