Новость к разбору на составные детальки любимого сайта (или не- любимого :))
http://www2.imagiware.com/RxHTML/ - Сайт онлайновой проверки любого html кода (странички или даже целого сервера) на правильность. Выдается полнейшая статистика. Особенно мне понравилась статистика по IMG. Сколько времени грузится, сколько все картинки весят и т.п.
Также выдаются рекомендации. Но только по найденным ошибкам относительно стандарта HTML.
Все делается в онлайне. Сразу же. Автоматом. Поэтому, ошибки стиля не учитываются - робот-с...
 

      ...Итак, сервер передает вашему браузеру пакеты с информацией. Т.е. с затребоваными ресурсами. По 80-му порту. Это уже обсуждалось в 44 номере. И все бы хорошо, если бы не одно "но". Кодировки. Это настоящий бич для локальных версий программного обеспечения. Т.е. различное представление символов национального языка. С латинскими буквами все просто. Они всегда находятся на одном и том же месте в таблице символов. Кириллица же, например, представлена несколькими видами расположения в таблице. Эти способы расположения и имеют знакомые названия KOI, WIN, DOS (alt), MAC и т.п. Например, в кодировке DOS (alt) код русской буквы "А" - 128, а в кодировке WIN ее код уже будет 192. Историю и "этнос" типов кодировок я здесь рассматривать не буду. Тем более, что в одном из прошедших номеров я давал хорошую ссылку на сайт, где все-все про них написано.

      Ну а интернет-то здесь при чем? Ведь по идее можно договориться использовать файлы только в KOI или скажем в WIN кодировке. А дело в том, что различные операционные системы используют свои кодировочные таблицы. Например, для юникса это KOI, и естественно, что системный администратор старается все текстовые файлы на сервере привести к единому "знаменателю", т.е. только в KOI. Сисадмин NT web-сервера естественно клонит к WIN кодировке.

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

      Допустим, ваш браузер желает видеть windows (1251) кодировку, а на сервере она лежит в KOI. Перекодировкой может заниматься сам сервер. Поэтому на многих сайтах можно видеть кнопочки [win] [koi] [iso] и т.д. Хотя сейчас это уже и не модно, я расскажу все таки как происходит перекодировка на сервере. Когда вы тыкаете допустим на [lat], вы даете команду серверу направлять текстовый поток уже не через 80 порт, а через 8105 порт. например, www.irk.ru:8105/dir1/dir2/... таким образом файл будет обработан следующим образом: встречающиеся русские буквы программа перекодировки на сервере заменит на латинские. И выдаст вам через порт 8105. А вот если с этого же порта вы затребуете не текстовый файл, а скажем, zip или rar, то сервер этот момент просечет (в зависимости от настроек) и его перекодировать не будет, а направит вам по обычному 80-му порту, дабы не попортить его перекодировкой.

      Но сейчас все немного попроще: апач на "той" стороне от юзера знает, какую кодировку в данный момент хочет видеть браузер у пользователя. И сам подбирает таблицу перекодировки.

      На сегодня, если META tag стоит правильно (то есть та кодировка в которой и написан текст), то все браузеры его будут правильно показывать, по крайней мере, последние версии. То же самое и с почтой - если Content-Transfer-Encoding в заголовке письма соответствует содержимому, то  во всех программах будет показываться все правильно. Естетственно, когда такого заголовка или тега нет, либо они не соответствуют содержимому, то получиться может все что угодно.

      Кстати, почему-то я так и не нашел ни у кого ответа на вопрос, "а почему бы всем провайдерам не договориться выкладывать файлы только в какой-то одной кодировке?". Сейчас сильный разнобой. Кто в KOI, кто в WIN. Иногда встречаются такие перлы: текст лежит в WIN, сервер думает что там KOI и перекодирует его в WIN. Получается как бы WIN->WIN. Это вызывает просто несварение у многих программ. Особенно такая беда встречается у многих почтовых серверов. Применение, например, в NN view->encoding->... результата не даст. Потому как encoding сделан, собственно, как viewer - он просто пытается посмотреть на код с "разных сторон" кодировочных таблиц. Лечится обратной перекодировкой в KOI. Такие казусы вполне могут быть результатом неправильной настройки сервера.

      Теперь - FTP. File Transfer Protocol был рожден чуть ли не вместе с юниксом. Общение с юзером в действительности происходит через два порта (понимайте слово "порт" просто как виртуальное устройство). 21 порт - команды для FTP сервера, 20 порт - данные. Такое разделение, по видимому было придумано для того, чтобы множить потоки 20-го порта, а для управления использовать только один 21-й. Это даст возможность во время передачи например дать команду cd (change directory) и/или команду на передачу другого файла. Да еще такое разделение дает возможность множить потоки данных на 20 порт, не создавая множества ftp-сессий с сервером. В случае ограничения соединений - это было бы удачным решением. Почему "было бы" ? Потому как, что-то я не знаю ни одной программы, которая бы так делала. Приходится открывать еще одну сессию. А можно было бы просто раздробить потоки данных по 20-му порту. Почему никто так и не написал такого софта, непонятно...

      Само по себе разделение вообще-то достаточно интересная штука, хотя можно обойтись и без него. Но, повторяю, ftp сервис был придуман давно, и работа через два порта видимо что-то подразумевала еще, но... Давно это было :))

      Кстати говоря, у ftp сервера достаточно интересный набор команд, о которых мы и не подозреваем подчас. За нас их выполняет ftp программа (Cute, FAR или даже Windows-commander, да много каких). Особенно в CuteFTP можно видеть какие именно команды он подает. Например, чтобы показать вам директорию на удаленном сервере выполняется две команды: cd dir - сменить директорию, pwd - напечатать директорию, выдавая поток с информацией вам.

