unicode

This is a follow up from my previous post: The power and expressiveness of Swift ranges. For a Character Range: contain works fine let numericalRange = 1...10 numericalRange.contains(8) // true let a: Character = "a" let z: Character = "z" let alphabeticalRange = a...z alphabeticalRange.contains("k") // true for-loop and count don’t work print(numericalRange.count) // 10 print(alphabeticalRange.count) // ❌ Referencing property 'count' on 'ClosedRange' requires that 'Character' conform to 'Strideable' for num in numericalRange { print(num) // 1 2 3 4 5 6 7 8 9 10 } for char in alphabeticalRange { // ❌ Referencing instance method 'next()' on 'ClosedRange' requires that 'Character' conform to 'Strideable' print(char) } What both of those errors mean is that Swift can’t figure out what the next character is for a given character....

This post is the result of some post-discussion on my Swift Strings for iOS interviewing post. Given that characters look like one another or that are invisible code points I thought there might be some room for abuse. Luckily Unicode has great documentation security. At the high level there are two types of security issues: Visual Security Issues Suppose that the user gets an email notification about an apparent problem in their Citibank account....

This is bit of fast paced intro into Swift Strings. ASCII, Unicode and the challenges they introduce. ASCII Ages ago, only characters that existed were just a to z, A to Z, and bunch of other English characters. This was problematic. You were limited to only 7 bits i.e. only 2 ^ 7 - 1 = 127 characters. Also non-English characters where not part of ASCII. Literally the name says ‘American Standard Code for Information Interchange’....