Alfanümerik Karakter: Tanımı, Kripto Para Birimindeki Kullanımı, Güvenliği

Alfanümerik Karakter: Tanımı, Kripto Para Birimindeki Kullanımı, Güvenliği

Altmış iki. Birisi "yalnızca alfanümerik karakterler kullanın" dediğinde mevcut olan farklı sembollerin toplam sayısı bu. Yirmi altı büyük harf, yirmi altı küçük harf, on rakam. Büyük/küçük harf duyarlılığını kaldırırsak sayı otuz altıya düşer. Her iki sayı da önemlidir, çünkü şimdiye kadar yazdığınız neredeyse her dijital tanımlayıcı - bir cüzdan adresi, bir Wi-Fi şifresi, bir işlem özeti, bir GitHub belirteci - bu altmış iki sembolün seçilmiş bir alt kümesinden oluşturulmuştur.

Hangi alt kümenin seçileceği ve neden seçileceği, çoğu açıklayıcının atladığı kısımdır. Ayrıca, alfanümerik karakterin ansiklopedik tanımını kripto cüzdanınızın pratik güvenliğine bağlayan kısım da burasıdır. Bu makale, sayım işlemini, arkasındaki standardı, modern kriptografinin alt kümelerini nasıl seçtiğini ve ABD ulusal parola otoritesinin bu konuda şu anda ne söylediğini ele almaktadır. Bu kılavuzun bazı bölümleri, çoğu güvenlik tavsiyesinin henüz yetişemediği şekillerde değişmiştir.

Alfanümerik Karakter Nedir? Tanımı ve Sayısı

Tanımla başlayalım. Alfanümerik karakter, A-Z arasındaki herhangi bir harf (büyük/küçük harf fark etmeksizin) veya 0-9 arasındaki herhangi bir ondalık rakamdır. Hepsi bu kadar. Bundan sonrası aritmetik açık: Her büyük/küçük harf için yirmi altı harf artı on rakam, büyük/küçük harf duyarlılığıyla altmış iki farklı karakter, duyarlılık olmadan otuz altı farklı karakter verir. Bunun dışındaki her şey "özel"dir. Noktalama işaretleri, boşluklar, matematik sembolleri, aksanlı harfler, emojiler - bunların hiçbiri alfanümerik olarak sayılmaz.

Mühendisler genellikle bu tanımı iki kısaltmadan biriyle karşılarlar. Grep, sed ve awk gibi POSIX araçları, yukarıdaki altmış iki karakterle eşleşen `[:alnum:]` ifadesini tanır. Python, JavaScript, Java, PCRE gibi çoğu modern regex türü ise bunun yerine `\w` kullanır. `\w` ile ilgili sorun, alt çizgiyi araya sıkıştırmasıdır. Alt çizgi resmi olarak alfanümerik değildir. Çoğu programlama sözdizimi bunu onursal bir unsur olarak ele alır; bu nedenle Stripe anahtar öneki `sk_live_` ve AWS anahtar öneki `AKIA`, alt çizgileri ve büyük harfleri rakamlarla karıştırır ve kimse bunu sorun etmez.

Bu terim nereden geldi? Şaşırtıcı bir şekilde, delikli kartlardan. 1930'larda IBM'in hesaplama ekipmanları, harfleri rakamlarla karıştıran kodlar için tek bir kelimeye ihtiyaç duyuyordu ve "alfanümerik" kelimesi yerleşti. 1960'ların başlarındaki IBM 1401'e gelindiğinde, bu kelime iş dünyasındaki bilgisayar kullanımının standart bir parçası haline gelmişti. Bu ayrım pratikte de etkiliydi; "alfanümerik" olarak tanımlanan bir alan herhangi bir harf veya rakamı kabul ederken, yalnızca rakamlardan oluşan bir alan alfabeyi tamamen reddediyordu. Buradan sonra kelime, plakalara, IBAN banka kodlarına, telefon tuş takımı anımsatıcılarına, ürün SKU'larına ve yüzlerce başka yere yayıldı.

