Dziwne zachowanie metody dopasowania ciągów()

Napotkałem interesujący problem dotyczący metody String (RegExp).Dziwne zachowanie metody dopasowania ciągów()

assertTrue("33CCFF".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC33FF".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC3355".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC9955".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC3366".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC3965".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC1961".matches("[0-9A-Za-z]{6}")); 
assertTrue("CC9999".matches("[0-9A-Za-z]{6}")); 
assertTrue("СС3966".matches("[0-9A-Za-z]{6}")); // failing 
assertTrue("СС9965".matches("[0-9A-Za-z]{6}")); // failing 
assertTrue("СС9966".matches("[0-9A-Za-z]{6}")); // failing

Ostatnie 3 asercja nieoczekiwanie się zawiesza. Nie mogłem znaleźć żadnych powodów, dla których to dziwne zachowanie się dzieje. Czy masz ten sam problem? Czy masz jakies pomysły?

Przy okazji, w przypadku pytania, moja wersja java jest następująca.

java version "1.6.0_26" 
Java(TM) SE Runtime Environment (build 1.6.0_26-b03) 
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Źródło

2011-10-05 lemiorhan

Sprawdziłem po twoich odpowiedziach i zauważyłem, że górne znaki C (& # 0043) są różne niż dolne znaki C (& # 1057). Sygnały C w ostatnich 3 liniach wydają się być z cyrylicy. http://webdesign.about.com/od/localization/l/blhtmlcodes-ru.htm – lemiorhan

Problem występuje z powodu wprowadzenia danych przez użytkownika. Aby sprawdzić, czy dane wejściowe są dziesiętne (nawet dla cyrylicy C), org.apache.commons.lang.StringUtils.isAlphanumeric() zwraca true jako następujące: assertTrue (StringUtils.isAlphanumeric ("\ u0421 \ u0421")) ; // cyrillic C assertTrue (StringUtils.isAlphanumeric ("\ u00E7 \ u00E7")); // ascii C – lemiorhan

Ostatnie trzy nie faktycznie starcie z charakterem ASCII "C". Zaczynają się od znaków spoza ASCII, które wyglądają jak "C". To nie pasuje do niczego w zestawie [0-9A-Za-z], dlatego wzorzec się nie udaje.

(znalazłem to przez skopiowanie i wklejenie kodu do edytora tekstu, który nie obsługuje znaki spoza ASCII strasznie dobrze - „?”. Wyszli jako)

Źródło

2011-10-05 16:25:28

Prawo, kod HEX niewłaściwego znaku C to '0x3F', ale dla wszystkich poprzednich' C' jest '0x43' – sll

@sll: Nie, 3F to po prostu"? " który jest często używany do reprezentowania znaków, które nie mogą być reprezentowane w inny sposób. Pokazany znak to * nie * "?". –

dobry połów! Wygląda na to, że mój redaktor zastąpił tę postać przez '?' Przed zapisaniem – sll

swój „СС3966” (I. wycinanie i wklejanie) są oznaczane jako nie-UTF-8, dlatego reg-ex ich nie dopasowuje. Kiedy zmieniam twój tekst i po prostu go wpisuję, działa zgodnie z oczekiwaniami. Nie wiem, skąd skopiowano te wartości, ale to jest twój problem.

Źródło

2011-10-05 16:29:01

Dostałem twój punkt. Odkryłeś problem jako JonSkeet. Wielkie dzięki za odpowiedź. – lemiorhan

To zabawne ... John i ja dowiedzieliśmy się tej samej odpowiedzi, znalazłem ją na 1 minutę zanim to zrobił ... on dostaje 12 przegranych, dostaję 1 :) Wygląda na to, że to przecież konkurs popularności! lol. –

btw, kiedy wkleiłem twój mecz w moje zaćmienie i próbowałem zapisać, IT wyświetliło okno dialogowe z informacją, że próbuję zapisać tekst w formacie innym niż UTF-8. Nie sądzę, abym zmodyfikował moje ustawienia zaćmienia, więc powinieneś zobaczyć, dlaczego twój nie daje tego samego ostrzeżenia dla przyszłych problemów, takich jak ten. –

Dziwne zachowanie metody dopasowania ciągów()

Odpowiedz

Powiązane problemy