There have been some additions since 2018 when this article was written; here is the current list, from what I can tell:
㍳ │ 003373 │ SQUARE AU │ AU │ Australia
㍴ │ 003374 │ SQUARE BAR │ BAR │ Bar, Punto 2012 Sociedad Anonima Promotora de Inversion de Capital Variable
㎈ │ 003388 │ SQUARE CAL │ CAL │ Google
㏄ │ 0033C4 │ SQUARE CC │ CC │ Cocos (Keeling) Islands
㏅ │ 0033C5 │ SQUARE CD │ CD │ The Democratic Republic of the Congo
� │ 01F12D │ CIRCLED CD │ CD │ The Democratic Republic of the Congo
㎝ │ 00339D │ SQUARE CM │ CM │ Cameroon
� │ 01F190 │ SQUARE DJ │ DJ │ Djibouti
㍷ │ 003377 │ SQUARE DM │ DM │ Dominica
DZ │ 0001F1 │ LATIN CAPITAL LETTER DZ │ DZ │ Algeria
Dz │ 0001F2 │ LATIN CAPITAL LETTER D WITH SMALL LETTER Z │ DZ │ Algeria
dz │ 0001F3 │ LATIN SMALL LETTER DZ │ DZ │ Algeria
fi │ 00FB01 │ LATIN SMALL LIGATURE FI │ FI │ The Republic of Finland
㎙ │ 003399 │ SQUARE FM │ FM │ Federated States of Micronesia
㏿ │ 0033FF │ SQUARE GAL │ GAL │ Galicia, Spain
㎇ │ 003387 │ SQUARE GB │ GB │ United Kingdom
㏉ │ 0033C9 │ SQUARE GY │ GY │ Guyana
㏌ │ 0033CC │ SQUARE IN │ IN │ The Republic of India
㎏ │ 00338F │ SQUARE KG │ KG │ Kyrgyzstan
㎞ │ 00339E │ SQUARE KM │ KM │ Comoros
㏎ │ 0033CE │ SQUARE KM │ KM │ Comoros
㎾ │ 0033BE │ SQUARE KW │ KW │ Kuwait
㋏ │ 0032CF │ LIMITED LIABILITY SIGN │ LTD │ Binky Moon, LLC
㎃ │ 003383 │ SQUARE MA │ MA │ Morocco
� │ 01F16A │ RAISED MC SIGN │ MC │ Monaco
� │ 01F16B │ RAISED MD SIGN │ MD │ The Republic of Moldova
㎎ │ 00338E │ SQUARE MG │ MG │ Madagascar
㏕ │ 0033D5 │ SQUARE MIL │ MIL │ United States Military
㎜ │ 00339C │ SQUARE MM │ MM │ Myanmar
� │ 01F16C │ RAISED MR SIGN │ MR │ Mauritania
㎳ │ 0033B3 │ SQUARE MS │ MS │ Montserrat
㎷ │ 0033B7 │ SQUARE MV │ MV │ Maldives
㎹ │ 0033B9 │ SQUARE MV MEGA │ MV │ Maldives
� │ 01F14B │ SQUARED MV │ MV │ Maldives
㎽ │ 0033BD │ SQUARE MW │ MW │ Malawi
㎿ │ 0033BF │ SQUARE MW MEGA │ MW │ Malawi
㎁ │ 003381 │ SQUARE NA │ NA │ Namibia
㎋ │ 00338B │ SQUARE NF │ NF │ Norfolk Island
№ │ 002116 │ NUMERO SIGN │ NO │ The Kingdom of Norway
㎀ │ 003380 │ SQUARE PA AMPS │ PA │ Panama
㎩ │ 0033A9 │ SQUARE PA │ PA │ Panama
㎊ │ 00338A │ SQUARE PF │ PF │ French Polynesia
㏗ │ 0033D7 │ SQUARE PH │ PH │ The Republic of the Philippines
㏚ │ 0033DA │ SQUARE PR │ PR │ Puerto Rico (U.S.)
㎰ │ 0033B0 │ SQUARE PS │ PS │ Palestinian Territory, Occupied
㎺ │ 0033BA │ SQUARE PW │ PW │ Palau
₨ │ 0020A8 │ RUPEE SIGN │ RS │ Serbia
� │ 01F14C │ SQUARED SD │ SD │ Sudan
℠ │ 002120 │ SERVICE MARK │ SM │ San Marino
㏛ │ 0033DB │ SQUARE SR │ SR │ Suriname
� │ 01F14D │ SQUARED │ SS │ SS │ South Sudan
st │ 00FB06 │ LATIN SMALL LIGATURE ST │ ST │ Sao Tome and Principe
㏜ │ 0033DC │ SQUARE SV │ SV │ El Salvador
℡ │ 002121 │ TELEPHONE SIGN │ TEL │ Contact data
™ │ 002122 │ TRADE MARK SIGN │ TM │ Turkmenistan
Ⅵ │ 002165 │ ROMAN NUMERAL SIX │ VI │ Virgin Islands, U.S.
ⅵ │ 002175 │ SMALL ROMAN NUMERAL SIX │ VI │ Virgin Islands, U.S.
㌽ │ 00333D │ SQUARE POINTO │ ポイント │ Amazon Registry Services, Inc.
Lowercasing is not guaranteed to be stable between Unicode versions. If you're looking for stable string matching, use "case folding" instead. Instead of:
lower(a) == lower(b) // or,
lower(needle) in lower(haystack)
Use:
casefold(a) == casefold(b) // or,
casefold(needle) in casefold(haystack)
It's equivalent to lowercasing in almost all cases, but with a stability constraint between across Unicode editions. As per the Unicode stability policy [1]:
> Case folding is not the same as lowercasing, and a case-folded string is not necessarily lowercase. In particular, as of Unicode 8.0, Cherokee has become a bicameral script with the introduction of lowercase Cherokee letters, but Cherokee text case folds to the existing uppercase letters. This case folding behavior for Cherokee text is precisely to guarantee continued case folding stability.
Casing in Unicode can be tricky. The case mapping FAQ [2] is a good place to start. If you need more information, start scanning through the Core Spec and following the case-related links [3].
From what I understand, it is mostly the very rigid and prescriptive attitude which the average reader gets from his book, which, if you listen to him talk, was not his intent. He even published a new 2025 edition of “Clean Code” to try and fix this, by making the text less self-assured. So while he may or may not be responsible, he did not intend it.
I came to say the same thing. “How many baud was it?” is the immediate question anyone familiar with modems would have, but it is nowhere in the text. Only in the image of the advertisement does it say that it is 300 baud. Because people who would want to buy one would want to know.
NAT and CGNAT break the basic idea of how the Internet was designed, forcing everyone into servers and consumers. We've just become used to it, and most people have never experienced it any other way.
The Internet was supposed to be a purely peer-to-peer network, where the addresses on each side of a connection pointed to an end node. That's why protocols like FTP or SIP break when NAT is used, and why you have to play games with port forwarding if you want to run services from your house (assuming you have a public IP address at all).
It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer. That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
> It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer.
Because just about all applications are currently architected in such a manner.
When Skype first came out many moons ago it allowed peer-to-peer connections with clients, but a lot of clients were behind NAT (especially ones that could not do PCP or UPnP), so Skype had to come up with the notion of "super nodes" that could do relaying.
Protocols like STUN/TURN/ICE/etc had to be developed to deal with all of this blocking of traffic.
If clients could know their 'real' addresses and allow things like PCP (which is often needed for (e.g.) video games), then perhaps there could me less strictly consuming and more collaborating.
We couldn't do it with FTP. That's kinda the point. We didn't have static IP addresses for every machine or the entries in DNS to go with them.
The whole idea of "consumer" and "server" nodes is so baked into how people think about networking they don't even realize it. But that's not how the Internet was intended to be in the first place.
You absolutely can do it within the existing paradigm, in a number of ways, actually. Search for iroh, or DynDNS for example.
And if you seriously believe that Dropbox appeared because of NAT, and not because people prefer out-of-the-box solutions, I can only suggest you to go out of your bubble, and discuss technical issues with random people.
"Intended" btw is not even an argument. Internet wasn't intended for many things which we happily do here.
I'm well familiar with DynDNS. I used to run it before I got a real domain. It can't tell the difference between my laptop and my workstation, since they're both behind the same IP. I wasn't aware of iroh, but having looked it up, it's just a hack to get around problems that NAT has caused.
And yes, Dropbox does exist because of NAT, or more generally the fact that "consumers" are second-class citizens on the Internet. If everyone had a publicly routed address and an entry in DNS - which is how the Internet was originally envisioned - we'd have solutions that don't require a third party server.
Both of your examples just show how deep the Stockholm syndrome is. IPv4's limitations have shifted the way people think about networking so much that they rarely even realize they're doing it. But this isn't the way it was supposed to be. "Intended" is completely valid when we're talking about how something has strayed from its original design and the ramifications of it.
I'm not naive enough to think that we can ever get rid of the "consumer" and "producer" ideas that have crept into everyone's head. But it's important to remember that these ideas came about only because of limitations in the protocol, not because they're some kind of natural law of how global networks function.
Yes, and DynDNS too. Which is fine, cause it works, and that is what I said. The claim to which it replies is that people have to pay to Dropbox cause poor souls were stopped from sharing files using existing technologies like FTP by the damned IPv4, and not because they simply prefer an out-of-the-box GUI thing.
There were out-of-the-box GUI experiences, like Apple's "Back to my Mac", that never worked right because of all the issues with poking through NAT caused by IPv4.
Relying on peer-to-peer relays also doesn't scale, which is why Skype dropped its supernode architecture.
> That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
Dropbox gained popularity *BECAUSE IT MADE IT EASY TO DO THIS WHEN YOU'RE STUCK BEHIND NAT TRASH*. By the time it was even a thought in anyone's brain the internet had already been ruined by that garbage.
It would never have existed in a world without NAT because it wouldn't have been needed, syncing data between computers you owned that all had publicly routable addresses is a much simpler problem.
Every ISP that has CGNAT v4 without providing full v6 needs to be shut down. They are either incompetent or actively choosing to make their users' service less useful to restrict them and/or encourage "upgrades". Internet service has a public routable IP address, period.
>it would never have existed in a world without NAT because it wouldn't have been needed,
I'm sorry, but this claim is one of the brightest examples of false consenses effect I've seen in ages. People generally just prefer an icon on desktop to click/tap. And that's the reason Dropbox found its audience.
Now imagine if you didn't need that icon and Windows Explorer (or whatever file manager you use) could just connect to wherever your file is. Maybe through a "Favorite."
Then imagine the security implications of trusting windows to serve just some selected files over FTP and never have any security hole that exposed other files or allowed RCE
> syncing data between computers you owned that all had publicly routable addresses is a much simpler problem.
In no way am I denying that people would like to solve the same problems easily. What I'm saying is that it would have been a much simpler problem requiring much less infrastructure. An application like SyncThing that works without any central infrastructure would have been an order of magnitude easier to implement in a world where every internet connected device had a unique routable address.
> Only today we would have put everything behind something like NAT anyway because your devices would be getting hacked constantly.
So the security "provided by" common 1:many NAT comes from the fact that 1:many NAT inherently requires stateful connection tracking and by its nature traffic coming in from the "1" side without an associated connection or rule has nowhere to go, effectively denying any other traffic by default from the "1" side which is almost universally the untrusted side.
Do you know what else has stateful connection tracking and deny-by-default rules on untrusted interfaces? Every single firewall that's worth using or even was at one point worth using in a year starting with a "2".
So yes, in a world without NAT we'd still have stateful firewalls blocking unsolicited incoming traffic that had not been specifically allowed. Those who wish to host public services will still need to configure rules to allow that traffic in unsolicited but those rules will be simpler than NAT port forwards because there's no address translation involved. Anything else wanting to generate on demand temporary connections between systems will be able to do so simply by having each system perform a basic hole punch, sending traffic at the other at the same time with the same pair of ports, and expect it to work again in ways much simpler than what's necessary for reliably doing the same in a 1:many NAT environment.
1:many NAT makes nothing better, it only makes things worse. It's a bad thing and needs to go away as quickly as possible.
---
1:1 NAT is an entirely different beast, it can be entirely stateless and thus has no has no negative impact on most protocols that don't try to communicate address info in-band but also that statelessness means it doesn't inherently provide a firewall effect.
> It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer. That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
Dropbox gained popularity because none of us can or want to bother to do it with FTP, with the exception of a very small and determined minority.
Why do you think that even FANG engineers use cloud storage systems such as Dropbox/iCloud/OneDrive/Google Drive/etc. Can't an elite software engineer put together a FTP server?
Why do you think Dropbox et al are still a thing in spite of projects such as Syncthing?
This is not the only instance where user experience and convenience show their value. Look at Docker, for example. The "aktually" crowd will be fast to say that anyone can do the same with chroot et al, but they will again be missing the whole point. It's the same thing why Microsoft tried to invest in Aspire even though Docker is here.
It's like complaining that people can buy bread when all they need to make their own is flour, water, salt, and yeast. That's completely besides the point, ain't it?
I think you're taking the "FTP" part a bit too literally here. No one's suggesting we'd jump in a terminal and type in FTP commands manually or even use the FTP protocol itself - we've got better options today, and we'd have even better options if the Internet had had global node-to-node connectivity all along.
It'd likely just be built into your operating system's tooling. Your file manager would be able to access other machines it can authenticate to, or you'd automount remote directories on login, etc.
The reason people use cloud storage systems for moving files around is because they have to. A 3rd party server is required because we don't have node-to-node connectivity.
Hell, we'd likely have had cloud storage options sooner because people wanting extra remote storage would totally have been a thing.
> You mean it's fixed by NAT and CGNAT. Because it's works just fine for me.
CGNAT works for you? Do you play video games at all? Because there are all sorts of people for which it doesn't.
The fact that you may be fortunate enough to get a publicly-accessible IPv4 address on your WAN interface does not mean everyone else is. This type of attitude seems to be akin to "I gots mine."
I don't play this kind of games at all, but I still can sympathize with you if it's your preferred pastime, and it doesn't work as good as you'd like. I just don't think it warrants a conclusion that those nets in which we are arguing are broken. They are tangibly, observably doing pretty well. And I find that the idea that in a shiny world of pure IPv6 central servers/nodes would decentralize themselves comes from deep misunderstanding about what "normal" humans want.
> And I find that the idea that in a shiny world of pure IPv6 central servers/nodes would decentralize themselves comes from deep misunderstanding about what "normal" humans want.
It's not about "what 'normal' humans want", it's about what can even be built.
It's currently hard to build decentralized anything now, and it'd be nice to open things up to see what creative things (if any) people could come up with if the network allowed for more peer-to-peer connections.
There are working procedures to follow in such situations, and minimally competent ISPs deal with them well enough so that most users don't even know the problem exists.
Back when I managed teams that dealt with API traffic at a unicorn, this wasn't the case. We'd ban a /32 and several times customers would start reaching out to our support portal (which ran behind different ingress rules) asking why they couldn't use the site a couple weeks later.
I've never worked on the ISP side so there's no doubt that there is a process at the competent ones, but my guess is most users do not have a competent one.
reply