21–30 of 32 posts
Apparently, all I know about strings is correct.
And, he didn't even touch on the horror that is EBCDIC. Once you've had to touch that, the idea of "code point" for a character is something you can't ignore, hoping that things just work "most of the time" -- ASCII A != EBCDIC A.
Earlier quoted context omitted.
And, he didn't even touch on the horror that is EBCDIC. Once you've had to touch that, the idea of "code point" for a character is something you can't ignore, hoping that things just work "most of the time" -- ASCII A != EBCDIC A.
Are there still (many) of people using EBCDIC?
(disclosure: I once worked at a company that made tools to port code and data from IBM minicomputers to Unix & MS platforms, and also at the largest [format,] print & mail shop in the US)
Apparently, all I know about strings is correct.
(Unless you already knew it ten years ago. Back when he wrote "Everything you thought you knew about strings is wrong." it was quite true of most every programmer, and it was thanks to this piece and similar ones, by Spolsky and others, that the information got spread around.
There must be some phrase for this opposite of the "self fulfilling prophecy": the cautionary phrase that causes itself to become false in the future ;-)
Earlier quoted context omitted.
There never will be more than 4 bytes for UTF-8 because Unicode is restricted to 21 bits. Remember that all UTFs have to be able to represent all of Unicode and UTF-16 could not represent those “code points” where UTF-8 needs 5+ bytes. Also I wouldn't say that UTF-8 is a compression scheme. SCSU is one but has its own share of problems. UTF-8 just happens to preserve ASCII compatibility which is an important property…
From the standpoint of an English speaker, UTF-8 is effectively a (good) compression scheme for Unicode, as opposed to using 2 or more bytes for every character. I guess if I were German or Spanish (to say nothing of Asian languages), it would be the opposite of compression :-)
I discovered one case today, there may be others. Answer: https://twitter.com/moreati/status/332910618858364928
Apparently, all I know about strings is correct.
"Thank you, Mark Pilgrim". (Unless you already knew it ten years ago. Back when he wrote "Everything you thought you knew about strings is wrong." it was quite true of most every programmer, and it was thanks to this piece and similar ones, by Spolsky and others, that the information got spread around. There must be some phrase for this opposite of the "self fulfilling prophecy": the cautionary phrase that causes its…
Earlier quoted context omitted.
As your parent already noted, thinking of it as a sequence of code points goes wrong when you need to truncate a string in between a base and a combining character.
Not true. Take this string: d͊ It is composed of two code points: U+0064 and U+034A. The second code point is a combining character. The two code points together form one glyph. The term "character" is confusing because people use different definitions for it, I avoid using it, but the term Unicode code point is very clear. Python 3's strings is a sequence of code points. The above string is represented like this: >>…
A Friday challenge: In Python when is u'ß'.upper() equal to u'SS'? I discovered one case today, there may be others. Answer: https://twitter.com/moreati/status/332910618858364928
A Friday challenge: In Python when is u'ß'.upper() equal to u'SS'? I discovered one case today, there may be others. Answer: https://twitter.com/moreati/status/332910618858364928
Earlier quoted context omitted.
Not true. Take this string: d͊ It is composed of two code points: U+0064 and U+034A. The second code point is a combining character. The two code points together form one glyph. The term "character" is confusing because people use different definitions for it, I avoid using it, but the term Unicode code point is very clear. Python 3's strings is a sequence of code points. The above string is represented like this: >>…
Except it doesn't work as expected because users generally expect graphemes to stay as they are instead of losing random diacritics.