Форум PHP

Тема письма на кириллице в utf-8 отображается корректно, а тело письма (сообщение) на кириллице выдаёт "кракозябры". Почему???

На счет размера страниц памяти я как-то не думал. Теперь не спорю.

А письма действительно не доходят из-за ограничений хостинга.
Буду переезжать.

>Вы извините, я Ваших доводов не понимаю.
>Вы приводите факты, подтверждающие лишь то, что кодировать нужно кратное 3 число байт,
>а также то, что символы перевода строки (и все остальное) игнорируются при декодировании.

Если переводы строки все сплошь игнорировать , все кусочки окажутся вытянутыми в одну большую строку.
При этом абсолютно все равно, где были разрывы - через 3 символа, через 33 или через 3000.

Понятно, почему при некратном буфере происходит ошибка - у Вас просто не заполняется битами до конца четверка символов.

Непонятно, почему Вы считаете 3 осмысленной кратностью. Непонятно, но не особо интересно.
76 символов (выбранных функцией chunk_split) это 76/4 * 3 = 57 байт.
Вот эти 57 байт и есть осмысленная кратность.
Другая осмысленная кратность - размер физического сектора устройства - 512 байт (следствие архитектуры устройств внешней памяти)
Третья осмысленная кратность - распространенный размер страницы виртуальной памяти - 4096 байт (следствие процессорной архитектуры ) .
Умножьте одно на другое - получите эти числа.
Дальнейший спор считаю бессмысленным.

Ну а что двадцатиметровые письма не доходят - так может на сервере ограничение действует?

Вы извините, я Ваших доводов не понимаю.
Вы приводите факты, подтверждающие лишь то, что кодировать нужно кратное 3 число байт,
а также то, что символы перевода строки (и все остальное) игнорируются при декодировании.

Вкупе это подтверждает мой довод Выше Вашего последнего сообщения о том, что буфер
нужно выбирать кратным трем, а строки длинной менее 76 симавлов, которые могут появиться
в середине закодированного текста (на границах блока) не на что не повлияют.

Почему же:
> Фактически, буфер у Вас должен быть размером, кратным 58368,
> ну иль на худой конец - 29184.
> А если не сильно жалко - 233472.

?

P.S. Мои письма с файлом 20 Мб так и не доходят, хотя с небольшими (1-2) Мб все нормально
и на большие smtp сервер говорит "Ok". Экспериментирую с разными почтовыми сервисами.

Но письма не доходат не из-за обсуждаемого нами сейчас вопроса (размера буфера), поскольку в этом случае теряется аттач, но письмо приходит.

>Так ведь совершенно не обязательно, чтобы в закодированном виде все строки были
>одинаковой длины.

Почему?

>Важно чтобы исходные данные были кратны трем, тогда Base64 не будет выравнивать блок до 3 байтов нулями.

Это ваше "Важно" важно не более и не менее, чем мое "обязательно" из абзаца выше.

Если Вы заглянете в стандарт, то увидите, что исходные данные вовсе не обязаны быть кратны трем, как и выходные - четырем:

----
The encoded output stream must be represented in lines of no more
than 76 characters each. All line breaks or other characters not
found in Table 1 must be ignored by decoding software.
----
Выходной поток (закодированные байты) должен иметь длину строк не более 76 символов.
Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны
быть проигнорированы декодером base64.

Так ведь совершенно не обязательно, чтобы в закодированном виде все строки были
одинаковой длины. Важно чтобы исходные данные были кратны трем, тогда Base64 не будет выравнивать блок до 3 байтов нулями.

Строки:

3fLuIO/w7uLl8O737e7l IPHu7uH55e3o5Swg5Ovo 7e3gIOru8u7w7uPuIOHu 6/z45SAyMCDh4Ony и 3fLuIO/w7uLl8O737e7lIPHu7uH55e3o5Swg5Ovo7e 3gIOru8u7w7uPuIOHu6/z45SAyMCDh4Ony

декодируются одинаково.

>Поясните откуда цифры, пожалуйста. Не понял.
>chunk_split(), режет длинную base64 строку на короткие, разделенные \r\n.
на короткие строки, какой именно длины?
Понятно же, что выход должен быть кратен этой длине.
Иначе возникнут обрывки ничем не оправданные.

>(для строки > 76 символов)

Сколько байт исходного потока создаст 76 символов потока сообщения?
Совершенно очевидно, это не единственная кратнось, которую желательно предусмотреть при буферизации.
Какой еще кратный множитель выберем (читайте - Вы выбрали уже)?

Поясните откуда цифры, пожалуйста. Не понял.
chunk_split(), режет длинную base64 строку на короткие, разделенные \r\n.
Но для base64 нет символа \r\n, поэтому

base64_decode(chunk_split(base64_encode($string))) = $string

(для строки > 76 символов)

Или я где-то не прав? Вышеприведенную функцию проверял для буфера = 30 байт
и файла ~10 кБ. Работает верно.

А по поводу функции - эти циклы меня нисколько не напрягают, да и не важно это.

P.S. С поставленной задачей пока не справился - скрипт говорит, что письмо отправленно, т.е. smtp сервер вернул "успешно", но письма так и нет. Файл всего 20 Мб, а Маил.Ру говорит, что готов принять 30. Загадка...

кратность буфера у Вас задает не мифическая тройка, а [умалчиваемый] параметр функции chunk_split() (и конечно сам алгоритм base64, который 3 байта кодирует четырьмя символами. )
Фактически, буфер у Вас должен быть размером, кратным 58368, ну иль на худой конец - 29184.
А если не сильно жалко - 233472.
Проверяйте.

Кроме того эти дикие циклы с условиями на каждой реплике диалога, которые безусловно вполне оправданы сами по себе, всё же достойны оказаться вынесенными в отдельную функцию.
Неужели не тянет?!

Quoted-Printable

Но кодировать им двоичные данные не выйдет в принципе, а большие объемы текстов с применением национальных алфавитов хоть и получится, но будет весьма неэффективным решением.