Büyük/küçük harf duyarlılığı ve duyarsızlığı arasındaki ayrım göründüğünden daha önemlidir. Büyük harflere izin verildiğinde parola entropisi iki katına çıkar. Bitcoin'in Base58 adresleri bilerek her iki büyük/küçük harf durumunu da korur. Bech32 ise bilerek büyük/küçük harf duyarlılığını ortadan kaldırır. Bu tercihlerden her biri, ifade gücü ve insan hatası arasında bir denge kurmayı gerektirir. Yanlış seçim yaparsanız, insanlar yazım hataları nedeniyle para kaybeder.

Alfanümerik Karakter

ASCII'den Unicode'a: Kısa Bir Teknik Tarihçe

"Alfanümerik" bugün, altmış yıl süren bir standartlar savaşının hayatta kalan örneğidir. Kullanıcıların çoğu bu savaşın ortasında kaldı ve farkına bile varmadı.

ASCII ilk olarak ortaya çıktı. 1963'te Amerikan Standartlar Birliği tarafından kullanıma sunuldu ve beş yıl sonra ANSI X3.4-1968 olarak resmileştirildi. Ardından iki revizyon daha yapıldı - biri 1977'de, diğeri 1986'da. 1968 sürümünde büyük harf A 65, küçük harf a 97 ve 0-9 rakamları 48 ile 57 arasında numaralandırıldı. Editörünüzü şimdi açın: 'A' baytı hala 65. Altmış yıldır hiçbir şey değişmedi.

Yaklaşık kırk yıl boyunca ASCII alfabetik ve sayısal karakter seti, alfabetik ve sayısal karakter seti olarak kaldı. Sonra küresel web geldi. Yedi bit artık yeterli değildi. Hatalar çok kötüydü. Bozuk e-postalar. Bozulmuş veritabanları. Tokyo'da mükemmel çalışan Japon web siteleri, ABD'deki bir dizüstü bilgisayarda soru işaretleri duvarı gibi görünüyordu. Unicode, 1991'de iddialı bir hedefle geldi: Herkesin yazdığı her yazı sistemindeki her karaktere benzersiz bir numara atamak. UTF-8, 1992'de Unicode'u sıradan ağlar üzerinden taşıyan kodlama olarak ortaya çıktı. Bunun püf noktası geriye dönük uyumluluktu; UTF-8'in ilk 128 kod noktası, tam olarak orijinal 1968 ASCII baytına karşılık geliyordu. 1991'den önce gönderilen İngilizce metinler sonsuza kadar çalışmaya devam etti.

Bu geçiş Aralık 2007'de gerçekleşti. O ay, kamuya açık web tarama istatistikleri nihayet UTF-8'in çevrimiçi en yaygın kodlama olarak ASCII'yi geride bıraktığını gösterdi. O zamandan itibaren "alfanümerik" terimi artık yalnızca altmış iki ASCII sembolünü ifade etmiyordu. Unicode artık Kiril, Yunanca, Arapça, İbranice ve CJK alfabeleri için alfanümerik blokları katalogluyor. Her alfabe kendi harfleri ve kendi rakamlarıyla birlikte geliyor.

Ancak pratikte, sınırları aşması gereken yazılımlar hala orijinal ASCII alt kümesini varsayılan olarak kullanıyor. Latin harfleri A-Z. Arap rakamları 0-9. Başka hiçbir şey yok. Bunun nedeni sıradan. Her klavye ASCII üretir. Her veritabanı bunu kabul eder. Her regex motoru bunu bilir. Bu aralığın dışına çıktığınızda, yanlış kodlama hataları, benzer karakterler ve aşağıda tekrar değineceğim kimlik avı saldırıları gibi sorunlarla karşılaşırsınız.

