Can {searchTerms} Use Spaces Instead of +?

[Foreeps]

Hello,

I've run into a search engine that treats "two+words" as a single term. While all the rest I've seen are happy with '+' deliminating the terms the way {searchTerms} does it normally, is there a way to modify it to use spaces instead, or an alternative {spaceTerms} parameter or something?

Thank you!

[dewitt]

It's in interesting question, and I can't recall whether the use of '+' has been discussed before. The only thing the spec says is that "The value must be URL-encoded." As such, perhaps try %20 for that search engine and see what happens?

[Foreeps]

That's what I was asking - how can I get {searchTerms} to use spaces, %20, instead of +?

Or do you mean typing "%20" in my search instead of spaces? That isn't a very user-friendly solution, and it doesn't actually work: a search for "two%20words" literally searches for that, converting it in the address bar to "test%2520words".

[Standard8]

That's what I was asking - how can I get {searchTerms} to use spaces, %20, instead of +?

Assuming what you're trying to do is to create an OpenSearch definition for a search engine, then the encoding of the URL is decided by the application that's processing that definition.

If {searchTerms} is within the actual URL, rather than the query, then it must be URL encoded, i.e. using %20.

If {searchTerms} is within the query part of the URL, then it can be encoded using application/x-www-form-urlencoded which allows for using + instead of %20.

From my experience, most search engines allow either, but it might be a bug in the engine itself. Is the engine visible publicly?

[V1j2t3]

Yes

[Foreeps]

Sorry to drop off the planet!

I was trying to build a search widget for zLibrary on https://mycroftproject.com/ like I have for a couple other websites. The search URL worked out to be https://z-lib.fm/s/{searchTerms}/, but using it would create the address https://z-lib.fm/s/test+search/, which would search for the literal test+search, while other search engines I made widgets for would parse the same thing as test search.

At some point between then and now it started working correctly, where the widget would return https://z-lib.fm/s/test search/. I suppose someone must have found the problem and fixed it, though I didn't do anything like update or create a new widget - I don't know anything about the programming chain, would a Firefox update possibly include embedding a new OpenSearch version?

Anyways, wherever the fix happened, this ticket is still open. I think it's solved, but I'll let you decide whether or not to close it, since I don't know what fixed it.

Incidentally, manually entering https://z-lib.fm/s/test+search/ into my browser still searches for the literal as a single word, if you wanted to see what I had been experiencing.