It's unclear why the API in general converts from the internally-stored base-36 representation to base-16, except maybe because people usually use base-16 for hashes so it's less likely to be surprising. The first addition of a "sha1" parameter in the API appears to be gerrit 25456.
Version: 1.25-git
Severity: enhancement
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add prop=sha1base36 to many api modules | mediawiki/core | master | +38 -20 |
The title, as stated, makes this a WORKSFORME because it already returns the field.
Comment 0 makes it clear that it's just not encoded in the specific way you'd like. Why should we either break existing clients expecting the base-16 representation or bloat the API with an ability to select between base-16 and base-36?
the file sha1 (in imageinfo or allimages) is also converted before outputting, when than should all modules with hash processing should have prop=sha1base36 along with prop=sha1 to allow this. (For input in allimages there are two params).
I don't really mind bloating the API, but maybe better documentation would suffice to avoid confusion.
It sounds like there's a two-step process going on to arrive at the final sha1:
wfBaseConvert( sha1( $text ), 16, 36, 31 );
wfBaseConvert( $revision->getSha1(), 36, 16, 40 );
What would be the parameters to wfBaseConvert if one wanted to do this in one step? Thanks.
(In reply to Nathan Larson from comment #4)
I don't really mind bloating the API
I do. Without a good reason, there's little point in returning data in two different formats when it can easily be converted client-side.
It sounds like there's a two-step process going on to arrive at the final
sha1:wfBaseConvert( sha1( $text ), 16, 36, 31 );
wfBaseConvert( $revision->getSha1(), 36, 16, 40 );What would be the parameters to wfBaseConvert if one wanted to do this in
one step? Thanks.
I note that $revision->getSha1() is returning the value returned by the first line, so the above is more correctly stated as:
$stored = wfBaseConvert( sha1( $text ), 16, 36, 31 );
$output = wfBaseConvert( $stored, 36, 16, 40 );
The two wfBaseConvert calls are undoing each other. The one-step process would be:
$output = sha1( $text );
Or if you really want to use wfBaseConvert for some reason,
$output = wfBaseConvert( sha1( $text ), 16, 16, 40 );
(it turns out that both wfBaseConvert() and sha1() output lowercase hexits, so we don't need to worry about even that potential difference).
Change 175852 had a related patch set uploaded (by Umherirrender):
Add prop=sha1base36 to many api modules
Change 175852 abandoned by Umherirrender:
Add prop=sha1base36 to many api modules
Reason:
Just a show case