Sınıf Üyeler Saymak Regex kısaltması Örnek
Alfabetik A–Z, a–z 52 `[A-Za-z]` Sade İngilizce kelime
Sayısal 0–9 10 `[0-9]` veya `\d` Bir yıl, bir posta kodu
Alfanümerik A–Z, a–z, 0–9 62 `[A-Za-z0-9]` veya `[:alnum:]` API anahtarı, SKU
Özel / sembolik `!@#$%^&*()_+-=[]{};:'"\ ,.<>/?` ~33 (ASCII) `[^A-Za-z0-9]` Parola değiştirici

Kriptografide Alfanümerik Karakterler: Adresler, Hash'ler, Tohumlar

İşte çoğu genel açıklama metninin atladığı nokta: Kripto para sistemleri hiçbir zaman altmış iki karakterden oluşan tam alfanümerik karakter setini kullanmaz. Dikkatlice seçilmiş alt kümeleri tercih ederler. Her biri, keyfi bir estetik değil, belgelenmiş bir mühendislik uzlaşmasıdır.

Önce Bitcoin. Eski bir Bitcoin adresi (1 veya 3 ile başlayan) Base58 ile kodlanır. Alfabe, Satoshi Nakamoto tarafından elle tasarlanmıştır. Tarif: altmış iki karakterlik alfanümerik kümeyi alın, dört üyeyi silin. Sıfır rakamı, büyük O, büyük I, küçük l gider. Neden bu dört harf? Bunları kötü bir el yazısıyla bir Post-it'e yazın. Uzaklaşın. Beş dakika sonra geri gelin. Bunları birbirinden ayırt etmeye çalışın. Edemezsiniz. Base58'in çözmek için tasarlandığı sorun tam olarak budur. Geriye elli sekiz karakter kalır. Tipik bir eski adres, yirmi altı ila otuz beş sembol uzunluğunda olur; gerçekten gerekirse elle kopyalanabilecek kadar kısadır.

SegWit, Ağustos 2017'de aktif hale geldi. Bununla birlikte, BIP-173'te tanımlanan ikinci bir Bitcoin adres formatı olan Bech32 ortaya çıktı. Bech32 farklı bir yaklaşım benimsiyor. Büyük/küçük harf duyarlılığı tamamen ortadan kalkıyor; her adres küçük harfle yazılıyor. Dört farklı karakter atılıyor: 1 rakamı, artı b, i, o. Geriye kalan otuz iki harf ve rakam, yerleşik bir sağlama toplamı taşıyor. Sağlama toplamı, neredeyse her tek karakterlik yazım hatasını otomatik olarak yakalıyor. Kasım 2021'den beri aktif olan Taproot, araştırmacıların orijinal matematiksel hesaplamalarda bir köşe durumu hatası bulmasının ardından formatı Bech32m (BIP-350) olarak geliştirdi.

Ethereum üçüncü bir yol seçti. Sadece onaltılık sayı sistemini kullandı. Bir Ethereum adresi, `0x` ile başlayan ve ardından tam olarak kırk onaltılık karakterden oluşan, toplamda kırk iki karakterden oluşur. Onaltılık sayı sistemi, alfanümerik karakterleri on altı üyeye kadar daraltır. 0-9 rakamları, a-f harfleri, başka hiçbir şey yok. Bu seçim 2015'te temiz görünüyordu. Ancak 2026'da, kullanıcıların MetaMask'te ham onaltılık sayı bloklarına yıllarca gözlerini kısarak bakmalarının ardından, çirkin görünmeye başladı. EIP-55 çözüm oldu. Küçük harfli adresin Keccak-256 hash'inden türetilen bir kalıpta belirli harfleri seçici olarak büyük harfe dönüştürüyor. Sonuç, ücretsiz yazım hatası tespiti. EIP-55, yazım hatalarını yaklaşık %99,975 güvenilirlikle yakalıyor. Kaçırma oranı yaklaşık %0,0247. Küçük. Sıfır değil.