Да, енкодер-граббер маленький и удобный. Ничего не скажешь. Называется CDex. Домашняя страничка.
Поддержка cddb есть - сразу же и названия файлам дает. Есть возможность кодирования звука кроме своего внутреннего кодера, другими. Вплоть до VQF. Сам пакует только в mp2. Может и в MP3, только в стандартном пакете не идет DLL-ки, которая может это делать. Хотя, можно переименовать mp2enc.dll в mp3enc.dll - появится фича Layer 3. Как это будет работать - я не проверял.
Размер получается у mp2 тот же при том же битрэйте - 128kbps.
Проверяем, чем же он там кодирует.

Красная линия на рисунке - оригинальный WAV файл. Зеленая - зажато plugger v4.0. Белая - зажато CDex.
Ну?! Кто там у нас режет ниже 14-15кГц? Кажется только Ulead. Даже Xing и тот до 16кГц! (Music Match JuckeBox). Причем, я когда наблюдал за графиком - CDex-овский вначале вообще, только до 12кГц скакал, (при том, что остальные сразу нормально по всему спектру "подпрыгнули" - специально проверил) и только потом он уже дополз до 15кГц. Т.е. ниже 50-60 децибел у него совсем плохо с частотами выше 12кГц.
Значит, если пользоваться CDex, то имеет смысл упаковывать только каким-нибудь внешним кодером.
Так что, практическая польза только в поддержке cddb и сграбливании треков с нормальными именами.

Насчет NotifyCD player - как пишут, он похоже, единственный, кто понимает CD-changer в полном объеме.

Обещают вроде деформируемо-разрушаемую игроком поверхность и здания. Это интересно. А то ведь зарядишь бывало по хибаре ракет 5-6 - а ей хоть бы хны! :)) Дальше дырок в стенах создатели 3D игр так и не ушли пока.
А тут еще и следы на поверхности обещают от железных пят таких вот кузнечиков :) Хотя нечто подобное было в Duke  - там следы тоже оставались.
Ну, и, много всяких других вкусностей обещают..