CheckNumber.AI · 6 min read
API Serileştirmesinde Telefon Numarası Dizeleri: Her Basamağı Koruyun
Telefon değerlerini alımdan toplu dışa aktarmaya kadar dize olarak korumaya yönelik bir geliştirici test planı.
API serileştirmesindeki telefon numarası dizeleri, veri alımından JSON’a, depolamaya ve dışa aktarmaya kadar metin olarak kalmalıdır. Bir telefon değeri hesaplanacak bir miktar değil, bir tanımlayıcıdır; bu nedenle sayısal dönüşüm baştaki sıfırı, artı işaretini veya anlamlı alt basamakları kaybettirebilir. Toplu gönderimden önce, orijinal telefon metnini nihai makine tarafından okunabilir değerle karşılaştıran ve açıklanamayan her türlü değişikliği işaretleyen bir gidiş-dönüş (round-trip) test düzeneği kullanın.
Telefon numarası dizeleri bir API iş akışında neden önemlidir
Bir geliştirici, tamamen basamaklarla dolu bir alan görüp alışkanlıkla sayısal bir tür seçebilir. Alan bir tanımlayıcı olduğu için bu risklidir. Aritmetik anlamlı değildir ve bir sayıya dönüştürmek baştaki sıfırı kaldırabilir veya baştaki artı işaretini reddedebilir. JavaScript’in belirli bir duyarlık sınırı vardır: MDN’s Number reference, güvenli aralığının ötesindeki tam sayıların JSON’dan Number değerlerine ayrıştırılırken bozulabileceğini açıklamaktadır. Google’ın libphonenumber FAQ sayfası, JavaScript sayı duyarlığı nedeniyle en küçük basamakların değiştiği bir telefon ayrıştırma vakasını belgelemektedir.
Daha kısa değerler bile veri işleme sırasında değişebilir. Bir CRM alanı ülke kodunu atlayabilir, yerel bir numara anlamlı bir baştaki sıfıra sahip olabilir ve bir elektronik tablo yuvarlanmış bir değer görüntüleyebilir. Geliştirici için değişmez kural “tüm girdiler geçerli telefon numaralarıdır” değildir. Kural, “uygulama hangi metni aldığını ve daha sonra hangi metni gönderdiğini belirleyebilir” şeklindedir. Doğrulama ve normalleştirme, her değişiklik ayrı ayrı kaydedilerek daha sonra gelebilir.
Bu makale, bir CheckNumber toplu iş akışından önceki müşteri veri işlem hattını ele almaktadır. CheckNumber, CSV veya TXT yüklemesi ve REST API erişimi aracılığıyla desteklenen telefon numarası listelerinin toplu kontrolünü destekler. Belgelenmiş ürün yetenekleri, hizmetin müşterinin JSON’unda veya veritabanında zaten bozulmuş olan bir numarayı onardığı anlamına gelmez.
Değeri her sınır boyunca izleyin
Bir telefon değerinin izlediği yolu yazın: potansiyel müşteri formu veya kaynak dosya, uygulama isteği, JSON ayrıştırma, veritabanı sütunu, uygulama okuma, dışa aktarma dönüştürmesi, nihai CSV veya TXT baytları ve toplu gönderim. Her adımda veri türünü ve herhangi bir biçimlendirme işlevinin karakterleri değiştirip değiştiremeyeceğini belirleyin. Kullanıcı arayüzündeki bir görüntüleme etiketi yeterli değildir; önemli olan altta yatan depolanan metin ve nihai dışa aktarmadır.
Orijinal metni ve ayrı bir hazırlanmış değeri saklayın. Ülkeye duyarlı bir normalleştirme adımı noktalama işaretlerini değiştirirse veya onaylanmış bir ülke kodu eklerse, hazırlanmış değer meşru şekilde farklılık gösterebilir; ancak orijinal değer karşılaştırma için kullanılabilir kalmalıdır. Bir dönüştürmede hata ayıklarken kaynak değerin tek kopyasının üzerine yazmayın. Bir numara üst akıştaki sayısal bir alandan geldiğinde zaten yuvarlanmışsa, bu yuvarlanmış değeri bir dizeye dönüştürmek kayıp basamakları geri getiremez. Eksik karakterler uydurmak yerine yetkili kaynağa geri dönün.
ITU-T E.164 recommendation, uluslararası numaralandırma planını açıklamaktadır. CheckNumber’ın ücretsiz panel Numara Temizleyicisi, ücretli bir kontrolden önce telefon numaralarını E.164 standardına normalleştirebilir, mükerrer ve geçersiz girişleri kaldırabilir. Bu hazırlık, geliştiricinin kaynak metni koruma yükümlülüğünden ayrıdır. Ülkeye duyarlı normalleştirme, toplu bir dosya oluşturulmadan önce bilinen ülke bağlamına göre incelenmelidir.
Bir ürün şeması varsaymadan bir geliştirici gidiş-dönüş test düzeneği oluşturun
Kararlı bir test kaydı kimliği (ID), orijinal telefon dizesi, onaylanmış ülke ve beklenen hazırlanmış dize içeren müşteri tarafı bir test düzeneği oluşturun. Birkaç yapay vaka hazırlayın: baştaki artı işaretine sahip bir değer, baştaki sıfıra sahip yerel bir değer, sayısal duyarlık hatalarını ortaya çıkarmak için seçilmiş uzun bir basamak dizesi, ayırıcılara sahip bir değer ve iki ayrı kayıt kimliğiyle ilişkili yinelenen bir değer. Ekibin kendi ortamında ayrılmış veya iletişim kurulmayan test değerleri kullanın ve bunları yapay olarak etiketleyin. Bu test düzeneği serileştirmeyi ve eşlemeyi test eder; herhangi bir test değerinin gerçek, geçerli veya kayıtlı bir numara olduğunu iddia etmez.
Her vaka için müşteri uygulamasında şu yolu doğrulayın: yakalanan alan metindir; JSON gösterimi dize olarak kalır; veritabanı gidiş-dönüşü birebir aynı orijinal karakterleri döndürür; ve nihai dışa aktarma amaçlanan hazırlanmış metni içerir. Normalleştirme işlem hattının bir parçasıysa, çıktısını ayrı olarak gözden geçirilmiş bir beklentiyle karşılaştırın ve orijinal dizeyi saklayın. Bir basamak sayısı denetimi ve karakter karakter karşılaştırma, görsel bir elektronik tablo önizlemesinin gizlediği bir dönüşümü yakalayabilir.
İki kayıt kimliği arasında paylaşılan bir numara için bir test ekleyin. Dışa aktarma bir arama girdisini tekilleştirebilir, ancak müşteri tarafındaki eşleme, nihai numara düzeyindeki gözlemi her iki kaynak kayıtla da bağlamalıdır. Seçilen ürünün geçerli sözleşmesinde belirtilmediği sürece, bir denetleyici dışa aktarımının özel kimlikleri veya kaynak sırasını koruduğunu varsaymayın. Test düzeneği, bir API isteği veya bir denetleyici yanıt örneği uydurmadan müşterinin eşleme sürecini sınamalıdır.
Nihai dışa aktarımı bir elektronik tablo görünümü olarak değil, veri olarak inceleyin
Elektronik tablo yazılımında açılan bir CSV, görüntüleme amacıyla yeniden biçimlendirilebilir. Nihai dosya gönderilmeden önce makine tarafından okunabilir metin olarak incelenmelidir. Her telefon satırındaki tam karakterleri, özellikle artı işaretini, baştaki sıfırları, ülke kodunu ve son basamakları doğrulayın. Dışa aktarım bir veritabanı sorgusundan oluşturuluyorsa, aynı test kimlikleri altında depolanan orijinal ve hazırlanmış değerlerle bir satır örneğini karşılaştırın.
CheckNumber telefon listesi yüklemeleri için, dosya başına bir ülke ve ülke koduyla birlikte satır başına bir numara kullanın; baştaki artı işareti isteğe bağlıdır. Desteklenen yüklemelerde CSV veya TXT kullanılır. Bu yükleme kuralları, belgelenmemiş bir REST istek biçimine körü körüne kopyalanmamalıdır. Geliştiriciler, seçilen desteklenen ürün için güncel API belgelerini kullanmalı ve uygulamadan önce gerçek arayüzünü ve sınırlarını teyit etmelidir.
Eksik ülke kanıtı veya açıklanamayan basamak değişiklikleri içeren kayıtları, müşteri tarafından yönetilen bir inceleme kuyruğunda bekletin. Yanlış numarayı içeren temiz bir dışa aktarma, açık bir istisnadan daha kötüdür; çünkü kontrol tamamlanabilirken sonuç yanlış kaynak kayda atfedilebilir. İstisna nedenini ve kaynak kimliğini saklayın, böylece üst akış veri sahibi bunu düzeltebilir.
Korumayı bir sürüm koşulu haline getirin
Kod bir ayrıştırıcıyı, JSON modelini, veritabanı türünü, içe aktarma eşlemesini veya dosya dışa aktarıcısını her değiştirdiğinde gidiş-dönüş test düzeneğini çalıştırın. Yalnızca uygulamanın hatasız tamamlandığını kontrol etmek yerine, orijinal ve hazırlanmış değerleri sabit sınırlarda karşılaştırın. Açıklanamayan bir karakter kaybolduğunda, göründüğünde veya konum değiştirdiğinde test başarısız olmalıdır. Ayrıca, nihai olarak dışa aktarılan bir satır amaçlanan kaynak kayıtla birleştirilemediğinde de başarısız olmalıdır.
Üretim listeleri için kaynak satırları, benzersiz hazırlanmış numaraları, bekletilen istisnaları, gönderilen satırları ve daha sonra eşleşen sonuçları mutabık kılın. Bunlar müşteri tarafı denetim sayılarıdır, beklenen denetleyici performans rakamları değildir. Bir uyumsuzluk, bırakılan satırları veya eşlemeyi kaybeden tekilleştirmeyi ortaya çıkarabilir. Daha sonraki soru belgelenmiş bir geçerlilik sinyaliyle ilgili olduğunda, ayrı bir adım olarak Telefon Numarası Denetleyicisi ürününü inceleyin. Denetleyiciye özel sonuçlar, müşteri kontrollü inceleme ve segmentasyon için dışa aktarılabilir; ancak bunların yorumlanması, girdi hazırlığından sonra seçilen belirtilen ürüne bağlıdır.
Temel geliştirme kuralı basittir: tanımlayıcıları metin olarak koruyun, normalleştirmeyi açık hale getirin ve toplu iş akışına giren nihai baytları doğrulayın. Bu, serileştirmenin tek başına numara geçerliliği, sahiplik veya platform kaydı sağladığını iddia etmeksizin sonraki bir kontrolün anlamını korur.
SSS
Geliştiriciler JSON’da telefon basamaklarının değişmesini nasıl önleyebilir?
Değeri baştan sona dize olarak tutun ve ayrıştırma, depolama ve dışa aktarma boyunca bir gidiş-dönüş testi yapın. Sayısal bir dönüştürme anlamlı karakterleri veya duyarlığı kaybettirebilir.
Yuvarlanmış bir sayıyı tekrar metne dönüştürmek kayıp basamakları geri getirebilir mi?
Hayır. Değer uygulamaya ulaşmadan önce zaten değiştirilmişse yetkili kaynak kontrol edilmelidir.
Bir telefon dizesi test düzeneği neleri içermelidir?
Baştaki artı işaretleri, baştaki sıfırlar, uzun basamak dizeleri, ayırıcılar ve farklı kaynak kimlikleriyle eşlenmiş mükerrer değerler için yapay vakalar kullanın; ardından nihai dışa aktarımı gözden geçirilmiş beklentilerle karşılaştırın.
Geliştiriciler CheckNumber API girdi biçimini nerede bulabilir?
Seçilen desteklenen toplu ürün için güncel API belgelerine başvurun. Bu makale, bir API istek şemasından ziyade müşteri tarafındaki bir koruma testini açıklamaktadır.
