Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #7717

Re: contains

Show all headers | View raw

On 11-09-08 11:47 AM, Lew wrote:
> On Thursday, September 8, 2011 7:33:34 AM UTC-7, Arved Sandstrom wrote:
> 
> Your post had trouble, being in "UTC-7" and dealing with 8-bit characters.
> 
>> Lew wrote:
>>> Arved Sandstrom wrote:
>>>> bob wrote:
>>>>> Is there any case-insensitive version of the String contains method?
>>>>>
>>>> Not that I'm aware of. An easy way to do the deed is to use Pattern;
>>>> something like
>>>>
>>>> boolean isContained  =
>>>>     Pattern.compile("isThisStringContained",
>>>>         Pattern.CASE_INSENSITIVE)
>>>>     .matcher("stringThatMayContainOther").find();
>>>>
>>>> does the trick.
>>>>
>>>> A possibly preferable alternative to doing case-insensitive string
>>>> operations is simply to uppercase (or lowercase) both Strings before
>>>> doing the operation. .toLowerCase() and .toUpperCase() are String
>>>> methods that are available for this purpose. If you plan to do this a
>>>> lot you can write up a small utility method.
>>>
>>> Beware of uppercasing and lowercasing - the results can be surprising.
>>>
>>> String whatThe = "ß".toUpperCase().toLowerCase();
>>>
>>> What should be the value of '"ß".equalsIgnoreCase("ss")'?
>>>
>>> What should be the value of '"ß".toUpperCase().toLowerCase().equals("ß")'?
>>>
>> That's a good point, but it's no mystery that uppercasing/lowercasing
>> outside the standard 26-letter Latin alphabet has the odd pitfall here
>> and there, like Eszett rules.
>>
>> So my second suggestion applies in particular to Strings that contain
>> Latin characters. For anything else you'd best be aware of the rules and
>> the nature of your text.
> 
> Which means, for all practical purposes, always be aware of the rules and nature of your text.  Even here in the U.S. of A., we use lots of letters that don't fall into your (apparent) definition of "Latin" characters, for example, Latin-American names and loan words.  Never mind that in almost any context that a programmer cares about, you have to deal with locales.  Advising a programmer to deal with just the restriction to ASCII is a ludicrous suggestion.  You pretty much always have to be aware, at a minimum, of eight-bit characters, and really all of UTF-8.  To do otherwise is very irresponsible.

I'm not exactly advising any programmer to deal with just ASCII; what I
am saying here is that if you know that your text is ASCII text (*way*
more common than you make out) that lowercasing and uppercasing in this
particular situation is a potential approach. By ASCII text I still mean
Unicode; simply the ASCII subset thereof.

Incidentally, as a Canadian programmer who deals with a lot of
government information systems, and no small number of business
information systems, I can tell you straight up that it's not *my*
decision as to what characters are acceptable - that's decided by
analysts and business stakeholders. In fact it is still not uncommon for
many government systems at provincial levels not to deal with French
accents, let alone anything else outside the ASCII subset.

For example, one provincial vital information registry I've worked on,
which must communicate with other registries and also with federal
government systems, specifically has severe restrictions (including no
French-accented characters) so as to radically reduce the potential for
string operation errors in various use cases. There are excellent
reasons for doing this, namely that you have to deal with legacy data in
legacy systems that don't know from accents at all. This is common.

I'd be surprised if the majority of US-developed software is quite as
accommodating as you suggest. Partially for the same reason as I mention
above - as soon as one system starts using the full gamut of Unicode for
storing text information, any other systems that it talks to must have
the same data, or you must translate. If you're starting from scratch
then go full monty with Unicode and have fun; if you're dealing with all
those legacy datasets out there then it's not so easy.

And it's also not the programmer's decision - or shouldn't be - to start
using techniques such as those described in
http://www.rgagnon.com/javadetails/java-0456.html.

> Also, by definition "ß" is a Latin character, in the sense that it's in the Latin-1 (ISO8859-1) character set.
> 
> If you write for the 128
> Then you deserve your horrible fate.
> 
On a go-forward basis starting with a clean slate, absolutely, I agree.

AHS

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

contains bob <bob@coolgroups.com> - 2011-09-08 00:44 -0700
  Re: contains Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-08 08:19 -0300
    Re: contains Lew <lewbloch@gmail.com> - 2011-09-08 06:37 -0700
      Re: contains Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-08 11:33 -0300
        Re: contains Lew <lewbloch@gmail.com> - 2011-09-08 07:47 -0700
          Re: contains Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-08 18:59 +0000
            Re: contains Lew <lewbloch@gmail.com> - 2011-09-08 16:59 -0700
          Re: contains Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-09-08 16:37 -0300
            Re: contains supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-09-08 20:14 -0400
  Re: contains Arne Vajhøj <arne@vajhoej.dk> - 2011-09-08 20:05 -0400

csiph-web