Hash'ler en basit örnektir. Bir SHA-256 hash çıktısı 256 bittir ve 64 onaltılık karakter olarak görüntülenir. Ethereum'un Keccak-256'sı da aynı uzunlukta çıktı üretir. Bir Bitcoin işlem kimliği (txid), işlemin kendisinin SHA-256 hash'idir, bu nedenle bir txid de 64 alfanümerik onaltılık karakterdir. Blok gezgininde göz korkutucu görünebilirler. Tamamen alfanümeriktirler.

Başlangıç kelime öbekleri kalıbı bozar. BIP-39 cüzdan kurtarma, kripto paranın alfanümerik yapıdan çıkıp tamamen alfabetik alana geri döndüğü tek yerdir. Standart, 128 veya 256 bit entropiyi, sabit 2.048 kelimelik bir listeden alınan on iki veya yirmi dört İngilizce kelime olarak kodlar. Her kelime yalnızca küçük harflerden oluşur; rakam yok, büyük ve küçük harf karışımı yok. Neden? Çünkü tasarım hedefi, telefonunun şarjı bittikten sonra gece 3'te kağıda kelimeler yazan bir kişidir ve rakamlar, harflerin yaratmadığı belirsizliği ortaya çıkarır.

Tanımlayıcı Karakter seti Uzunluk Örnek (kısaltılmış)
Bitcoin eski adresi Base58 (58 karakter, 0/O/I/l içermez) 26–35 `1A1zP1eP5QGefi2…`
Bitcoin Bech32 (SegWit) 32 küçük harf, 1/b/i/o yok ~42 `bc1qar0srrr7xfk…`
Ethereum adresi hex (0–9, a–f) + `0x` 42 `0xde0B295669a91…`
SHA-256 / txid altıgen 64 `e3b0c44298fc1c1…`
BIP-39 kelimesi yalnızca a–z Kelime başına 3-8 `yeteneği terk etmek mümkün...`

Her bir alt küme, son derece teknik bir sistemin içinde gizlenmiş, insan odaklı bir tasarım parçasıdır.

Alfanümerik Şifreler: NIST 2024'te Gerçekten Ne Diyor?

İnternetteki parola önerilerinin çoğu birkaç yıl öncesine ait. Büyük ve küçük harfleri bir arada kullanın, rakamlar ekleyin, en az bir özel karakter ekleyin, her doksan günde bir değiştirin — bu kurallar yirmi yıl boyunca geçerliydi. Amerika Birleşik Devletleri Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) bu kurallardan resmen vazgeçti.

Dijital kimlik rehberliği konusunda federal otorite olan NIST'in Özel Yayını 800-63B, Eylül 2024'te 4. Revizyonu tamamladı. Yeni rehber, ne kadar çok şeyi kaldırdığıyla dikkat çekiyor. Tek faktörlü kimlik doğrulama için minimum uzunluk önerisi on beş karaktere çıkarıldı. Karakter bileşimi kurallarına ilişkin talimat "yapılmamalıdır" şeklinde ifade edildi: hizmetler belirli karakter sınıflarını zorunlu tutmamalıdır. Herkesin nefret ettiği doksan günlük periyodik parola süresi de kaldırıldı. Bu kuralların yerine, NIST artık hizmetlerin gönderilen parolaları bilinen tehlikeye atılmış kimlik bilgilerinin bulunduğu bir kara listeye karşı taramasını şart koşuyor.

Bu değişim, entropi matematiğiyle gerekçelendirilebilir. 62 karakterlik alfanümerik bir havuz, karakter başına yaklaşık 5,95 bit üretir. Tam 95 karakterlik yazdırılabilir ASCII havuzu (alfanümerik ve özel karakterler dahil), 6,57 bit üretir. Özel karakterlerin tamamını eklemek, karakter başına 0,62 bit kazandırır. Uzunluğa bir karakter daha eklemek ise tam 5,95 bit kazandırır. Uzunluk, karmaşıklığı bir büyüklük mertebesinde domine eder.

