Мусор в тексте

При написании модулей часто (постоянно) использую UTF-8 формат.
Различные редакторы, возможно и сам RadPHP (и DelphiPHP), дописывает в голову файла
код п»ї или EF BB FF
Поэтому при выполнении PHP кода все эти "префиксы", из всех используемых файлов
вставляются в самую верхнюю часть страницы, образуя при этом пустую строку, смещая
всю страницу на добрых ~12px.

Подскажите, как можно избавиться от побочных эффектов?
Может сам редактор в RadPHP все исправляет?

п»їп»їп»їп»їп»їп»їп»їп»їп»їп»ї<script language="JavaScript" type="text/javascript">

Сообщение отредактировано: nstur - 29.01.11, 18:27

Это проблема самой студии. По неизвестной причине разработчики RadPHP решили что должен использоваться UTF с БОМом, хотя это известный факт что для вебсайтов нужен UTF без БОМ (бом это та сигнатура в начале файла.)
Единственный способ который я знаю это взять Notepad++ (или ему подобный) и перекодировать в UTF без БОМ.

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

Если бы они чуть больше открыли ToolApi то можно было бы написать плагина который кодировал бы правильно.
пс. хотя можно попробовать хакерским методом это решить.

Цитата ViktorXP @ 29.01.11, 18:39

По неизвестной причине разработчики RadPHP решили что должен использоваться UTF с БОМом, хотя это известный факт что для вебсайтов нужен UTF без БОМ

причина известна
а известный факт неизвестен (вернее - кому и откуда он известен ?)

из Википедии
http://ru.wikipedia.org/wiki/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4

Цитата

Юнико́д[1] или Унико́д[2] (англ. Unicode) — стандарт кодирования символов, позволяющий представить знаки практически всех письменных языков.[3].....
Юникод имеет несколько форм представления (англ. Unicode transformation format, UTF): UTF-8, UTF-16 (UTF-16BE, UTF-16LE) и UTF-32 (UTF-32BE, UTF-32LE)....
UTF-8 — представление Юникода, обеспечивающее наилучшую совместимость со старыми системами, использовавшими 8-битные символы...

Порядок байтов
В потоке данных UTF-16 старший байт может записываться либо перед младшим (англ. UTF-16 big-endian), либо после младшего (англ. UTF-16 little-endian). Аналогично существует два варианта четырёхбайтной кодировки — UTF-32BE и UTF-32LE.

Для определения формата представления Юникода в текстовом файле используется приём, по которому в начале текста записывается символ U+FEFF (неразрывный пробел с нулевой шириной), также именуемый меткой порядка байтов (англ. byte order mark, BOM). Этот способ позволяет различать UTF-16LE и UTF-16BE, поскольку символа U+FFFE не существует. Также он иногда применяется для обозначения формата UTF-8, хотя к этому формату и неприменимо понятие порядка байтов. Файлы, следующие этому соглашению, начинаются с таких последовательностей байтов:

UTF-8
EF BB BF
UTF-16BE
FE FF
UTF-16LE
FF FE
UTF-32BE
00 00 FE FF
UTF-32LE
FF FE 00 00
Файлы в кодировках UTF-16 и UTF-32, не содержащие BOM, должны иметь порядок байтов big-endian (unicode.org).

К сожалению, этот способ не позволяет надёжно различать UTF-16LE и UTF-32LE, поскольку символ U+0000 допускается Юникодом (хотя реальные тексты редко начинаются с него).

...............
В операционных системах семейства Windows NT для внутреннего представления имён файлов и других системных строк используется двухбайтовая кодировка UTF-16LE.....
UNIX-подобные операционные системы, в том числе GNU/Linux, BSD, Mac OS X, используют для представления Юникода кодировку UTF-8.....
Проблемы Юникода
Хотя поддержка Юникода реализована в наиболее распространённых операционных системах, до сих пор не всё прикладное программное обеспечение поддерживает корректную работу с ним. В частности, не всегда обрабатываются метки BOM, и плохо поддерживаются диакритические символы. Проблема является временной и есть следствие сравнительной новизны стандартов Юникода (в сравнении с однобайтовыми национальными кодировками).

Мой опыт:
Если использовать только DelphiForPhp как редактор и среду разработки, то проблема не проявляется никогда

В дополнение
отсюда
http://ru.wikipedia.org/wiki/UTF-8

Цитата

