substring() 应该如何工作?

发布于 2024-07-22 09:02:38 字数 511 浏览 9 评论 0原文

我不明白为什么Java的[String.substring()方法](http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#substring(int,%20int%29 ) 是按原样指定的,我无法告诉它从编号位置开始并返回指定数量的字符;如果我指定超出的结束位置。 而不是只为我返回字符串的其余部分。

我习惯了 substring() (或 substr())采用两个参数的语言:开始位置和长度, 客观上这比 Java 的做法更好吗?如果是的话,您能证明一下吗?您见过的 substring() 的最佳语言规范是什么?如果有的话,这对语言来说是个好主意吗? Java抛出的IndexOutOfBoundsException是否是一个好的设计思想? 这一切都只是取决于个人喜好吗?

I do not understand why Java's [String.substring() method](http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#substring(int,%20int%29) is specified the way it is. I can't tell it to start at a numbered-position and return a specified number of characters; I have to compute the end position myself. And if I specify an end position beyond the end of the String, instead of just returning the rest of the String for me, Java throws an Exception.

I'm used to languages where substring() (or substr()) takes two parameters: a start position, and a length. Is this objectively better than the way Java does it, and if so, can you prove it? What's the best language specification for substring() that you have seen, and when if ever would it be a good idea for a language to do things differently? Is that IndexOutOfBoundsException that Java throws a good design idea, or not? Does all this just come down to personal preference?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

维持三分热 2024-07-29 09:02:38

有时第二个参数是长度更方便,有时第二个参数是“之前停止的偏移量”更方便。 同样,有时“如果我给你的东西太大,只需转到字符串的末尾”就很方便,有时它表明存在错误并且应该真正抛出异常。

如果您有固定长度的字段,则第二个参数是长度,这很有用。 例如:

// C#
String guid = fullString.Substring(offset, 36);

如果您要使用另一个分隔符,则第二个参数是偏移量,这很有用:

// Java
int nextColon = fullString.indexOf(':', start);
if (start == -1)
{
    // Handle error
}
else
{
    String value = fullString.substring(start, nextColon);
}

根据我的经验,通常情况下,您想要使用的参数与当前平台上提供的参数相反:)

There are times when the second parameter being a length is more convenient, and there are times when the second parameter being the "offset to stop before" is more convenient. Likewise there are times when "if I give you something that's too big, just go to the end of the string" is convenient, and there are times when it indicates a bug and should really throw an exception.

The second parameter being a length is useful if you've got a fixed length of field. For instance:

// C#
String guid = fullString.Substring(offset, 36);

The second parameter being an offset is useful if you're going up to another delimited:

// Java
int nextColon = fullString.indexOf(':', start);
if (start == -1)
{
    // Handle error
}
else
{
    String value = fullString.substring(start, nextColon);
}

Typically, the one you want to use is the opposite to the one that's provided on your current platform, in my experience :)

乖乖哒 2024-07-29 09:02:38

我习惯了以下语言
substring()(或 substr())需要两个
参数:起始位置和
长度。 这客观上更好吗
比 Java 的方式更好,如果是这样,
你能证明吗?

不,客观上这并没有更好。 这完全取决于您想要使用它的上下文。 如果你想提取特定长度的子字符串,那就不好了,但如果你想提取以第一次出现“.”结尾的子字符串,那就不好了。 在字符串中,这比您首先必须计算长度要好。 问题是:哪种要求更常见? 我想说的是后者。 当然,最好的解决方案是在 API 中同时拥有两个版本,但如果您始终需要基于长度的版本,那么使用静态实用程序方法并不是那么可怕。

至于例外,是的,这绝对是很好的设计。 您要求特定的东西,当您无法获得该特定的东西时,API 不应该尝试猜测您可能想要什么 - 这样,错误会更快地变得明显。

另外,Java 确实有一个 另一种 substring() 方法,返回从起始索引到字符串末尾的子字符串。

I'm used to languages where
substring() (or substr()) takes two
parameters: a start position, and a
length. Is this objectively better
than the way Java does it, and if so,
can you prove it?

No, it's not objectively better. It all depends on the context in which you want to use it. If you want to extract a substring of a specific length, it's bad, but if you want to extract a substring that ends at, say, the first occurrence of "." in the string, it's better than if you first had to compute a length. The question is: which requirement is more common? I'd say the latter. Of course, the best solution would be to have both versions in the API, but if you need the length-based one all the time, using a static utility method isn't that horrible.

As for the exception, yeah, that's definitely good design. You asked for something specific, and when you can't get that specific thing, the API should not try to guess what you might have wanted instead - that way, bugs become apparent more quickly.

Also, Java DOES have an alternative substring() method that returns the substring from a start index until the end of the string.

嗫嚅 2024-07-29 09:02:38

第二个参数应该是可选的,第一个参数应该接受负值。

second parameter should be optional, first parameter should accept negative values..

假扮的天使 2024-07-29 09:02:38

如果您省略第二个参数,它将转到字符串的末尾,而无需您计算它。

If you leave off the 2nd parameter it will go to the end of the string for you without you having to compute it.

记忆消瘦 2024-07-29 09:02:38

得到一些反馈后,我发现第二个参数作为索引的场景何时有用,但到目前为止,所有这些场景似乎都在解决其他语言/API 限制。 例如,API 没有提供方便的例程来为我提供输入字符串中第一个冒号之前和之后的字符串,因此我获取该字符串的索引并调用 substring()。 (这解释了为什么 substr() 中的第二个位置参数超出了所需的索引 1,IMO。)

在我看来,通过语言工具包中更全面的字符串处理函数集,第二个参数作为-索引场景输给了第二个参数作为长度。 但有人请给我举一个反例。 :)

Having gotten some feedback, I see when the second-parameter-as-index scenario is useful, but so far all of those scenarios seem to be working around other language/API limitations. For example, the API doesn't provide a convenient routine to give me the Strings before and after the first colon in the input String, so instead I get that String's index and call substring(). (And this explains why the second position parameter in substr() overshoots the desired index by 1, IMO.)

It seems to me that with a more comprehensive set of string-processing functions in the language's toolkit, the second-parameter-as-index scenario loses out to second-parameter-as-length. But somebody please post me a counterexample. :)

眼泪淡了忧伤 2024-07-29 09:02:38

如果你把它收起来,这个问题就不会再困扰你的梦想了,你最终会睡个好觉:

public String skipsSubstring(String s, int index, int length) {
    return s.subString(index, index+length);
}

If you store this away, the problem should stop plaguing your dreams and you'll finally achieve a good night's rest:

public String skipsSubstring(String s, int index, int length) {
    return s.subString(index, index+length);
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文