Verizon'ın 2025 Veri İhlali Araştırma Raporu, kimlik bilgilerinin tüm onaylanmış ihlal giriş noktalarının %22'sini oluşturduğunu ortaya koydu. Kimlik bilgisi doldurma (sızdırılmış parola listelerinin otomatik olarak yeniden kullanılması), kimlik doğrulama girişimlerinin ortalama %19'unda gerçekleşiyor ve %44'e kadar çıkıyor. Kullanıcıların %49'u farklı hizmetlerde parolalarını yeniden kullanıyor. Bu sorunların hiçbiri büyük harf kullanımını zorunlu kılmakla çözülmüyor.

Özel karakter içermeyen daha uzun bir alfanümerik şifrenin kırılması, karmaşıklık kontrol listesini karşılamak için oluşturulmuş kısa bir şifreye göre daha zordur. Eğer bankanız hala sizden bir büyük harf, bir rakam ve bir özel karakter içeren on iki karakterli bir şifre oluşturmanızı istiyorsa, bu politika artık ABD federal standardıyla resmen uyumsuz hale gelmiştir.

Alfanümerik Karakterler Başka Nerelerde Görünür?

Kriptografi ve parolaların ötesine geçildiğinde bile, bir sistemin insanların yazabileceği ve bilgisayarların belirsizlik olmadan çözümleyebileceği bir tanımlayıcıya ihtiyaç duyduğu her yerde alfanümerik karakter dizileri hala karşımıza çıkmaktadır.

Banka kodları kolay bir örnektir. Bir IBAN, otuz dört alfanümerik karaktere kadar uzayabilir ve her zaman iki harfli bir ISO ülke koduyla başlar. SWIFT/BIC kodları sekiz veya on bir karakterden oluşur. Araç plakaları ülkeye göre değişir — bir İngiliz plakası bir Alman plakasına hiç benzemez — ancak her ikisi de aynı altmış iki sembol havuzunun alfanümerik alt kümeleridir. Araç Kimlik Numaraları (VIN) dünya çapında tam olarak on yedi karakterdir ve VIN'lerde I, O ve Q harfleri, rakamlardan görsel olarak ayırt edilebilmeleri için kasıtlı olarak yasaklanmıştır.

API anahtarları, çoğu kullanıcının bakmaya zahmet etmediği günlük örneklerdir. Bir Stripe canlı anahtarı, `sk_live_` ve ardından alfanümerik bir belirteçle açılır. Bir AWS erişim anahtarı, `AKIA` ve ardından on altı alfanümerik karakterle açılır. 2021'den sonra verilen bir GitHub kişisel erişim belirteci, `ghp_` ile açılır. Bu önekler de alfanümeriktir ve sağlayıcıların sızdırılmış anahtarlar için genel depoları ve günlükleri tarayabilmesi için seçilmiştir. Çoğu durumda, bu tarama, herhangi bir saldırgan yapmadan önce bir hatayı yakalar.

QR kodlarından kısaca bahsetmek gerekir. ISO/IEC 18004 standardı, büyük harfler, rakamlar, boşluk ve birkaç noktalama işaretinden oluşan belirli bir 45 karakterlik kümeyi genel bayt modundan daha verimli bir şekilde kodlayan özel bir "alfanümerik mod" tanımlar. Yalnızca büyük harfli alfanümerik içerik içeren bir QR kodu, aynı içeriğin ham bayt olarak kodlanmasına kıyasla kare başına yaklaşık 1,6 kat daha fazla veri depolar.

Base32, Base58, Base64: Crypto Bir Alt Küme Seçtiğinde

İkili sayıları alfanümerik bir alt kümeye dönüştürmek için özel olarak tasarlanmış birkaç kodlama standardı mevcuttur. Referans olarak, IETF tarafından 2006 yılında yayınlanan RFC 4648 gösterilebilir. Bu standart üç kodlama tanımlar.