Порядок байтов (BOM, сигнатура)
Многие программы Windows (включая Блокнот) добавляют байты 0xEF, 0xBB, 0xBF в начале любого документа, сохраняемого как UTF-8. Это метка порядка байтов Юникода (англ. Byte Order Mark, BOM), также её часто называют сигнатурой (соответственно, UTF-8 и UTF-8 with Signature). По наличию сигнатуры программы могут автоматически определить, является ли файл закодированным в UTF-8, однако файлы с такой сигнатурой могут некорректно обрабатываться старыми программами, в частности xml-анализаторами. Такие редакторы, как Notepad++, Notepad2 и Kate позволяют явно указывать, следует ли добавлять сигнатуру при сохранении UTF-файлов.

Цитата vicis @ 31.01.11, 16:41

а известный факт неизвестен (вернее - кому и откуда он известен ?)

Всем веб разработчикам в частности дизайнерам. Спроси любого веб дизайнера что лучше выбрать utf c бом или без бом.
Проявляется это потому что все браузеры выводят эту сигнатуру как пробел из за чего и лезет весь дизайн. Если кодить в RadPHP и не использовать дизайн (просто формы кнопки и тд. типа в делфи) то глюк не будет проявляться (но это не говорит о его отсутствии), но стоит натянуть шаблон и все полезет. а сервис по генерации XML вообще не будет работать ибо бом ему по среди горла встанет.

Цитата

Многие программы Windows....

В том то и прикол. веб почти весь пропитан юниксовым стандартом. И вот такие виндовские замашки ни к чему хорошему не приводят.

Добавлено 31.01.11, 17:34
круто. в версии 3.0.0.1319 уже сделали нормально. сохраняет в Utf-8 без БОМ.

Цитата ViktorXP @ 31.01.11, 17:19

Всем веб разработчикам в частности дизайнерам. Спроси любого веб дизайнера что лучше выбрать utf c бом или без бом

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

Цитата

И вот такие виндовские замашки ни к чему хорошему не приводят.

при чём тут виндовскте замашки
всё описано в спецификации и виндовс тут не при чём
http://unicode.org/faq/utf_bom.html#gen6

стандарт использования бом-а вылазит боком. посмотри на результат генерации данных в первом посте. до вывода тела джава-скрипта выполнилось десять php скриптов с бом-ом. Если это не не аргумет что бом зло то показываю до чего он может привести.
создаем два php-скрипта:
1) index.php

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 
<html>
  <head>
    <title></title>
    <style type="text/css">
    .css1 {
      border: solid 1px #000;
      height: 100px;
      width: 100px;
    }
    .css2 {
      border: solid 1px #0f0;
      height: 100%;
      width: 100%;
      display: inline-table;
    }
 </style>
  </head>
  <body>
    <div class="css1"><?php include('test.php') ?></div>
  </body>
</html>

2) test.php

<div class="css2">Test</div>

Для чистоты експеремента нужно убедится что ни каких символов нет ни до открытия тега не после его закрытия.
первоначально второму файлу ставим кодировку utf-8 без бом. (у первого файла кодировка значения не имеет)
запускаем и видим что отработано четко. квадрат в квадрате. без лишних аномалий (хотя в FF внутренний квадрат выступает на два пикселя немного в низ и в право но это уже нюансы стилизации которые нас не интересуют).
а теперь второму скрипту меняем кодировку на utf-8 c бом-ом. и что же мы наблюдаем? тут уже ни какая подгонка стилизации не поможет. максимально что можно выжать из любого браузера это уменьшить это расстояние в один пиксель (меньше не получится, так как там идет текст и браузеру нужно его куда то вывести. ибо для браузера бом является текстом (кодировка ему передается в хейдере). а в данном примере бом вылез не в начале файла а вообще в середине тела странички)
для наглядности скрин:
Прикреплённый файл__________.jpg (86,05 Кбайт, скачиваний: 777)
вывод: Бом это зло


Добавлено 31.01.11, 23:13

Цитата ViktorXP @ 31.01.11, 22:50

максимально что можно выжать из любого браузера это уменьшить это расстояние в один пиксель

впринципе если внутренний див сделать position: absolute; то его разместить можно будет как угодно и где угодно. Но это не будет айс. это ж какие масштабы работы дизайнеру нужно будет проделать что бы правильно позиционировать такие дивы. а еще если интерфейс резиновый то и джаву применять... проще взять правильное решении и убрать бом

Добавлено 31.01.11, 23:40

Цитата vicis @ 31.01.11, 18:32

а кривые плоскогубцы в топку

Вот как раз бом и является этими плоскогубцами.

Цитата vicis @ 31.01.11, 18:32

при чём тут виндовскте замашки
всё описано в спецификации и виндовс тут не при чём
http://unicode.org/faq/utf_bom.html#gen6

Ты сам внимательно читал эту спецификацию?
http://unicode.org/faq/utf_bom.html#BOM
обрати внимания на нюансы с utf-8

