Sprawdzenie poprawności adresu www

Witam,
chciałbym umieć sprawdzać, czy tekst wpisany w TextField jest adresem strony www.
Jak to zrobić w Javie?
Wyrażenie regularne? jak je zdefiniować?

Proszę o pomoc,
pozdrawiam

textField.getText().matches("^(http://)?(www\\.)?.+\\.[a-zA-Z]{2,4}$");

Pisane na szybko.

boolean ok=true;
try
{
   new URL(textField.getText());
}
catch(MalformedURLException)
{
   ok=false;
}

@bo, Java nie ASM nie traktuj wyjątków jak przerwań i nie używaj ich do sterowania.

@metfan, pobierasz http://commons.apache.org/validator/ i masz klasę:
http://commons.apache.org/validator/apidocs/org/apache/commons/validator/UrlValidator.html

W Javadocu przykład jak to zrobić. Możesz pobrać kod źródłowy i sobie popatrzyć. Prosty regexp jak podał iooi nie wystarczy (nie uwzględnia m.n. parametrów, IP, portów).

Java nie ASM nie traktuj wyjątków jak przerwań i nie używaj ich do sterowania.

Jakieś większe powody ku temu, czy tylko wydajnościowe?

Java nie ASM nie traktuj wyjątków jak przerwań i nie używaj ich do sterowania.

Zakładałem, że użytkownik po to wpisuje adres strony w polu tekstowym by się z nią za chwilę połączyć. Zatem użycie wyjątku jest nieuniknione.
Jeśli nawet wpisuje ten adres "dla sportu", to nie widzę niczego złego w użyciu wyjątków do sprawdzenia poprawności adresu.

rzucenie wyjatku jest duzo bardziej kosztowne niz sprawdzenie wyrazenia regularnego. to tak jak bys iterowal po tablicy dopoki nie wypadnie arrayindeoxoutofboundexception.

@donkey7, @bo

Jeżeli chcemy używać wyjątków w językach wysokiego poziomu (Java/C#) do sterowania przepływem to popełniamy poważy błąd.

Po pierwsze wprowadzenie niepoprawnych danych nie powinno być traktowane jako sytuacja wyjątkowa. Klientom zdarza podać sie dane błędne, niepoprawne, z literówkami. Scenariusz danego procesu powinien uwzględniać taką sytuację i odpowiednio ją traktować bez potrzeby używania wyjątków. Jest nawet taka regułka, która mówi, że to co wysyłamy musi być poprane, a to co odbieramy może. Zatem przyjmując dane od klienta nie możemy założyć, że sytuacją wyjątkową będzie taka w której dane te będą niepoprawne.

Po drugie popatrzmy na kod przestawiony przez bo. Co oznacza ok w tym przypadku? Czy nie jest to kod nadmiarowy? Wykorzystując walidator apache mogę zrobić tak:

if(!validator.isvalid(addres)){
   sendErrorInfor(NOT_VALID);
}

czy ten kod nie jest czytelniejszy?

Po trzecie wyjątki mogą służyć do sterowania przepływem

• w momencie gdy tworzymy adapter i chcemy dużych ilości bloków catch:

// kod oryginalny
try{
   outsource.doSth();
}
catch(SthNotFound e){ }
catch(OurProgrammersAreLazy e){ }
catch(IOException e){ }

//kod adaptera
try{
   adapter.doSth();
}
catch(AdapterException e){}

W takim przypadku izolujemy nasz kod od kodu dostawcy i możemy wymienić dostawcę bez konieczności zmian w naszym kodzie. Powstaje coś w rodzaju adaptera wyjątku.

• w momencie gdy problem może być rozwiązany na wiele sposobów, ale decyzję powinien podjąć klient (kod wyżej).
• w momencie gdy sytuacja jest naprawdę wyjątkowa.

Opiszę dokładniej moje stanowisko w sprawie używania wyjątków do kontroli.

1. Użycie nieuzasadnione, głupie, godne potępienia,...

try
{
   //kod odwołujący się do tab[i]
}
catch(IndexOutOfBoundsException )
{
  ....
}

można bowiem prosto sprawdzić czy zmienna i ma właściwą wartość

if(i>=0 && i<tab.length)
{
   //kod odwołujący się do tab[i] 
}

2. Użycie uzasadnione, bo sprawdzenie jest kłopotliwe (skomplikowane). Mamy String s, należy sprawdzić czy można go "sparsować" do zmiennej typu int.

boolean mozna=true;
try
{
  Integer.parseInt(s);
}
catch(NumberFormatException e)
{
  mozna=false;
}

jest, Imho, znacznie lepsze od sprawdzania czy s zawiera odpowiednie znaki (cyfry, ew. '-' na początku, bez wiodących zer), czy s nie jest zbyt długi, jeśli s ma maksymalną dopuszczalną długość, to czy pierwsza cyfra jest '1' lub '2', jeśli jest '2', to czy następna cyfra jest '0' lub '1', ...

@bo, ale mam nadzieję, że ten kod zamykasz w dodatkowe metody i nie szwenda się on po całym projekcie:

public class NumberValidator{

  public static boolean  isValid(String s){
    boolean mozna=true;
    try{
      Integer.parseInt(s);
    }
    catch(NumberFormatException e){
      mozna=false;
    }
    return mozna;
  }
}

?

@eeee, w tym przykładzie zapewne chodzi o połączenie ze stroną. Trzeba będzie utworzyć URL, żeby kod skompilować i tak trzeba obsłużyć wyjątek. Istnieje też niebezpieczeństwo, że wyrażenie regularne zostanie błędnie napisane i odrzuci poprawny adres (przepuści błędny).
@Koziołek, jeśli chodzi o czytelność kodu, to

private boolean isValid(String adres)
{
   try
   {
       new URL(adres);
       return true;
   }
   catch(MalformedURLException e)
   {
       return false;
   }
}
....
if(!isValid(adres))
{
   ....
}

@bo, dlatego wolę walidator apache. Co do czytelności to tru. twój lepszy.

@Koziołek, nie chciałem się licytować w czytelności, tylko pokazać, że moje rozwiązanie można też napisać czytelnie. Jesteś zupełnie pewien, że validator Apache'e zwraca true <==> new URL(..) nie rzuca wyjątku?

@bo, nie. Walidator Apache sprawdza za pomocą wyrażeń regularnych napisanych na podstawie RFC.

Mógłby ktoś mi pomóc w utworzeniu wyrażenia regularnego, które dobrze się sprawdza dla adresów z i bez http, www, i akceptuje znak "/" na końcu adresu?

@metfan, zrób jak pisałem. Weź bibliotekę Apache Commons Validators i tam masz URL Validator. W środku są odpowiednie regexpy.