Hex, bunların en basiti. Resmi adı Base16. On altı karakter: 0–9, a–f. Ethereum adreslerinde, kriptografik hash'lerde ve ham baytları okumanız gereken hemen hemen her düşük seviyeli hata ayıklama işleminde kullanılır. Base32 ise daha ilginç olanı. 32 karakterlik alfabe, büyük/küçük harf duyarlılığı olmaması ve bazı varyantlarda görsel olarak karıştırılabilecek 0, 1, 8 ve 9 rakamlarını atması için seçildi. İki faktörlü kimlik doğrulamayı ayarlayan ve Google Authenticator'a bir gizli anahtar giren herkes Base32 yazmıştır - çoğu zaman farkında olmadan.

Base64, en çok kullanılan şifreleme yöntemidir. Altmış iki alfanümerik karakter ve `+` ile `/` sembollerinden oluşur. URL güvenli bir varyantı ise bu sembolleri `-` ve `_` ile değiştirir. Base64, e-posta eklerinizi taşır, HTML içindeki veri URL'lerini kodlar ve OAuth için JSON Web Token'larını paketler.

Bitcoin'in Base58'i RFC 4648'in dışında yer almaktadır. Satoshi Nakamoto bunu bağımsız olarak geliştirdi. Hedef farklıydı - karakter başına bayt verimliliği değil, insanların adresleri yeniden yazması - ve sonuç, başka hiç kimsenin kullanmadığı özel bir alfabe oldu. Bazen Ascii85 olarak da adlandırılan Base85, tam tersi yönde çalışır. Dört baytı beş karaktere sıkıştırır ve PDF ve PostScript dosyalarında görünür; burada ekstra yoğunluk, okunabilirlik kaybını haklı çıkarır.

Alfanümerik Karakter

Sık Karşılaşılan Hatalar: Görsel Karışıklık ve Benzerlikler

Kripto paraların alfanümerik alt kümeleri seçmesinin nedenleri, herkesin hata yapmasının nedenleriyle aynıdır. Birkaç karakter çifti sorunların çoğuna neden olur.

Klasik karıştırılabilir harfler: sıfır ve büyük O. Bir rakamı, küçük l, büyük I. Küçük l ve büyük I. Bitcoin Base58 bu nedenle dördünü de atlıyor. Diğer sistemler farklı önlemler kullanıyor — VIN'ler I, O ve Q'yu atıyor, bazı finansal kodlar O'yu tamamen atıyor ve ülkenin yazı tipinde 0'a en çok benzeyen harfi yasaklayan ulusal plaka kuralları bulabilirsiniz.

Daha karmaşık ve yeni bir sorun ise Unicode homograf saldırılarıdır. Bu fikir, Evgeniy Gabrilovich ve Alex Gontmakher tarafından 2001 yılında yayınlanan bir makalede belgelenmiştir. Homograf, farklı bir yazı sisteminden görsel olarak özdeş bir karakterin değiştirilmesidir; örneğin, Latin alfabesindeki 'a' (U+0061) yerine Kiril alfabesindeki 'а' (U+0430). Bu ikame ile bir alan adı kaydederseniz, gerçek bankadan ayırt edilemeyen bir kimlik avı sayfası barındırabilirsiniz. Modern tarayıcılar, bir alan adı farklı yazı sistemlerini karıştırdığında ham Punycode gösterimini (örneğin `xn--80akhbyknj4f` gibi) görüntüler. Bu savunma çoğu saldırıyı yakalar. Ancak hepsini değil.

2026'te Güçlü Alfanümerik Şifre Nasıl Oluşturulur

Üç kural. Hepsi de doğrudan NIST matematiğinden türetilmiştir.

Birincisi: uzunluk, karakter sınıfından daha önemlidir. On altı karakter veya daha fazlasını hedefleyin. Bu kural, sistemin yalnızca harf ve rakamları mı yoksa yazdırılabilir tüm ASCII kümesini mi kabul ettiğine bakılmaksızın geçerlidir.

İki: Eğer ezberlemeniz gerekiyorsa, bir parola kullanın. Geniş bir listeden rastgele seçilmiş dört kelime (Diceware listesi en iyi seçenektir) bir insanın oturup uyduracağı neredeyse her kısa paroladan daha iyi performans gösterir.