Цитата ViktorXP @ 31.01.11, 22:50

Ты сам внимательно читал эту спецификацию?
http://unicode.org/faq/utf_bom.html#BOM
обрати внимания на нюансы с utf-8

что я не так понял там ?

да, есть ньюансы и браузеры их должны учитывать
вопрос в том: учитывают или нет....
если не учитывают, то использовать BOM не стоит
а если учитывают, то может что то с таким дизайном или дизайнером

Все производители браузеров обычно декларируют большее чем у других соответствие стандартам
BOM нужен для определения кодировки UTF-8
Если бы небыло проблемы, то наверное и не писали бы стандарт
Тогда осталось определить - используют ли браузеры BOM и в браузерах ли дело?

Вот что накопал
В XML 1.0 BOM требуется для UTF-16 и разрешается для UTF-8.
В HTML 4.01 BOM рекомендуется для UTF-16 и не регламентируется для UTF-8.

Здесь описано как браузер должен работать со страницам.
В частности

Цитата

1 Summary of key points
The following are the key architectural points of this finding:

1.Metadata received in an encapsulating container, such as the metadata within the header fields of a message that describe the data enclosed within that message, is authoritative in defining the nature of the data received.

2.Inconsistency between representation data and metadata is an error that should be discovered and corrected rather than silently ignored.
.....

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

Есть предположение что браузер, чтобы определить, в какой кодировке показывать страницу, делает так:
- сперва смотрит на ее HTTP хидер (Content-Type: text/html; charset=...)
- если нет HTTP хидера, смотрит на HTML хидер (<meta http-equiv="Content-Type" content="text/html; charset=..."/>)
- если нет HTML хидера, браузер пытается угадать кодировку через анализ контента. Вот тут BOM может (и должен) сыграть свою роль.

Смотрим как делают реальные браузеры и языки:
1. Mozilla (Firefox)

Цитата

