単に128bitバイナリのASCIIエンコーディングと違うの。
絵文字にしたらかわいいと思う
見た目の良し悪しは主観だけど、URLに使用することを考慮するだけならBase64URLにするかな。
UUIDを視認して使う必要があるシーンってある？
Base58なんてあるのね。へぇ。自分も(視認性の高い)ランダムパスワード生成C#コードをLINQPadで組んで使ってるので文字種数えてみたら52文字だった。 234789ACEFHJKLMNPRSTUVWXYZacdefghkmnprstuvwxyz#%=@*+
初めからUUIDを使わずそのように振り出してしまえば良いのでは、と少し思ってしまったやつ。
なるほど、IT系だと妙なところで文字数制限に引っかかる場合もあるから役に立つ場面ありそう
ULIDじゃ駄目なん？ULIDは人間の目で見て紛らわしい文字を除外した特殊なBase32でエンコードされる
36 文字が 22 文字になったところで「短くてスッキリ」なんて思わないな。
よほどのことが無い限り要件側を調整したいなぁ...採用する仕様としてカジュアルに規格を弄ぶことのリスクはデカい（使用するライブラリが限定されたり、不整合が起きないかチェックしなければならなかったり...）
世の中のほぼ全てのケースで UUID はオーバースペックなので、DB のキーはともかく、URL に表出するのは UUID のうち32bit分くらいで実用上十分では？git のハッシュだって省略表記で困った事ないでしょ？
生成された文字列をデコードする必要は滅多にないはず（あるとすればタイムスタンプを見たい場合位？）だし、他の言語でも簡単に実装可能なのでアリだと思う。有効性検査が必要なら1文字足してチェックサム付ければ
DBにはバイナリで保存される。文字列にするとデフォルトでは16進数、つまりBase16。BaseXXを大きくすれば短くなる。この人は視認性の良いBase58を採用したという話。
RDBだともっと短い桁数で保存されてるよね。推測されにくいURL用ってことなのかな？
Base64だとURL Unsafeなので Base64 URL EncodeしてたがBase58でいいのか。覚えておこう。
一瞬なに言いだしたのかと思ったが、情報量を減らすんじゃなく表現形式の無駄を削ったのね。36字固定→22字程度と。
『Base58』
人がハンドコピーするとかでなければbase64urlのほうがよさそうな。
Base64URLというのがあるのかー
これをbase32でやったULIDがすでに定着してるのに
DBではUUIDv4をidとして使っているけれど、URLにそのままUUIDv4を使いたくなかった。そのため今回のを作成した理解で良いのかな？
発想がいいなあ。
UUIDの形式にこだわらないのであれば暗号論的疑似乱数を直接Base58あるいはBase64URLに変換すればよいのに
手打ちすることがないのなら、Base64URLで十分なような……/それに、入力はプログラムから渡すんだから、不正な文字が入ることもなくない?
個人的にはnanoidの方が無難かな https://github.com/ai/nanoid
“WebサービスやAPIで使われるUUIDは、ハイフン込みで36文字と長くてURL埋め込むに不向き。Base64は/+=などURLで不向き。Base58（視認性の悪い文字を除外したアルファベット）でエンコードすると22文字程度、短く使いやすい”
ULIDじゃだめかな。ソートもできるし。
NanoIDでよくない?の気持ちになった()
👀
https://www.npmjs.com/package/short-uuid
UUIDをBitcoinでも使われているBase58でエンコード
Base58, Base64URLとどう違うんだろって思ったけど、視認性の低い紛らわしい文字を除外してるんだ。ユニークIDの視認性が低い問題って何だろ。既存データの調査するときに目が滑るとかかな。
UUIDを短くするライブラリを作った
単に128bitバイナリのASCIIエンコーディングと違うの。
絵文字にしたらかわいいと思う
見た目の良し悪しは主観だけど、URLに使用することを考慮するだけならBase64URLにするかな。
UUIDを視認して使う必要があるシーンってある？
Base58なんてあるのね。へぇ。自分も(視認性の高い)ランダムパスワード生成C#コードをLINQPadで組んで使ってるので文字種数えてみたら52文字だった。 234789ACEFHJKLMNPRSTUVWXYZacdefghkmnprstuvwxyz#%=@*+
初めからUUIDを使わずそのように振り出してしまえば良いのでは、と少し思ってしまったやつ。
なるほど、IT系だと妙なところで文字数制限に引っかかる場合もあるから役に立つ場面ありそう
ULIDじゃ駄目なん？ULIDは人間の目で見て紛らわしい文字を除外した特殊なBase32でエンコードされる
36 文字が 22 文字になったところで「短くてスッキリ」なんて思わないな。
よほどのことが無い限り要件側を調整したいなぁ...採用する仕様としてカジュアルに規格を弄ぶことのリスクはデカい（使用するライブラリが限定されたり、不整合が起きないかチェックしなければならなかったり...）
世の中のほぼ全てのケースで UUID はオーバースペックなので、DB のキーはともかく、URL に表出するのは UUID のうち32bit分くらいで実用上十分では？git のハッシュだって省略表記で困った事ないでしょ？
生成された文字列をデコードする必要は滅多にないはず（あるとすればタイムスタンプを見たい場合位？）だし、他の言語でも簡単に実装可能なのでアリだと思う。有効性検査が必要なら1文字足してチェックサム付ければ
DBにはバイナリで保存される。文字列にするとデフォルトでは16進数、つまりBase16。BaseXXを大きくすれば短くなる。この人は視認性の良いBase58を採用したという話。
RDBだともっと短い桁数で保存されてるよね。推測されにくいURL用ってことなのかな？
Base64だとURL Unsafeなので Base64 URL EncodeしてたがBase58でいいのか。覚えておこう。
一瞬なに言いだしたのかと思ったが、情報量を減らすんじゃなく表現形式の無駄を削ったのね。36字固定→22字程度と。
『Base58』
人がハンドコピーするとかでなければbase64urlのほうがよさそうな。
Base64URLというのがあるのかー
これをbase32でやったULIDがすでに定着してるのに
DBではUUIDv4をidとして使っているけれど、URLにそのままUUIDv4を使いたくなかった。そのため今回のを作成した理解で良いのかな？
発想がいいなあ。
UUIDの形式にこだわらないのであれば暗号論的疑似乱数を直接Base58あるいはBase64URLに変換すればよいのに
手打ちすることがないのなら、Base64URLで十分なような……/それに、入力はプログラムから渡すんだから、不正な文字が入ることもなくない?
個人的にはnanoidの方が無難かな https://github.com/ai/nanoid
“WebサービスやAPIで使われるUUIDは、ハイフン込みで36文字と長くてURL埋め込むに不向き。Base64は/+=などURLで不向き。Base58（視認性の悪い文字を除外したアルファベット）でエンコードすると22文字程度、短く使いやすい”
ULIDじゃだめかな。ソートもできるし。
NanoIDでよくない?の気持ちになった()
👀
https://www.npmjs.com/package/short-uuid
UUIDをBitcoinでも使われているBase58でエンコード
Base58, Base64URLとどう違うんだろって思ったけど、視認性の低い紛らわしい文字を除外してるんだ。ユニークIDの視認性が低い問題って何だろ。既存データの調査するときに目が滑るとかかな。