Üçüncüsü: geri kalan her şey için bir parola yöneticisi kullanın. Yöneticinin, asla elle okumanız veya yazmanız gerekmeyecek uzun alfanümerik dizeler oluşturmasına izin verin. Bir yönetici çıktıyı işledikten sonra, çıktının okunabilirliği artık hiç önem taşımaz.

Hızlı Referans: Alfanümerik Sayılar ve Örnekler

Büyük/küçük harf duyarlılığıyla altmış iki. Büyük/küçük harf duyarlılığı olmadan otuz altı. Rakamlar için ASCII kodları 48–57. Büyük harfler için 65–90. Küçük harfler için 97–122. Tüm kümeyi `[A-Za-z0-9]` regex'i veya `[:alnum:]` POSIX sınıfı ile eşleştirin. Bu altmış iki sembollük havuz, bu hafta dokunacağınız neredeyse her dijital tanımlayıcının temelini oluşturuyor. Şifreler. API anahtarları. IBAN'lar. Plaka numaraları. İşlem kimlikleri. Oluşturduğunuz her cüzdan adresi.

Sorusu olan?

Çünkü Satoshi Nakamoto oturup yaygın yazı tiplerinde görsel olarak birbiriyle çakışan her karakteri sildi. Sıfır, büyük O harfiyle çakışır. Küçük l harfi, büyük I harfiyle çakışır. Bir Bitcoin kullanıcısının kağıt yedeklemeden adresini yeniden yazması kafa karışıklığına yol açar. Bu karışıklık insanlara gerçek para kaybettirir. Bu dört sorunlu karakteri ortadan kaldırırsanız, yazım hatası oranı düşer.

Hayır. Noktalama işaretleri, matematik sembolleri, para birimi işaretleri, boşluklar – harf veya rakam olmayan her şey alfanümerik kümenin dışında yer alır. Bunları bir şifreye ekleyebilir ve her karakter için bir miktar entropi kazanabilirsiniz. Tek bir ekstra karakter eklemek genellikle size önemli ölçüde daha fazla kazandırır.

Harf ve rakamlardan oluşan, sembol içermeyen bir parola. Eylül 2024’te yayınlanan NIST SP 800-63B Rev 4, mevcut revizyonunda özel karakterler istemeyi bıraktı. Genel tavsiye, en az on beş karakter artı bilinen ihlal edilmiş kimlik bilgilerine karşı bir kara liste kontrolüdür. Çoğu kurumsal parola politikası bu kılavuzun birkaç yıl gerisindedir.

Evet, ancak hiçbir zaman tüm küme değil. Eski Bitcoin adresleri, 0, O, I ve l harflerini kaldıran Base58 kullanır. Bech32 SegWit adresleri ise 1, b, i ve o harflerini kaldıran otuz iki karakterlik küçük harf alt kümesi kullanır. Her iki seçimin ardındaki mantık aynıdır: İnsanlar benzer karakterleri yeniden yazarken karıştırır ve karışıklık nedeniyle yeniden yazanlar para kaybeder.

Hayır. Boşluk, tamamen ayrı bir kategori olan whitespace sınıfında yer alır. Herhangi bir testi çalıştırın — POSIX `[:alnum:]`, regex `[A-Za-z0-9]`, Python’ın `isalnum()`’u, JavaScript regex `\w` — ve bunların hepsi boşlukları, sekmeleri ve yeni satırları reddeder.

Büyük/küçük harf duyarlılığı önemliyse altmış iki. Yirmi altı büyük harf, yirmi altı küçük harf, on rakam. Büyük/küçük harf duyarlılığını kapatırsanız otuz altı ile çalışırsınız. Bu ayrım, 1968 ASCII standardına kadar uzanıyor ve o zamandan beri değişmedi.

Ready to Get Started?

Create an account and start accepting payments – no contracts or KYC required. Or, contact us to design a custom package for your business.

Make first step

Always know what you pay

Integrated per-transaction pricing with no hidden fees

Start your integration

Set up Plisio swiftly in just 10 minutes.