Charset AutoDetection (InputText)
{
if (all characters in InputText are ASCII)
{
if InputText contains ESC or “~{“
{
call ISO-2022 and HZ detector with InputText;
if one of them succeed, return that charset, otherwise return ASCII;
}
else
return ASCII;
}
else if (InputText start with BOM)
{
return UCS2;
}
else
{
Call all multi-byte detectors and single-byte detectors;
Return the one with best confidence;
}
}

т.е. BOM использует

2. Python

Цитата

Если текст начинается с BOM, можно разумно предположить, что текст кодируется в UTF-8, UTF-16 или UTF-32. (Спецификации расскажет нам точно в какой). Эта обработка встроена в UniversalDetector, которая возвращает результат сразу, без какой-либо дальнейшей переработки.

т.е. BOM использует

3. HTML / XML-анализатор для Python
порядке очередности, превратить ваш документ в Unicode:

Цитата

•Кодировка вы передаете в качестве fromEncoding аргумент суп конструктора.
•Кодировка обнаружена в самом документе: например, в декларации XML или (для HTML-документов) http-equiv мета-тег.
•Кодировка понюхал , глядя на первые несколько байт файла. Если кодирования обнаружен на данном этапе, это будет один из UTF-* кодировок, EBCDIC или ASCII.
.....

т.е. BOM использует

4. Документированный баг в php

Цитата

[2003-02-07 07:46 UTC]
Проблема:
Когда PHP файл сохраняется в кодировке UTF-8 формате UTF-8 спецификации, как первые три байта файла (EF BB BF), PHP не игнорирует эти байты при загрузке и компиляции файла, но вместо этого их выводит их до <? PHP. Это приводит к неправильному отображению части страницы и отказа какого-либо вывода заголовков HTTP.

Он делает это даже тогда, когда внутренний формат символ установлен в php.ini быть UTF-8.

Ожидаемый результат:
PHP признает, UTF-8 спецификации и игнорирует его.
......
[2004-05-25 10:33 UTC]
Добавление "- включить-Zend-многобайтовых к последнему PHP5 ....
[2005-01-12 17:36 UTC]
> Как насчет этого - позволить-Zend-многобайтовых по умолчанию?

В самом деле, я использую его на рабочем сервере с июня 2003 года, без проблем и со многими удовлетворения.

[2005-08-22 16:32 UTC]
PHP 5.0.4 для Windows / еще / не похоже, чтобы он (Enable-Zend-многобайтовых) включен по умолчанию. Например session_start () разбивается на UTF-8 закодированных файлов PHP. Я бы настоятельно рекомендуем, чтобы позволить-Zend-многобайтовых умолчанию для релиза Windows!
[2005-08-22 16:35 UTC]
Это произойдет с Unicode поддержки в PHP 6,0

как я понимаю баг исправлен, но нужно включить многоязыковую поддержку

5. Исправления бага в Опере
-Ignoring of the the header UserJS with the BOM


думаю, что дальше нет смысла копать в этом направлении
Есть спецификация и есть реализация.
Так что можно BOM и убрать из файла, но время на определение кодировке уходит больше, возможны коллизии и т.п.

Цитата vicis @ 01.02.11, 19:12

да, есть ньюансы и браузеры их должны учитывать
вопрос в том: учитывают или нет....
если не учитывают, то использовать BOM не стоит

Как? ты видимо не пробовал мой пример который я привел.
не забывай что бом указывается в самом начале файла. и как по твоему браузер должен распознать вот это
Прикреплённый файл__________.png (13,92 Кбайт, скачиваний: 759)

это скорее проблема php ибо он выдает все что есть при этом тупо считая бом как равноправные символы.

Добавлено 01.02.11, 21:00
и ты не заметил что бом должен быть один. а на сайте каждый загружены скрипт дарит страничке свой бом.

Продолжим.
Определим всё же круг виновных в кривом дизайне и что делать, что бы не наступать на грабли.
Главное не плеваться на невиновных голословно

Предлагаю простую логику рассуждений
1. Начинать каждый задействованный в проекте файл с BOM или нет, при использовании UTF-8, должен решить разработчик исходя из стандартов и особенностей разработки.
2. Стандарты рекомендуют наличие BOM у файла приходящего с сервера(там где рекомендуют) к браузеру (или другому софту), но он должен быть один и в начале.
3. Если используеш include или другие подобные операторы, то должен понимать что делаеш.
А делаеш в этом случае всегда один файл из нескольких, например: выходной файл = файл1+файл2+файл3.
И если у тебя во вложенных файлах (файл2,файл3) есть BOM то должен понимать, что он будет добавлен в середину, а полученный в результате файл будет не соответствовать стандарту. Соответственно браузер его неправильно отработает.
Вывод - читай мурзилку и не ставь BOM во вложенных файлах (снимай упаковку с кирпичей ).
По идее, пхпшные функции должна бы отслеживать это, но судя по отзывам разработчиков полноценная поддержка обещана в 6-й версии.
Т.е. исходим из того что поддержки обрезания BOM у файлов, которые инклудятся в рассматриваемых функциях php нет.

Таким образом:
1. за кривой дизайн отвечает разработчик, т.к. не понимает или не читал стандарта, или не понимает что делает.
2. разработчики RadPHP (DelphiForPhp) не причём при любом раскладе с едущим дизайном, т.к. в данных случаях используются пхпшные функции, а они их не разрабатывали. С другой стороны то, что в последней версии BOM там не вставляется
и хорошо и плохо. С одной стороны всё же BOM рекомендуется, а с другой народу которой наступает на эти грабли видно много, вот и облегчили жизнь.
Логичнее было бы вставить где то опцию, но может я её просто не нашёл.
3. Разработчики PHP похоже тоже не причём, т.к. да, есть особености, но никто ничего в этой версии не обещал. Берите что есть ведь и так на шару... (доработать функцию на вырезание BOM при include можно в несколько строк )
4. Браузеры же, BOM в начале файла используют по назначению, о чём говорят приведённые выше ссылки, хотя по всем браузерам я не нашёл информации. Возможно с этим у каких то браузеров есть грабли, но тогда их нужно увидеть на каком то примере и тоже учесть.

Ещё несколько соображений на эту тему.
Если глянуть на функцию AutoDetection для Mozilla (Firefox) из поста выше, то более тупого алгоритма придумать сложно - анализировать сначала что все символы в ASCII... Это же ресурсоёмкая задача. И если её не выполнять, то браузер будет работать быстрее. А почему так, да потому что есть весёлые ребята разработчики, которым стандарты по барабану. Ну раньше таких требований небыло, но сейчас то есть. Скорее всего отсюда этот BOM и появился. И пока программисты будут отказываться от его использования проблема будет существовать.
Думаю, что у каждого был такой опыт неоднократно, когда нужно бы просто переделать функцию и уйти от каких то тормозных решений прошлого, но нет возмжности, т.к. на это уже много завязано. Но в конце концов приходит время и уже рубиш по живому.
Достаточно в упомянутой функции поменять местами проверки и вывести на первое место проверку BOM и некоторые сайты(страницы) будут грузится быстрее остальных.

Что могу добавить: Для веб страниц (для html, js) я бы не рекомендовал бом пока в php не внесут исправления по этому нюансу. Страничка будет корректно работать в любом случае. Так как в заголовке ответа от сервера возвращается кодировк, чего вполне достаточно для работы браузера.

nstur что то молчит. это видимо от переизбытка информации