 |
 |
 |
||
 |
||||
Ваши предложенияДобавлено: Четверг, 21 Июня, 2007 16:18 Размещено в: Ваши предложенияВаши пожелания и комментарии о работе нашего проекта вы можете оставлять в комментариях к этому сообщению. |
||||
 |
|
 |
||
|
||||
|
|
|
||
|
||||
|
||||
|
|
|
||
|
||||
Release 1.1
25 Июня, 2007 в 11:25
Hello michel,
Обращаю Ваше внимание,
что в файле cidr_ru_slave_index.db есть ошибка:
в последней строке начальный айпи равен конечному!
надо бы исправить!
3653762816 3653762816 217.199.255.0 - 217.199.255.0 RU Екатеринбург Свердловская область Уральский ASSIGNED PA
Та же ошибочная строка присутствует и в файле cidr_ru_block.txt.
Кроме того, почему-то в файлах присутствуют НЕ ВСЕ блоки адресов!
Например нет блока
inetnum: 62.231.160.0 - 62.231.191.255
org: ORG-RDTC1-RIPE
netname: RU-RDTC-20030523
descr: PROVIDER Local Registry
descr: Regional Digital Telecommunication Company
country: RU
Еще я заметил некоторые неточности.
Например, нижеуказанный блок расположен в Обнинске,
а у вас в базе написано, что это Калуга:
inetnum: 62.148.139.0 - 62.148.139.255
netname: OBNINSK-MAN139
descr: Obninsk Town
descr: Metropolitan Area Network, Ethernet
descr: Engels str., 2, 10, 16, 18, 20, 24, 34
descr: Kurchatov str., 41, 54, 56, 58, 60
descr: Kaluzhskaya str., 2, 4, 12
country: RU
Очень хотелось бы, чтобы ваша база была актуальной!
И еще есть пожелание:
Сейчас пользоваться этой базой неудобно,
поскольку она неполная…
Было бы очень здОрово, если бы в нее были дополнительно включены
поля netname и descr из базы РИПН/Ру-Центр.
25 Июня, 2007 в 11:26
Нашел ошибочку в форме для ответа:
Написано:
E-mail (не публекуется) (обязательно)
Надо написать:
E-mail (не публИкуется) (обязательно)
25 Июня, 2007 в 16:45
>Нашел ошибочку в форме для ответа:
>Написано:
>E-mail (не публекуется) (обязательно)
>Надо написать:
>E-mail (не публИкуется) (обязательно)
Спасибо за замечание, опечатка исправлена.
25 Июня, 2007 в 16:50
>Hello michel,
>Обращаю Ваше внимание,
>что в файле cidr_ru_slave_index.db есть ошибка: в
>последней строке начальный айпи равен конечному!
>надо бы исправить!
>3653762816 3653762816 217.199.255.0 - 217.199.255.0
>RU Екатеринбург Свердловская область Уральский ASSIGNED PA
>Та же ошибочная строка присутствует и в файле cidr_ru_block.txt.
Это не ошибка, такой блок есть в RIPE. Это можно проверить по whois.
>Кроме того, почему-то в файлах присутствуют НЕ ВСЕ блоки адресов!
>Например нет блока
>inetnum: 62.231.160.0 - 62.231.191.255
>org: ORG-RDTC1-RIPE
>netname: RU-RDTC-20030523
>descr: PROVIDER Local Registry
>descr: Regional Digital Telecommunication Company
>country: RU
Блок добавлен. Завтра информация обновиться.
>Еще я заметил некоторые неточности.
>Например, нижеуказанный блок расположен в >Обнинске, а у вас в базе написано, что это Калуга:
>inetnum: 62.148.139.0 - 62.148.139.255
>netname: OBNINSK-MAN139
>descr: Obninsk Town
>descr: Metropolitan Area Network, Ethernet
>descr: Engels str., 2, 10, 16, 18, 20, 24, 34
>descr: Kurchatov str., 41, 54, 56, 58, 60
>descr: Kaluzhskaya str., 2, 4, 12
>country: RU
>Очень хотелось бы, чтобы ваша база была актуальной!
Исправлено.
>И еще есть пожелание:
>Сейчас пользоваться этой базой неудобно, поскольку она неполная…
>Было бы очень здОрово, если бы в нее были дополнительно включены
>поля netname и descr из базы РИПН/Ру-Центр.
Мы подумаем над Вашим предложением. Спасибо за исправления и предложения.
6 Июля, 2007 в 3:39
Сделайте прямо на главной странице чтобы отображался IP адрес зашедшего и сразу результаты поиска по базе а ниже кнопку - Вас определили неправильно? Поправьте нас! С переходом на формочку где можно ввести исправления.
10 Июля, 2007 в 13:57
>Сделайте прямо на главной странице чтобы отображался
> IP адрес зашедшего и сразу результаты поиска по базе а
> ниже кнопку - Вас определили неправильно? Поправьте
> нас! С переходом на формочку где можно ввести
>исправления.
Отличное предложение! Мы подумаем над Вашей идеей.
11 Августа, 2007 в 8:38
нашел опечатку при описании
http://ipgeobase.ru/Help.html
ALLOCATED PA
сделанные в этом пространстве , –>навыдлено
13 Августа, 2007 в 18:19
>нашел опечатку при описании
>http://ipgeobase.ru/Help.html
>ALLOCATED PA
>сделанные в этом пространстве , –>навыдлено
Спасибо за внимание к нашему проекту и ценные замечания. Опечатка исправлена.
29 Сентября, 2007 в 10:25
Добрый день, почему бы вам не объединить записи в базе адресов таким образом: Если населенный пункт один и адреса идут попорядку, например
1040547840|1040547855|Москва|…
1040547856|1040547871|Москва|…
1040547872|1040547887|Москва|…
можно объедининть в 1040547840|1040547887|Москва|…
таким образом можно уменьшить базу с 84510 до 19963 строк. А если понадобиться можно разделить
2 Октября, 2007 в 18:23
>Добрый день, почему бы вам не объединить записи в базе
>адресов таким образом: Если населенный пункт один и
>адреса идут попорядку, например
>1040547840|1040547855|Москва|…
>1040547856|1040547871|Москва|…
>1040547872|1040547887|Москва|…
>можно объедининть в 1040547840|1040547887|Москва|…
>таким образом можно уменьшить базу с 84510 до 19963
>строк. А если понадобиться можно разделить.
Так делать нельзя, так как это различные блоки адресов, которые, возможно, выделены разным организациям.
5 Октября, 2007 в 12:49
Ну, и добавте эти разные организации! :), чтобы лишних вопросов не возникало. В двоичные файлы не обязательно, наверное добавлять, а в текстовый - очень даже в тему, тем более, что об этом просят (Netname и Descr, например!).
6 Октября, 2007 в 15:29
>Ну, и добавте эти разные организации! :), чтобы лишних вопросов не возникало.
>В двоичные файлы не обязательно, наверное добавлять, а в текстовый - очень
>даже в тему, тем более, что об этом просят (Netname и Descr, например!).
Сделано. Теперь последним полем в файле cidr_ru_block.txt добавлено описание блока.
9 Октября, 2007 в 13:53
Прежде всего хочу отметить удобство вашего сайта и простоту организации БД. Это приятно.
Предложения такие:
1. В cidr_ru_block.txt первые два поля стоит сделать не в числовом формате, а в хексах, например: 0×31303430 вместо 1040547840. Перевод из хексов в IP-адреса проще, чем перевод из простых чисел.
2. Не забывайте о Windows-пользователях. Вместо tar.gz лучше использовать простой zip, а в качестве переводов строк cr и lf, вместо одного lf.
9 Октября, 2007 в 16:22
>Прежде всего хочу отметить удобство вашего сайта и простоту организации БД.
>Это приятно.
Спасибо, нам очень приятно
>Предложения такие:
>1. В cidr_ru_block.txt первые два поля стоит сделать не в числовом формате,
>а в хексах, например: 0×31303430 вместо 1040547840. Перевод из хексов в
>IP-адреса проще, чем перевод из простых чисел.
Простые числа нагляднее и легче осуществлять поиск и устанавливать принадлежность IP-адреса блоку.
>2. Не забывайте о Windows-пользователях. Вместо tar.gz лучше
>использовать простой zip, а в качестве переводов строк cr и lf, вместо
>одного lf.
Хорошее предложение! Мы подумаем.
Спасибо за интерес к нашему проекту.
27 Октября, 2007 в 16:31
В данных есть до сих пор Пермская область, а её уже нет как два года…Нужно бы исправить для актуальности.
Пермский Край.
Образован 1 декабря 2005 года в результате объединения Пермской области и Коми-Пермяцкого автономного округа.
Спасибо за работу
15 Ноября, 2007 в 18:17
>В данных есть до сих пор Пермская область, а её уже нет как два года…
>Нужно бы исправить для актуальности.
>Пермский Край.
>Образован 1 декабря 2005 года в результате объединения Пермской области
>и Коми-Пермяцкого автономного округа.
>Спасибо за работу
Исправлено, спасибо за замечание.
17 Ноября, 2007 в 23:41
мне кажется будет хорошо если добавить в “Расширенный поиск” поиск по Провайдерам
21 Ноября, 2007 в 7:48
1. В названии города Йошкар-Ола второе слово в базе написано с маленькой буквы. При работе с Вашей базой сторонними скриптами может возникнуть ошибка при регистрозависимом поиске.
2. Вопросы и ответы. Пункт 9 - ошибка в заголовке, слово “оветственную” (если придираться, то и в самой ссылке лишний пробел перед запятой).
Проект Ваш понравился, спасибо. Сейчас работаю над переводом базы в используемый мной формат, поглядим, как заработает.
21 Ноября, 2007 в 8:13
Еще вместо “Ростов (на Дону)” было бы правильнее, имхо, “Ростов-на-Дону”.
21 Ноября, 2007 в 16:22
>ZeTiX ответил(а):
>мне кажется будет хорошо если добавить в “Расширенный
>поиск” поиск по Провайдерам
Вы имеете в виду интернет провайдеров? Для крупных городов там есть поиск по полю maintainer, во многих случаях это и есть провайдер.
21 Ноября, 2007 в 16:33
>1. В названии города Йошкар-Ола второе слово в базе написано с маленькой
>буквы. При работе с Вашей базой сторонними скриптами может
>возникнуть ошибка при регистрозависимом поиске.
Исправлено.
>2. Вопросы и ответы. Пункт 9 - ошибка в заголовке, слово
>“оветственную” (если придираться, то и в самой ссылке лишний пробел
>перед запятой).
Исправлено.
>Проект Ваш понравился, спасибо. Сейчас работаю над переводом
>базы в используемый мной формат, поглядим, как заработает.
Спасибо)
21 Ноября, 2007 в 16:35
>Еще вместо “Ростов (на Дону)” было бы правильнее, имхо, “Ростов-на-Дону”.
Исправлено.
10 Февраля, 2008 в 17:02
Нашел пару багов в названиях городов:
“Каменск- Шахтинский” - лишний пробел после “-”
“Ханты-мансийск” - второе слово нужно с большой буквы
12 Февраля, 2008 в 11:05
Исправьте ошибку, которая вылетает, когда нажимаешь кнопку “найти” в “расширенном поиске”, не заполняя никаких полей.
12 Февраля, 2008 в 16:12
>Нашел пару багов в названиях городов:
>“Каменск- Шахтинский” - лишний пробел после “-”
>“Ханты-мансийск” - второе слово нужно с большой буквы
Исправлено, завтра информация обновится
12 Февраля, 2008 в 16:23
>Исправьте ошибку, которая вылетает, когда нажимаешь кнопку “найти” в
>“расширенном поиске”, не заполняя никаких полей
Исправлено, спасибо за замечание.
19 Февраля, 2008 в 16:47
Еще было бы хорошо разделить IP и GEO части, как например в базе от MaxMind( ну или добавить номер населенного пункта как один из параметров). Очень не удобно сначало парсить вашу базу в одну табличку, а потом по текстовым(!) ключам выставлять IDшники городов записям и переливать данные в более легковесную “рабочую” таблицу.
22 Февраля, 2008 в 17:49
>Еще было бы хорошо разделить IP и GEO части, как например в базе от
>MaxMind( ну или добавить номер населенного пункта как один из параметров).
>Очень не удобно сначало парсить вашу базу в одну табличку, а потом по
>текстовым(!) ключам выставлять IDшники городов записям и переливать данные
>в более легковесную “рабочую” таблицу.
В MaxMind своя кодировка регионов и городов. Например, по MaxMind код москвы 47. Режет слух
Мы можем выложить файл с кодами регионов РФ по ГОСТУ и с телефонными кодами городов. Если есть такая необходимость - ждем Вашего предложения)
1 Апреля, 2008 в 13:48
Предлагаю все-таки подумать о Windows-пользователях и предоставлять возможность скачать файл cidr_ru_block.txt отдельным zip-архивом!
6 Апреля, 2008 в 17:37
>Предлагаю все-таки подумать о Windows-пользователях и предоставлять
>возможность скачать файл cidr_ru_block.txt отдельным zip-архивом!
Хорошее предложение! Теперь на странице с архивом есть ZIP-файл с нашей базы. Спасибо Вам за интерес к проекту.
15 Апреля, 2008 в 20:35
Предоставили бы готовый скрипт, который бы перенаправлял на условную англоязычную версию сайта,если человек заходит не с россии и не с СНГ
16 Апреля, 2008 в 13:40
>Предоставили бы готовый скрипт, который бы перенаправлял на
>условную англоязычную версию сайта,если человек заходит не с россии
> и не с СНГ
Мы подумаем над Вашим предложением. Спасибо за интерес к проекту.
7 Мая, 2008 в 18:40
На странице http://ipgeobase.ru/Help.html#32 , кажется, опечатка. Там написано:
“За ним следует блок 140.220.100.12 – 140.220.100.192 , содержащий в себе блоки 145.145.23.78 – 145.145.24.0 и 145.145.23.78 – 145.145.23.100 ”
Это неверно. Вероятно, Вы хотели сказать “за ним следует блок 140.220.100.12 – 140.220.100.192, который не содержит других блоков, а далее блок 145.145.23.78 – 145.145.24.0, содержаший в себе 145.145.23.100″
7 Мая, 2008 в 19:25
>На странице http://ipgeobase.ru/Help.html#32 , кажется, опечатка. Там написано:
>“За ним следует блок 140.220.100.12 – 140.220.100.192 ,содержащий в себе
>блоки 145.145.23.78 – 145.145.24.0 и 145.145.23.78 – 145.145.23.100 ”
>Это неверно. Вероятно, Вы хотели сказать “за ним следует блок 140.220.100.12 – 140.220.100.192,
>который не содержит других блоков, а далее блок 145.145.23.78 – 145.145.24.0,
> содержаший в себе 145.145.23.100″
Да, это описка. Спасибо за замечание, ошибка исправлена.
17 Мая, 2008 в 19:43
Сделайте пожалуйста онлайн версию по средствам xml, чтобы можно было сделать к вам запрос и получить ответ. Это позволит избежать устаревших данных на конечных сайтах и решить проблему обновления информации. Также через данную систему автоматизированно можно было бы сообщать вам о ошибка или неточностях.
17 Мая, 2008 в 19:50
Почему бы не экспортировать базу, в понятном для всех виде для MySQL?
18 Мая, 2008 в 16:28
>Почему бы не экспортировать базу, в понятном для всех виде для MySQL?
Немного не понятен Ваш вопрос? Файлы и так идут в формате db. Этот формат загружается в mysql за считанные секунды.
18 Мая, 2008 в 16:29
>Сделайте пожалуйста онлайн версию по средствам xml, чтобы можно было сделать
> к вам запрос и получить ответ. Это позволит избежать устаревших данных на конечных
> сайтах и решить проблему обновления информации. Также через данную систему
> автоматизированно можно было бы сообщать вам о ошибка или неточностях.
Мы уже думали над этим. В самое ближайшее время такой сервис будет доступен.
23 Августа, 2008 в 10:57
Вот мой вариант php-скрипта поиска:
$gf = file(”cidr_ru_block_20080805.txt”);
$ipl = sprintf(”%u”, ip2long($_SERVER['REMOTE_ADDR']));}
$gfl = count($gf);
for($i=$gfl; $i>0; $i–)
{
$data = strtok($gf[$i],” \t”);
$ip1 = $data;
$ip2 = strtok(” \t”);
if($ipl>=$ip1){
if($ipl<=$ip2){
strtok(” \t”);
strtok(” \t”);
strtok(” \t”);
strtok(” \t”);
$gorod = strtok(”\t”);
$oblast = strtok(”\t”);
break;
}
}
}
$gf = array();
unset($gf);
Потестил - все определяет правильно, только памяти много ест.
26 Августа, 2008 в 14:03
На какой e-mail можно написать?
Указанный на сайте (michel@quest.polyn.kiae.su) не работает.
26 Августа, 2008 в 19:26
>
> $gf = file(”cidr_ru_block_20080805.txt”);
> $ipl = sprintf(”%u”, ip2long($_SERVER['REMOTE_ADDR']));}
> $gfl = count($gf);
> for($i=$gfl; $i>0; $i–)
> {
> $data = strtok($gf[$i],” \t”);
> $ip1 = $data;
> $ip2 = strtok(” \t”);
> if($ipl>=$ip1){
> if($ipl< =$ip2){
> strtok(” \t”);
> strtok(” \t”);
> strtok(” \t”);
> strtok(” \t”);
> $gorod = strtok(”\t”);
> $oblast = strtok(”\t”);
> break;
> }
> }
> }
> $gf = array();
> unset($gf);
Потестил - все определяет правильно, только памяти много ест.
Сразу могу сказать, что скрипт неправильный. Он находит первый попавшийся блок. А надо, чтобы находил минимальный, т.к. один адрес может входить в нескольео блоков и только минимальным из них определяется его географическое положение.
26 Августа, 2008 в 19:34
> Указанный на сайте (michel@quest.polyn.kiae.su) не работает.
Он работает, просто приходит куча спама. Возможно ваше письмо попало в спам. Лучше пишите сюда.
28 Августа, 2008 в 5:29
admin, обратите внимание что скрипт ищет диапазон в обратном порядке, вот например есть блоки:
123.123.123.0 - 123.123.123.255
123.123.123.12 – 123.123.123.45
123.123.123.60 – 123.123.123.100
123.123.123.101 – 123.123.123.192
135.213.234.10 – 135.213.234.255
140.220.100.12 – 140.220.100.192
145.145.23.78 – 145.145.24.0
145.145.23.78 – 145.145.23.100
и надо пробить адрес 123.123.123.78, поскольку блоки по степени вложенности сортированы сверху вниз, а скрипт ищет снизу, то результатом будет 123.123.123.60 – 123.123.123.100 а это и есть минимальный блок, так почему же он неправильный?
29 Августа, 2008 в 15:34
> 123.123.123.0 - 123.123.123.255
> 123.123.123.12 – 123.123.123.45
> 123.123.123.60 – 123.123.123.100
> 123.123.123.101 – 123.123.123.192
> 135.213.234.10 – 135.213.234.255
> 140.220.100.12 – 140.220.100.192
> 145.145.23.78 – 145.145.24.0
> 145.145.23.78 – 145.145.23.100
> и надо пробить адрес 123.123.123.78, поскольку блоки по степени вложенности сортированы сверху вниз,
> а скрипт ищет снизу, то результатом будет 123.123.123.60 – 123.123.123.100 а это и есть минимальный
> блок, так почему же он неправильный?
Извиняюсь, погорячился
Согласен с Вами, обратный поиск решает проблему любого уровня вложенности. Я еще потестирую скрипт, и затем он будет выложен на сайт. Спасибо за интерес к нашему проекту.
2 Октября, 2008 в 21:53
Да сделайте наконец xml версию, и всё остальное отпадёт, уже на маразм походит это всё %)
4 Октября, 2008 в 16:45
Учитывая большие нагрузки на сервис это не совсем тривиальная задача. Мы работаем над этим. Через некоторое время сервис будет доступен.
5 Октября, 2008 в 20:55
Было бы очень удобно, если бы было реализовано API для работы с базой, не требующее ни скачки и слежения за обновлением базы, ни осознания принципов организации файлов бд и их разбора.
Например, программист бы писал: ipgeobase.ru/api?key=ключдлясайта&ip=интересующийайпишник&charset=utf-8
И получал бы:
1:Регион:Область:Город
или
0:Не найден
7 Октября, 2008 в 14:49
> ни скачки и слежения за обновлением базы, ни осознания принципов организации файлов
> бд и их разбора.
> Например, программист бы писал: ipgeobase.ru/api?key=ключдлясайта&ip=
> интересующийайпишник&charset=utf-8
> И получал бы:
> 1:Регион:Область:Город
> или
> 0:Не найден
Это и есть xml версия, о которой говорит sunsword. В ближайшее время такой сервис будет доступен.
15 Октября, 2008 в 12:04
Такая идея, просто выскажу. Ведь если когда-то в будущем, будет точно определяться адрес внутри населённого пункта, имея гугломапсы, которые умеют просчитывать маршрут, можно будет рисовать посетителю сайта не просто схему проезда к нашему офису компании, но схему проезда именно от его местоположения, с учётом развязок и светофоров.
И вопрос теперь без шуток. База совместима по формату с ситилайт максмайнда? Т.е. есть решение на максмайнде, которое внутри РФ сильно промахивается в 50% случаев, может есть какойто конвертер данной базы в dat максмайнда?
15 Октября, 2008 в 14:30
Такая идея, просто выскажу. Ведь если когда-то в будущем, будет точно определяться адрес внутри населённого пункта, имея гугломапсы, которые умеют просчитывать маршрут, можно будет рисовать посетителю сайта не просто схему проезда к нашему офису компании, но схему проезда именно от его местоположения, с учётом развязок и светофоров.
И вопрос теперь без шуток. База совместима по формату с ситилайт максмайнда? Т.е. есть решение на максмайнде, которое внутри РФ сильно промахивается в 50% случаев, может есть какойто конвертер данной базы в dat максмайнда?
Это практически нереально сделать, т.к. собирать информацию по точному гео-положению IP-адреса (до дома или улицы) надо вручную связываясь с администраторами блоков. Тем более, в большинстве случаев эта информация конфиденциальна.
Нет, не совместима. Но перегнать ее в максмайндовский формат задача не сложная.
7 Ноября, 2008 в 9:01
Python-версия cidr_ru_search.pl
Я не разбирался с алгоритмом, просто в тупую переписал на python и оформил в виде класса
Можно использовать как python-библиотеку
Инструкции в самом скрипте
http://genum.ru/base/static/public/ipgeobase.py
8 Ноября, 2008 в 17:33
Python-версия cidr_ru_search.pl
Я не разбирался с алгоритмом, просто в тупую переписал на python и оформил в виде класса
Можно использовать как python-библиотеку
Инструкции в самом скрипте
http://genum.ru/base/static/public/ipgeobase.py
Спасибо, я думаю некоторым пользователям это будет интересно.
21 Ноября, 2008 в 15:38
не исключаю, что вопрос “от чайника”, но:
возможно ли появление в базе IP-адресов по административным округам Москвы?
если нет. то почему, если да, тов какие сроки ))
Спасибо
26 Ноября, 2008 в 17:44
не исключаю, что вопрос “от чайника”, но:
возможно ли появление в базе IP-адресов по административным округам Москвы?
если нет. то почему, если да, тов какие сроки ))
Спасибо
Это проблематично, т.к. такую информацию надо узнавать у множества провайдеров.
Во-первых это титаническая ручная работа, а во-вторых далеко не все провайдеры предоставят такую информацию.
27 Ноября, 2008 в 18:07
http://github.com/maxlapshin/ipgeobase
Версия для использования с Ruby on Rails, через Ruby-Inline. Сам поиск сделан на C, ищет только город (мне ничего кроме этого не было нужно).
10 Декабря, 2008 в 15:32
http://www.softkey.ru/catalog/program.php?ID=30947
Компилирует Вашу базу, работает за 10 запросов в бинарный файл.
Не грузит хостинг и не создаёт паразитного трафика.
13 Декабря, 2008 в 23:28
Импортнул всё в MySQL-таблицу:
$f = fopen(’cidr_ru_block.txt’, ‘r’);
while (!feof($f)) {
$s = iconv(’windows-1251′, ‘UTF-8′, trim(fgets($f)));
$a = explode(”\t”, $s);
mysql_query(”INSERT INTO ip_base (start, end, range, country, place, area, region, status, info) VALUES (”.intval($a[0]).”, “.intval($a[1]).”, ‘”.trim($a[2]).”‘, ‘”.trim($a[3]).”‘, ‘”.trim($a[4]).”‘, ‘”.trim($a[5]).”‘, ‘”.trim($a[6]).”‘, ‘”.trim($a[7]).”‘, ‘”.addslashes(trim($a[8])).”‘)”);
}
fclose($f);
Тип таблицы MyISAM, размер 15.5 MB, время импорта меньше минуты. Дальше город определяю так:
$ip = trim($_SERVER['REMOTE_ADDR']);
$aip = explode(’.', $ip);
$sum = $aip[0] * 16777216 + $aip[1] * 65536 + $aip[2] * 256 + $aip[3];
$r = mysql_query(”SELECT place FROM ip_base WHERE start < “.$sum.” AND “.$sum.” < end ORDER BY id DESC LIMIT 1″);
if (mysql_num_rows($r) != 0)
list($place) = mysql_fetch_row($r);
else
$place = ‘[неизвестно]‘;
echo ‘Ваше местонахождение: ‘.$place;
Всем удачи!
22 Декабря, 2008 в 14:58
В тайтле страницы написано «География россйских» — забыли И после С.
23 Декабря, 2008 в 16:26
Укажите пожалуйста в тайтле какой именно страницы ошибка. Заранее спасибо за сообщение об ошибке
6 Января, 2009 в 13:00
На домашней! Я думаю, что ошибка в шаблоне!
13 Января, 2009 в 21:03
Ответьте, пожалуйста на письмо, отправленное с того же адреса, который указан при добавлении этого комментария, письмо с предложением помощи в развитии проекта.
20 Января, 2009 в 18:55
Возможно Ваше письмо затерялось в потоке спама. Мы очень заинтересованы в сотрудничестве. Перешлите пожалуйста на ipgeo-base@mail.ru
26 Января, 2009 в 19:05
Для своих нужд написал скрипт, работающий с базой. Возможно он будет кому то полезен.
Для его работы необходимы:
- файл cidr_ru_slave_index.db
- PHP версии от 5.0
- желательно наличие в системе команды grep.
Пример работы:
http://www.datalab.ru/geo/sample.php
Скачать вместе с последней базой можно отсюда:
http://www.datalab.ru/geo/geo.zip
Скрипт имеет два режима работы в зависимости от присутствия в системе команды grep.
С grep-ом работает в 2-10 быстрее (в зависимости от системы). Режим выбирается автоматически.
Help находится в заголовке файла Geoip.php.
При условии размещения фала с базой в той же директории что и скрипт, никакой настройки не требуется. Если файл с базой находится в другой директории, необходимо указать путь до папки в константе GEO_IP_DB_FOLDER.
29 Января, 2009 в 14:34
…
Спасибо Вам, Дмитрий.
19 Марта, 2009 в 1:02
Ребята, спасибо за базу. Просто отличный вариант. Тот что юзал до того как нашел Вас в корне ужасный. Вероятность верного определения по моим подсчетам не превысила 50%
19 Марта, 2009 в 13:04
Спасибо за Ваш отзыв! Мы будем развиваться и улучшать наш сервис в будущем.
23 Марта, 2009 в 13:33
А могли бы вы сохранять файлы (в частности block_coord.db ) в кодировке UTF-8?
23 Марта, 2009 в 19:51
А в чем состоит проблема перекодировать?
24 Марта, 2009 в 9:21
Проблему решил, извините за беспокойство
24 Марта, 2009 в 16:44
Сделяйте, плз, в XML запросе еще одно поле - кодировка…
И язык…
Типа:
cp1251
ru
Причем можно даже перед заданием списка IP, все-равно формат вывода для всех один пойдет…
24 Марта, 2009 в 18:35
И язык…
Типа:
cp1251
ru
Причем можно даже перед заданием списка IP, все-равно формат вывода для всех один пойдет…
По многочисленным просьбам добавим в ближайшем будущем. Пока сервис отдает ответ только в cp1251
27 Марта, 2009 в 12:09
Для своих нужд написал парсер файла cidr_ru_block.txt. Немного доработал и выложил. Если интересно, скрипт тут: http://saterenko.ru/files/ipgeobase.php.gz, описание тут: http://saterenko.ru/2009/03/27/Российская-география/.
Надеюсь, за лёгкую критику в описании простите
27 Марта, 2009 в 15:42
Надеюсь, за лёгкую критику в описании простите
Спасибо за Ваш труд. Однако хочу отметить, что вложенная структура соответствует политике выделения адресов RIPE и локальными интерент-реестрами (провайдерами) и их склеивание в диапазаны подряд недопустимо.
28 Мая, 2009 в 0:50
Здраствуйте. Вопрос по базе cidr_ru_block.txt. Скажите как вы определяете к какому региону и городу принадлежит блок IP-адресов?
Насколько мне известно в базе RIPE есть только указание какой стране принадлежит блок IP-адресов, а к какому региону или городу нет.
Смотрел в базах RIPE по адресу: ftp://ftp.ripe.net/ripe/dbase/ripe.db.dummy.gz
Может я смотрю не в той базе? Тогда подскажите, пожалуйста, адрес базы, которую вы используете при заполнении файла cidr_ru_block.txt?
2 Июня, 2009 в 20:01
Насколько мне известно в базе RIPE есть только указание какой стране принадлежит блок IP-адресов, а к какому региону или городу нет.
Смотрел в базах RIPE по адресу: ftp://ftp.ripe.net/ripe/dbase/ripe.db.dummy.gz
Может я смотрю не в той базе? Тогда подскажите, пожалуйста, адрес базы, которую вы используете при заполнении файла cidr_ru_block.txt?
Мы используем собственное ПО для определения города блока, в этом заключается суть проекта IpGeoBase. Город привязывается на основе синтаксического анализа полей RIPE, обратной связи от пользователей и многих других факторов.
10 Июня, 2009 в 23:29
Ну и код у вас! От кого прячетесь?
===============================
Сервис на высоте. Проект замечательный.
Но как всегда хочется большего.
Искал в интернете статистику пользователей. Путного ничего нет.
Например, сколько интернет-пользователей по регионам, городам, областям?
Сколько из них “домашних”, сколько пользователей от предприятий, заводов и фабрик?
================================
Карта понравилась. Хорошо бы еще показывала снимок из космоса с указанием дома
30 Июня, 2009 в 15:40
Добрый день!
Предлагаю упростить сервис и разгрузить ваш сервер следующим образом: в ответ на запрос по некоему URL просто выгружать в виде XML всю базу адресов. Как это сделано, например, на cbr.ru с курсами валют. Это позволит один раз в сутки (а вообще и реже) закачивать базу к себе на сервер и приложения будут обращаться к внутренней базе за инфой, а не терроризировать ваш сервер. Кроме того улучшается скорость обмена между приложением и базой, и, вероятные ошибки из-за отсутствия коннекта к вашему серверу, от сервера, скажем, в Иркутске. Т.е. фактически таким образом можно закешировать инфу в своей базе. Понятно, что объем базы велик и поэтому может имеет смысл именно для этого сервиса сделать ограничения, например не более 4-5 скачиваний базы с одного IP.
30 Июня, 2009 в 17:32
Дополнения. В одном из комментариев прочитал следующее:
“Предложение к администрации: было бы неплохо, если бы сервер отдавал еще такие данные:
- кроме названия региона, его двухцифровой код;
- телефонный код города ”
Мысль не плоха, но предлагаю не изобретать велосипед, а задействовать в качестве кода города его почтовый индекс. Список индексов для всех населенных пунктов есть тут: http://ru-zip.com/ Таблицу соответствия кодов и городов (справочник) можно смастерить самостоятельно, а можно пускать отдельным блоком в XML файле, о котором я писал в коменте 77 и в основном блоке с адресами не указывать город словами, а только код, файл несколько уменьшится. Телефонные код…. не знаю насколько это необходимо, а вот часовой пояс в справочнике кодов городов не помешал бы, мне думается. В виде разницы от UTC без учета перехода на летнее время.
6 Июля, 2009 в 13:27
Предлагаю упростить сервис и разгрузить ваш сервер следующим образом: в ответ на запрос по некоему URL просто выгружать в виде XML всю базу адресов. Как это сделано, например, на cbr.ru с курсами валют. Это позволит один раз в сутки (а вообще и реже) закачивать базу к себе на сервер и приложения будут обращаться к внутренней базе за инфой, а не терроризировать ваш сервер. Кроме того улучшается скорость обмена между приложением и базой, и, вероятные ошибки из-за отсутствия коннекта к вашему серверу, от сервера, скажем, в Иркутске. Т.е. фактически таким образом можно закешировать инфу в своей базе. Понятно, что объем базы велик и поэтому может имеет смысл именно для этого сервиса сделать ограничения, например не более 4-5 скачиваний базы с одного IP.
Здравствуйте.
А смысл? Ежедневно обновляемая база доступна по адресу: http://ipgeobase.ru/cgi-bin/Archive.cgi. Сервис сделан для того, чтобы клиенты не хранили у себя базу.
6 Июля, 2009 в 13:40
“Предложение к администрации: было бы неплохо, если бы сервер отдавал еще такие данные:
- кроме названия региона, его двухцифровой код;
- телефонный код города ”
Мысль не плоха, но предлагаю не изобретать велосипед, а задействовать в качестве кода города его почтовый индекс. Список индексов для всех населенных пунктов есть тут: http://ru-zip.com/ Таблицу соответствия кодов и городов (справочник) можно смастерить самостоятельно, а можно пускать отдельным блоком в XML файле, о котором я писал в коменте 77 и в основном блоке с адресами не указывать город словами, а только код, файл несколько уменьшится. Телефонные код…. не знаю насколько это необходимо, а вот часовой пояс в справочнике кодов городов не помешал бы, мне думается. В виде разницы от UTC без учета перехода на летнее время.
Отличная идея, оня обязательно появится в следующей версии.
29 Июля, 2009 в 11:39
Выложил отфильтрованную базу ipgeobase.ru.
В архиве есть все регионы (отфильтрованные , нет совпадений),
и все города РФ по регионам связанные по regionID (отфильтрованные , нет совпадений),
и полная база IP.
В базе 3 таблиц соответственно (отпарсенная в кодировке UTF-8 / mysql)
http://narod.ru/disk/11397282000/2009-07-29_12-34.ZIP.html
11 Августа, 2009 в 3:35
Замечательно, что вы создали поддерживаете такой сервис, но…
Может, я, конечно, чего-то не понимаю, но зачем плодить столько диапазонов, когда можно объединить их в один? Это же ускорит поиск в разы… Внимательно перечитал хелп у вас на сайте, но так ничего и не нашел
Смотрим первые же 20 строк базы slave:
1040547840 1040547855 62.5.128.0 - 62.5.128.15 RU Москва Москва Центральный ASSIGNED PA
1040547856 1040547871 62.5.128.16 - 62.5.128.31 RU Москва Москва Центральный ASSIGNED PA
1040547872 1040547887 62.5.128.32 - 62.5.128.47 RU Москва Москва Центральный ASSIGNED PA
1040547888 1040547903 62.5.128.48 - 62.5.128.63 RU Москва Москва Центральный ASSIGNED PA
1040547904 1040547919 62.5.128.64 - 62.5.128.79 RU Москва Москва Центральный ASSIGNED PA
1040547920 1040547935 62.5.128.80 - 62.5.128.95 RU Москва Москва Центральный ASSIGNED PA
1040547936 1040547951 62.5.128.96 - 62.5.128.111 RU Москва Москва Центральный ASSIGNED PA
1040547952 1040547967 62.5.128.112 - 62.5.128.127 RU Москва Москва Центральный ASSIGNED PA
1040547968 1040547983 62.5.128.128 - 62.5.128.143 RU Москва Москва Центральный ASSIGNED PA
1040547984 1040547999 62.5.128.144 - 62.5.128.159 RU Москва Москва Центральный ASSIGNED PA
1040548000 1040548015 62.5.128.160 - 62.5.128.175 RU Москва Москва Центральный ASSIGNED PA
1040548016 1040548031 62.5.128.176 - 62.5.128.191 RU Москва Москва Центральный ASSIGNED PA
1040548032 1040548047 62.5.128.192 - 62.5.128.207 RU Москва Москва Центральный ASSIGNED PA
1040548048 1040548063 62.5.128.208 - 62.5.128.223 RU Москва Москва Центральный ASSIGNED PA
1040548064 1040548079 62.5.128.224 - 62.5.128.239 RU Москва Москва Центральный ASSIGNED PA
1040548080 1040548095 62.5.128.240 - 62.5.128.255 RU Москва Москва Центральный ASSIGNED PA
1040548096 1040548111 62.5.129.0 - 62.5.129.15 RU Москва Москва Центральный ASSIGNED PA
1040548112 1040548127 62.5.129.16 - 62.5.129.31 RU Москва Москва Центральный ASSIGNED PA
1040548144 1040548159 62.5.129.48 - 62.5.129.63 RU Москва Москва Центральный ASSIGNED PA
1040548160 1040548223 62.5.129.64 - 62.5.129.127 RU Москва Москва Центральный ASSIGNED PA
И видим, что до строки 18 идет один диапазон с одним и тем же городом и реионом, но зачем-то разбитый на 18 маленьких диапазонов.
То есть эти 20 строк можно было уместить в 2:
1040547840 1040548127 62.5.128.0 - 62.5.129.31 RU Москва Москва Центральный ASSIGNED PA
1040548144 1040548223 62.5.129.48 - 62.5.129.127 RU Москва Москва Центральный ASSIGNED PA
И таких ЛИШНИХ строк в таблице 88 ТЫСЯЧ из 120 ТЫСЯЧ всего. То есть вместо огромной базы в 120 000 строк, мы могли бы иметь базу в 4 раза меньше. Объясните, пожалуйста, для чего такое разбиение?
15 Августа, 2009 в 17:26
У нас есть флажки (собственного производства) на все регионы и города
России из вашей базы.
Мы хотим бесплатно поделиться ими с народом (на вашем сайте).
3 Сентября, 2009 в 14:32
Может, я, конечно, чего-то не понимаю, но зачем плодить столько диапазонов, когда можно объединить их в один? Это же ускорит поиск в разы… Внимательно перечитал хелп у вас на сайте, но так ничего и не нашел
Смотрим первые же 20 строк базы slave:
1040547840 1040547855 62.5.128.0 - 62.5.128.15 RU Москва Москва Центральный ASSIGNED PA
1040547856 1040547871 62.5.128.16 - 62.5.128.31 RU Москва Москва Центральный ASSIGNED PA
1040547872 1040547887 62.5.128.32 - 62.5.128.47 RU Москва Москва Центральный ASSIGNED PA
1040547888 1040547903 62.5.128.48 - 62.5.128.63 RU Москва Москва Центральный ASSIGNED PA
1040547904 1040547919 62.5.128.64 - 62.5.128.79 RU Москва Москва Центральный ASSIGNED PA
1040547920 1040547935 62.5.128.80 - 62.5.128.95 RU Москва Москва Центральный ASSIGNED PA
1040547936 1040547951 62.5.128.96 - 62.5.128.111 RU Москва Москва Центральный ASSIGNED PA
1040547952 1040547967 62.5.128.112 - 62.5.128.127 RU Москва Москва Центральный ASSIGNED PA
1040547968 1040547983 62.5.128.128 - 62.5.128.143 RU Москва Москва Центральный ASSIGNED PA
1040547984 1040547999 62.5.128.144 - 62.5.128.159 RU Москва Москва Центральный ASSIGNED PA
1040548000 1040548015 62.5.128.160 - 62.5.128.175 RU Москва Москва Центральный ASSIGNED PA
1040548016 1040548031 62.5.128.176 - 62.5.128.191 RU Москва Москва Центральный ASSIGNED PA
1040548032 1040548047 62.5.128.192 - 62.5.128.207 RU Москва Москва Центральный ASSIGNED PA
1040548048 1040548063 62.5.128.208 - 62.5.128.223 RU Москва Москва Центральный ASSIGNED PA
1040548064 1040548079 62.5.128.224 - 62.5.128.239 RU Москва Москва Центральный ASSIGNED PA
1040548080 1040548095 62.5.128.240 - 62.5.128.255 RU Москва Москва Центральный ASSIGNED PA
1040548096 1040548111 62.5.129.0 - 62.5.129.15 RU Москва Москва Центральный ASSIGNED PA
1040548112 1040548127 62.5.129.16 - 62.5.129.31 RU Москва Москва Центральный ASSIGNED PA
1040548144 1040548159 62.5.129.48 - 62.5.129.63 RU Москва Москва Центральный ASSIGNED PA
1040548160 1040548223 62.5.129.64 - 62.5.129.127 RU Москва Москва Центральный ASSIGNED PA
И видим, что до строки 18 идет один диапазон с одним и тем же городом и реионом, но зачем-то разбитый на 18 маленьких диапазонов.
То есть эти 20 строк можно было уместить в 2:
1040547840 1040548127 62.5.128.0 - 62.5.129.31 RU Москва Москва Центральный ASSIGNED PA
1040548144 1040548223 62.5.129.48 - 62.5.129.127 RU Москва Москва Центральный ASSIGNED PA
И таких ЛИШНИХ строк в таблице 88 ТЫСЯЧ из 120 ТЫСЯЧ всего. То есть вместо огромной базы в 120 000 строк, мы могли бы иметь базу в 4 раза меньше. Объясните, пожалуйста, для чего такое разбиение?
Такое разбиение соответствует разбиению по блокам в базе RIPE (www.ripe.net). С точки зрения географии, Вы правы. Однако это нарушает логическую связь с whois сервисом RIPE и с ихней базой. Также потеряют смысл такие поля как
24 Сентября, 2009 в 18:46
Здравствуйте.
Скажите, пожалуйста, есть ли возможность узнать, обновились ли данные в базе или нет (API какой-нить)?
Спасибо.
6 Октября, 2009 в 17:28
Скажите, пожалуйста, есть ли возможность узнать, обновились ли данные в базе или нет (API какой-нить)?
Спасибо.
Данные в базе обновляются каждый день.
16 Ноября, 2009 в 2:22
Спасибо Вам за проект.
Получился очень полезный инфо-блок “Поиск географического местонахождения IP-адреса в Российской Федерации” использующий Вашу Базу Данных. Посмотреть можно здесь: shina76.ru (нижний блок).
И, конечно, появилась возможность оценивать географию посетителей сайта.
Желаю Вам дальнейшего интенсивного и экстенсивного развития проекта.
Так как к хорошему быстро привыкаешь, то теперь очень не хватает иностранных блоков.
24 Ноября, 2009 в 0:34
Было бы очень удобно получать туже информацию, на запрос nslookup -q=TXT
так как это реализовано в почтовых блэк листах!
25 Ноября, 2009 в 19:14
Пользуюсь достаточно долго Вашим сервисом, очень доволен. На днях заметил проблемку - при расширенном поиске в Москве недоступен список mntner (выпадающий список пустой).
Собственно, вот ссылка: http://ipgeobase.ru/cgi-bin/AdvSearch.cgi?city=%CC%EE%F1%EA%E2%E0®ion=%CC%EE%F1%EA%E2%E0&district=%D6%E5%ED%F2%F0%E0%EB%FC%ED%FB%E9&adv_srch_sbmt=%C8%F1%EA%E0%F2%FC&action_type=adv_search
Надеюсь скоро исправите. Успехов в развитии!
24 Декабря, 2009 в 15:27
Собственно, вот ссылка: http://ipgeobase.ru/cgi-bin/AdvSearch.cgi?city=%CC%EE%F1%EA%E2%E0®ion=%CC%EE%F1%EA%E2%E0&district=%D6%E5%ED%F2%F0%E0%EB%FC%ED%FB%E9&adv_srch_sbmt=%C8%F1%EA%E0%F2%FC&action_type=adv_search
Надеюсь скоро исправите. Успехов в развитии!
Уже исправили, спасибо за замечание)
24 Декабря, 2009 в 15:31
так как это реализовано в почтовых блэк листах!
Спасибо за предложение, мы подумаем над ним.
17 Января, 2010 в 15:21
в хелпе написано, что “Формат файла cidr_ru_slave_index.db полностью аналогичен формату файла cidr_ru_block.txt”, однако в первом отсутствует последний столбец - Описание блока. очень бы хотелось бы увидеть этот столбец.
отдельное спасибо за проделанную работу!
18 Января, 2010 в 14:52
отдельное спасибо за проделанную работу!
Хорошее предложение, думаю в ближайшее время добавим это поле, однако если Вам срочно нужен столбец с описанием, можно воспользоваться XML сервисом, он отдает это поле.
28 Января, 2010 в 11:34
Доброго времени суток.
Вчера ошибочно создал аналогичный пост в ветке “Неверное местонахождение IP-адреса” - исправляюсь.
Предложение/просьба: возможно ли в ответах на XML - запросы возвращать значение параметра “netname”.
Я проверял довольно большое кол-во адресов inetnum которых были следующими:
109.188.0.0 - 109.188.63.255
109.188.192.0 - 109.188.255.255
188.162.0.0 - 188.162.31.255
188.162.96.0 - 188.162.127.255
188.162.176.0 - 188.162.191.255
188.162.224.0 - 188.162.255.255
188.162.32.0 - 188.162.39.255
188.162.40.0 - 188.162.47.255
94.25.128.0 - 94.25.191.255
Судя по информации с сайта http://www.db.ripe.net все эти адреса относятся к провайдеру SCARLET (yota). Ответ, получаемый на XML запрос я анализирую в Excel. По всем адресам в поле inet-descr получаю значение “infrastructure in Msk”, что не удобно для моего анализа.
Пример с сайт: http://www.db.ripe.net
inetnum: 94.25.128.0 - 94.25.191.255
netname: SCARTEL
mnt-domains: SCARTEL-MSK-MNT
mnt-routes: SCARTEL-MSK-MNT
descr: infrastructure in Msk
country: RU
admin-c: Phl76
tech-c: PhL76
status: ASSIGNED PA
remarks: Contact information:
*************************************
Abuse:abuse@scartel.ru
Peering:noc@scartel.ru
*************************************
mnt-by: SCARTEL-MSK-MNT
source: RIPE # Filtered
person: Phil Latyshev
address: Rusakovskaya, 13, 107140 Moskov RUSSIAN FEDERATION
phone: +79254116273
nic-hdl: PhL76
source: RIPE # Filtered
% Information related to ‘94.25.128.0/21AS47395′
route: 94.25.128.0/21
descr: MSK SCARTEL network
origin: AS47395
mnt-by: SCARTEL-MSK-MNT
source: RIPE # Filtered
% Information related to ‘94.25.128.0/18AS47395′
route: 94.25.128.0/18
descr: MSK SCARTEL network
origin: AS47395
mnt-by: SCARTEL-MSK-MNT
source: RIPE # Filtered
29 Января, 2010 в 17:05
Вчера ошибочно создал аналогичный пост в ветке “Неверное местонахождение IP-адреса” - исправляюсь.
Предложение/просьба: возможно ли в ответах на XML - запросы возвращать значение параметра “netname”.
Я проверял довольно большое кол-во адресов inetnum которых были следующими:
109.188.0.0 - 109.188.63.255
109.188.192.0 - 109.188.255.255
188.162.0.0 - 188.162.31.255
188.162.96.0 - 188.162.127.255
188.162.176.0 - 188.162.191.255
188.162.224.0 - 188.162.255.255
188.162.32.0 - 188.162.39.255
188.162.40.0 - 188.162.47.255
94.25.128.0 - 94.25.191.255
Судя по информации с сайта http://www.db.ripe.net все эти адреса относятся к провайдеру SCARLET (yota). Ответ, получаемый на XML запрос я анализирую в Excel. По всем адресам в поле inet-descr получаю значение “infrastructure in Msk”, что не удобно для моего анализа.
Пример с сайт: http://www.db.ripe.net
inetnum: 94.25.128.0 - 94.25.191.255
netname: SCARTEL
mnt-domains: SCARTEL-MSK-MNT
mnt-routes: SCARTEL-MSK-MNT
descr: infrastructure in Msk
country: RU
admin-c: Phl76
tech-c: PhL76
status: ASSIGNED PA
remarks: Contact information:
*************************************
Abuse:abuse@scartel.ru
Peering:noc@scartel.ru
*************************************
mnt-by: SCARTEL-MSK-MNT
source: RIPE # Filtered
person: Phil Latyshev
address: Rusakovskaya, 13, 107140 Moskov RUSSIAN FEDERATION
phone: +79254116273
nic-hdl: PhL76
source: RIPE # Filtered
% Information related to ‘94.25.128.0/21AS47395′
route: 94.25.128.0/21
descr: MSK SCARTEL network
origin: AS47395
mnt-by: SCARTEL-MSK-MNT
source: RIPE # Filtered
% Information related to ‘94.25.128.0/18AS47395′
route: 94.25.128.0/18
descr: MSK SCARTEL network
origin: AS47395
mnt-by: SCARTEL-MSK-MNT
source: RIPE # Filtered
Добрый день. Мы подумаем над Вашим предложением по поводу netname. Первоначально сервис служит для географического определения и дополнительные поля не столь важны.
Указанные Вами блоки определяются верно.
31 Января, 2010 в 2:27
Добрый день!
Для начала хочу сказать вам огромное спасибо за такой прекрасный сервис.
А мое предложение такое: не могли бы вы сделать отображения хотя названия стран для зарубежных ip:
Например: Америка для американских ip, Франция для французских.
Очень этого не хватает.
С уважением, Evgeny
5 Февраля, 2010 в 17:04
Для начала хочу сказать вам огромное спасибо за такой прекрасный сервис.
А мое предложение такое: не могли бы вы сделать отображения хотя названия стран для зарубежных ip:
Например: Америка для американских ip, Франция для французских.
Очень этого не хватает.
С уважением, Evgeny
Добрый день, спасибо за отзыв
На главной странице поиска отображаются европейские адреса. Адреса остального мира в скором будущем будут подключены и к сайту и к сервису, пока на это не хватает мощностей.
17 Февраля, 2010 в 11:09
Здравствуйте! Возможно ли базу IP номеров интегрировать в систему управления рекламой OpenX? Для более качественного гетаргетинга по России. Из за кривости их платных баз теряются порядка 30% показов. В вашу базу веры больше.
25 Февраля, 2010 в 16:10
Спасибо за веру в нашу базу! Я думаю, что возможно. Наш проект дает базу данных адресов и примеры ее использования. А встраивание базы в конкретную систему - задача вебмастера.
10 Апреля, 2010 в 19:47
Здравствуйте!
Очень хороший сервис. Спасибо!
Однако, было бы совсем здоров привести названия регионов, областей, краев и республик в соответствие с Главой 3 Конституции РФ.
12 Апреля, 2010 в 15:54
Очень хороший сервис. Спасибо!
Однако, было бы совсем здоров привести названия регионов, областей, краев и республик в соответствие с Главой 3 Конституции РФ.
Добрый день. Вы не могли бы уточнить, какие именно субъекты называются неправильно?
12 Апреля, 2010 в 18:03
почти все края бывшие области. Вот тут вы найдете отличия http://www.constitution.ru/10003000/10003000-5.htm спасибо за внимание к проблеме!
26 Мая, 2010 в 9:58
Как насчет поискового плагина для браузеров?
31 Мая, 2010 в 18:38
Добрый день, Владимир.
Наш проект ставит перед собой немного другие цели. Прежде всего - это определение положения клиента сайта, т.е. все скрипты - серверные. С какой целью Вы планируете использовать плагин в браузере?
3 Июня, 2010 в 23:26
Когда, редактируя профиль в Живом Журнале, я нажимаю кнопку, позволяющую определить местонахождение, то получаю город Minsk, что правильно, и “штат” Mahilyow Province - а вот это уже полная дичь.
Я обратился в Службу поддержки ЖЖ. Мне ответили, что автоматическое определение выполняется на основании данных базы с http://ipgeobase.ru/.
Как бы вернуть мой город из Могилевской области куда следует? На самом деле здесь ведь даже Минскую область указывать неправильно: Минск является самостоятельной административной единицей и ни в какую область Беларуси не входит.
18 Июня, 2010 в 15:52
Я обратился в Службу поддержки ЖЖ. Мне ответили, что автоматическое определение выполняется на основании данных базы с http://ipgeobase.ru/.
Как бы вернуть мой город из Могилевской области куда следует? На самом деле здесь ведь даже Минскую область указывать неправильно: Минск является самостоятельной административной единицей и ни в какую область Беларуси не входит.
Добрый день, Вадим.
Наш проект определяет местоположение только по России. Для Белорусии ЖЖ использует какую-то другую базу.
14 Сентября, 2010 в 21:05
Как насчет поискового плагина для браузеров?
21 Сентября, 2010 в 14:56
Мы уже думали над этим, вопрос решается ,возможно в будущем появятся плагины для основных броузеров.
26 Октября, 2010 в 20:48
Было бы здорово видеть ещЁ и координаты населенных пунктов.
26 Ноября, 2010 в 0:45
Здравствуйте !
Я написал класс на php для получения информации об IP, который использует ваши файлы базы данных.
Информация не парсится с вашего ресурса из сети, а находится в файлах локально на сервере. Думаю, кому-нибудь такая вещь может быть полезна. Вам нужен данный скрипт ?
26 Ноября, 2010 в 10:37
Хочу предложить еще один вариант кода на ASP.Net для получения данных от Вашего сервиса:
//Код получает имя города по IP пользователя
//внедряется в Site.Master
//подключаем нужные библиотеки
//собственно код
<% if (Session["CheckedCityByIP"] == null) {
//записываем признак того, что в текущей сессии уже вычисляли город
Session.Add(”CheckedCityByIP”, true);
//сначала город не определен
string City = “not found”;
//получаем IP пользователя
string UserHostAddress = Request.UserHostAddress;
//создаем запрос
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(”http://194.85.91.253:8090/geo/geo.html” ;
//метод POST
request.Method = “POST”;
//Credentials указываем иначе выскочит ошибка 407
request.Proxy.Credentials = CredentialCache.DefaultCredentials;
//задаем текст запроса, передавая в него IP пользователя, полученный выше. Преобразуем в массив байтов
byte[] EncodedPostParams = Encoding.ASCII.GetBytes(”" + UserHostAddress + “” ;
request.ContentLength = EncodedPostParams.Length;
request.GetRequestStream().Write(EncodedPostParams, 0, EncodedPostParams.Length);
request.GetRequestStream().Close();
//отправляем запрос
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
//получаем ответ в виде строки в кодировке windows-1251
string html = new StreamReader(response.GetResponseStream(), Encoding.GetEncoding(”windows-1251″ ).ReadToEnd();
//парсим ответ
XmlDocument xDocument = new XmlDocument();
xDocument.InnerXml = html;
//находим узел, соответствующий IP пользователя
XmlNode Node = xDocument.SelectSingleNode(string.Format(”/ip-answer/ip[@value='{0}']“, UserHostAddress));
if (Node != null) {
//находим узел города (либо лбой другой узел из ответа)
XmlNode NodeCity = Node.SelectSingleNode(”city” ;
if (NodeCity != null) {
City = NodeCity.InnerText;
}
}
%>
13 Декабря, 2010 в 15:43
Я написал класс на php для получения информации об IP, который использует ваши файлы базы данных.
Информация не парсится с вашего ресурса из сети, а находится в файлах локально на сервере. Думаю, кому-нибудь такая вещь может быть полезна. Вам нужен данный скрипт ?
Добрый день. Можете опубликовать тут, можете прислать на ipgeobase@mail.ru
26 Января, 2011 в 1:48
не нашел куда спросить:
скажите, а это все бесплатно? может стоит написать где-то на сайте: “ура-ура! сервис бесплатный!”. а то я сегодня прикручу его к своему сайту, а завтра вы мне скажете, что хотите денег… ммм?
10 Февраля, 2011 в 14:58
скажите, а это все бесплатно? может стоит написать где-то на сайте: “ура-ура! сервис бесплатный!”. а то я сегодня прикручу его к своему сайту, а завтра вы мне скажете, что хотите денег… ммм?
Проект полностью бесплатный и в ближайшее время плата взиматься не будет.
15 Мая, 2011 в 7:57
Понятно, что большинство русскоязычных порно-сайтов размещены на компьютерах в кладовках оборотистых жителей Украины. Как и большая часть всёго отстойного в рунете (казино, лотереи и пр. Предложения о размещении непристойной рекламы постоянно поступают из Киева, Одессы и др. городов этой «братской» страны). Так как там не существует законов “Об Интернете”. RU-CENTER зарабатывает, предоставляя украинским гражданам регистрировать сайты в зоне RU. Это дело RU-CENTER.
Но непонятно – зачем мне и посетителям сайта ждать когда в файле – cities.txt
будут перебраны записи:
Добромиль Львовская область Западная Украина 49.566666 22.783333
Перечин Закарпатская область Западная Украина 48.734165 22.474167
Галич Ивано-Франковская область Западная Украина 49.125053 24.729639
Чтобы дойти до российских IP, например:
Гагарин Смоленская область Центральный федеральный округ 55.550911 35.014992
Если трогательно заботитесь о жителях другой страны, то и пишите для них отдельный – cities.txt.
Украина как Малайзия не входит в состав Союзного государства, поэтому никого в России не волнует – правильно ли будет определяться Добромиль. Но с какой стати разработчикам России смотреть, как тратится время на перебор этих деревень соседнего государства, тем более из текстового файла.
16 Мая, 2011 в 16:51
Александр, мы стараемся сделать нашу базу более универсальной. Если вы скачиваете нашу базу и используете ее в своем ПО, думаю для вас не составит труда убрать строчки, в которых встречается “Украина”.
17 Мая, 2011 в 9:03
Универсальный - охватывающий всё, что сделать невозможно.
Определив, что адрес 37257214 входит в блок - 37224448 37257215 2.56.0.0 - 2.56.127.255 UA 187
относится к UA, вроде удобнее, на будущее, ссылаться не на 187 (187 Киев Центральная Украина 50.450001 30.523333),
а на файл - UA-cities.txt.
Иначе, при добавлении ещё нескольких стран, файл cities.txt будет громадным. Классика баз данных - блоки. Блоки - это скорость поиска и сортировки.
25 Мая, 2011 в 7:58
Прошу сделать поддержку адресов ipv6
26 Мая, 2011 в 14:58
Мы как раз этим занимаемся в данный момент.
12 Июня, 2011 в 19:43
Пожалуйста напишите какая сейчас структура у cidr_optim.txt. В частности интересует как упорядочены блоки. Я так понимаю, вложенных сейчас нет. Каким образом они отсортированы?
15 Июня, 2011 в 9:36
Исправьте, пожалуйста, у г. Киева регион на “Киевская область”.
Было бы здорово получать результаты на разных языках (я рассматриваю в контексте 1 страна = 1 язык, т.е. в данный момент - русский и украинский), один из которых национальный. Это очень удобно для интернациональных проектов, ведь транслитеризация производится с национального языка. Как пример: Kyiv (укр. Київ) и Kiev (рус. Киев).
15 Июня, 2011 в 10:14
Так же был бы неплох xml-rpc контроль версий. Ведь многие были бы рады размещать базы у себя на сервере, тем самым снижая нагрузку на ваши сервера, и обновлять их с помощью своих же скриптов, а парсить строку обновления баз на странице “Архив” не фен-шуй, вдруг вы дизайн поменяете?) В случае монетизации вашего сервиса эта фича в любом случае будет, так пусть же будет и в free варианте.
16 Июня, 2011 в 0:53
Перевод на PHP CLI поиска по новой базе просмотреть
17 Июня, 2011 в 13:40
Было бы отлично, если бы Ваш xml сервис выдавал временную зону города относительно UTC.. задача корректировки времен часто возникает при создании сайтов использующих геолокацию.
20 Июня, 2011 в 17:48
Хорошее предложение, мы реализуем ее в будущем.
20 Июня, 2011 в 19:22
Было бы здорово получать результаты на разных языках (я рассматриваю в контексте 1 страна = 1 язык, т.е. в данный момент - русский и украинский), один из которых национальный. Это очень удобно для интернациональных проектов, ведь транслитеризация производится с национального языка. Как пример: Kyiv (укр. Київ) и Kiev (рус. Киев).
Киев — отдельная административно-территориальная единица Украины.
По поводу языков - сделано. Файл лежит тут:
http://ipgeobase.ru/cgi-bin/Archive_dop.cgi
21 Июня, 2011 в 16:05
Блоки упорядочены по возрастанию, блоки последовательны (вложенной структуры нет) , последовательные с одинаковым городом склеены в один.
5 Июля, 2011 в 14:30
А куда делся провайдер в xml?
6 Июля, 2011 в 20:02
2александр:
>>> Но непонятно – зачем мне и посетителям сайта ждать когда в файле – cities.txt
будут перебраны записи:
Сформируй базу данных и напиши синхронизатор нормальный, вместо тобо, чтобы извергать своё тупое пробухавшееся хамство.
8 Июля, 2011 в 13:20
Здравствуйте!
У нас стало не хватать ресурсов для старого сервиса, некоторые поля пришлось убрать.
12 Октября, 2011 в 16:52
Здравствуйте!
Делюсь классом на php для работы с локальной копией новой базы данных. Встроена проверка ip + приемлемо высокая скорость поиска по базе.
http://miha.perm.ru/2011/10/12/ipgeo-class-php/
20 Января, 2012 в 19:04
поддерживаю реквест таймзон
21 Января, 2012 в 21:35
Здравствуйте!
Не могу воспользоваться Вашим сервисом ни с одного американского хостинга, удается только с российских. Это специальное ограничение? Существует ли способ все же как-то использовать сервис с заграничного хостинга?
17 Февраля, 2012 в 9:51
Здравствуйте,
Набросал простой PHP класс для работы с XML интерфейсом http://www.seomax.info/project/ipgeobase/ возможно пригодится.
Спасибо за базу!
17 Февраля, 2012 в 20:05
И вопрос:
* в cidr_ru_block.txt от 2010-11-06 у нас было 148673 раз строчка типа “\tRU\t”, что значит около 150 тыщ российских диапазонов
* в cidr_optim.txt от 2012-02-13 у нас уже 35061 раз строчка типа “\tRU\t”, что значит около 35 тыщ российских диапазонов
Сам вопрос — значит ли это, что подозрительное сокращение почти в четыре раза есть благодать слияния блоков в один город, а не баг?
22 Февраля, 2012 в 14:17
* в cidr_ru_block.txt от 2010-11-06 у нас было 148673 раз строчка типа “\tRU\t”, что значит около 150 тыщ российских диапазонов
* в cidr_optim.txt от 2012-02-13 у нас уже 35061 раз строчка типа “\tRU\t”, что значит около 35 тыщ российских диапазонов
Сам вопрос — значит ли это, что подозрительное сокращение почти в четыре раза есть благодать слияния блоков в один город, а не баг?
Это результат оптимизации. Раньше блоки шли так, как они были в RIPE, теперь последовательные блоки с одинаковым городом склеены.
16 Мая, 2013 в 7:49
Здравствуйте!
Будет ли вариант с JSONP-выдачей?
Или может быть возможно пересадить xml-сервис на стандартный 80-й порт?