xulrunner.exe -register-global

Очень просто, но при уже установленном Firefox обидно ставить отдельную копию XULRunner. Так вот, оказывается можно скопировать в папку с Firefox только файл xulrunner.exe и выполнить вышеуказанную команду. Мелочь, а приятно.

Кстати, если не хочется искать xulrunner, то можно просто добавить в реестр следующую информацию (следите за путями и номерами версий!):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org]

[HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\GRE]

[HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\GRE\1.9.2.8]
"Version"="1.9.2.8"
"GreHome"="C:\\Program Files\\Mozilla Firefox"
"xulrunner"="true"
"abi"="x86-msvc"
"javaxpcom"="1"
[HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\Mozilla]
"CurrentVersion"="1.9.2.8"

В PHP я почти ноль, всё делал методом тыка, если ошибся — поправьте, пожалуйста.

• Яндекс и mail.ru иногда отдают текст русского запроса в кодировке windows-1251, а не utf-8. Нашел на форуме способ определения кодировки, который работает лучше, чем mb_detect_encoding. Добавил в класс wp_shortstat функцию преобразования кодировки запроса: query2utf8. Вызываю её только для Яндекса и mail.ru, хотя по идее надо бы для всех поисковиков. Но кодировка запросов Google почему-то не всегда определяется правильно.
• Перенес в функцию sniffKeyword преобразование запроса в нижний регистр.
• Перенс в функцию sniffKeyword перекодировку запроса в utf-8.

Теперь sniffKeyword возвращает полностью готовый к употреблению поисковый запрос — преобразованный к нижнему регистру, в utf-8. Русские буквы и отображаются, и сохраняются в базе правильно.
Осталась непонятная проблема с кириллической буквой 'е' — иногда вместо неё почему-то отображается '� �'.

Код для интересующихся. Основан на WP-Shortstat-1.15.

[HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2]
"cygdrive prefix"="/cygdrive"
"cygdrive flags"=dword:00000022

[HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/]
"native"="D:\\TOOLS\\cygwin"
"flags"=dword:00000002

[HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin]
"native"="D:\\TOOLS\\cygwin/bin"
"flags"=dword:00000002
[HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib]
"native"="D:\\TOOLS\\cygwin/lib"
"flags"=dword:00000002

static char* stralloc( const char* str ) {
    char* res = malloc( strlen( str + 1 ) );
    strcpy( res, str );
    return res;
}

Код выглядит как настоящий, замыленным взглядом ошибку увидеть сложно. А уж какие эффекты появляются! Эта функция вызывалась из двух мест:

static char* start() {
    return stralloc( "{'start':true}" );
}
 
static char* stop() {
    return stralloc( "{'stop':true}" );
}

Если вызывать только из первого места сколько угодно раз — всё работает. Если вызвать из второго места — падает при втором вызове. Если увеличить длину второй строки на один символ — опять же всё работает.

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

Выяснислось, что это он так обижается на то, что в ответе на запрос не указан

Content-type: application/json

Пришло время привести в порядок базовые знания.

В языке Java для строк используется тип java.lang.String. Символы в строке имеют тип Character — это 16-битные коды символов в кодировке Unicode.

Кодировка файлов может обеспечивать представление всех Unicode символов (UTF-8, UTF-16) или его подмножества (windows-1251). UTF-8 обеспечивает более компактное хранение наиболее распространенных символов (ASCII), но требует более сложного преобразования, поэтому существуют различные представления Unicode.

Что происходит, когда файл читается с помощью java.io.FileInputStream? Поток байтов преобразуется в последовательность Unicode символов. Стоп. Чтобы правильно преобразовать, надо знать кодировку файла. Но ни один из конструкторов FileInputStream не позволяет указать кодировку! Небольшое исследование выводит на инфрмацию о том, что используется умолчальная (дефолтная, стандартная) кодировка платформы. Что будет, если на самом деле в файле использована другая кодировка? Правильно, мусор. Как это победить? Есть такое свойство file.encoding, которое позволяет поменять стандартную кодировку, но оно не документировано (помните книжки типа «Недокументированные возможности MS Word 6.0?»).

Ладно, прочитали из файла строку в неправильной кодировке. В строке мусор. А мы этого не заметили и записали эту строку в другой файл. Конечно, через java.io.FileOutputStream. Тоже не имея возможности указать кодировку. В этом случае — к счастью. Потому что обратная функция почти все символы из мусора вернет в нормальное состояние. Кроме, если я не ошибаюсь, «И» и «ш». А мы будем долго удивляться, откуда такая выборочная беда, ну ведь почти всё же правильно работает!

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

import java.io.UnsupportedEncodingException;
public class StreamEncoding
{
    public static void main( String[] args ) throws UnsupportedEncodingException
    {
        String s = "Иллюзия";
        System.out.println( new String(  new String( s.getBytes( "UTF-8" ), "windows-1251" )
                                        .getBytes( "windows-1251" )
                                      , "UTF-8"
                                      )
                          );
    }
}

Результат вывода:
�?ллюзия

Редкий случай — удалось понять суть проблемы. Обычно удаётся устранить проявления, но не докопаться до сути. Как же делать правильно?

1. В своих программах для файловых операций использовать java.io.InputStreamReader/Writer и их конструкторы с указанием кодировки. Не использовать более простые File(Reader/Writer), потому что они не позволяют указать кодировку. И уж тем более не использовать File(Input/Output)Stream.
2. Чужие программы иногда удается победить указанием свойства file.encoding в командной строке Java-машины. Очевидно, не всегда.

А почему под Linux всё работало? Потому что файл был в кодировке UTF-8, а это стандартная кодировка платформы в Linux. Только не надо нос задирать, в следующий раз попадется windows-1251 и всё будет наоборот.

Начнем с названия. Люди из этой компании вообще думают, как это искать? Игрался я с языком, который называется Nice. Как вы считаете, сколько результатов Гугл выдаст по запросу Nice Programming Language? 2.5 миллиона! И это для малоизвестного языка. А для только что объявленного Simple Programming Language уже почти 19 миллионов!

Естественно, проект расположился на Google Code. Интересно стало посмотреть в исходники, тема трансляторов мне близка (TreeDL хоть и дает всего 1.5 тыщи ссылок, зато релевантность существенно выше). Транслятор Simple написан на Java 6. Парсер рукописный, дерево гетерогенное, рукописное. Классы для узлов дерева содержат методы для генерации байт-кода JVM (У Microsoft на .NET был Basic, теперь и на JVM есть ). Решение достаточно эффективное, но плохо расширяемое.

Прежде чем на Windows удалось скомпилировать пустую программу, пришлось исправить три критические ошибки. Забавно, первые четыре баг-репорта — мои. Для версии 0.1.0 это, конечно, простительно, но осадочек остался. Нехорошо это — выкладывать сборку для платформы и ни разу ее не запустить... Впрочем, у проекта, похоже, один участник — Herbert Czymontek, он же simplecompiler.

Но самое главное — пока, судя по всему, есть только язык и транслятор с библиотекой. Средств визуального проектирования GUI нет. А пока их не будет, Simple своё название не оправдает. Впрочем, даже если они будут, не понимаю, чем BASIC проще нормальных языков. Ладно, поживем — увидим, деньги могут многое.