GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    elilla&, triumphant over the precepts (elilla@transmom.love)'s status on Thursday, 20-Aug-2026 07:07:47 JST elilla&, triumphant over the precepts elilla&, triumphant over the precepts

    most people who are into writing systems are not into computers and vice-versa. so Unicode drama was a very particular kind of hobby drama. most of you have no idea how funny the current situation is.

    see, it gets pretty tricky to define what's a "character" across every writing system in the world. for 20 years, Unicode had very strict rules about what gets into the standard: no "rich text" or "graphical variations", only "plain text abstract characters" are defined. you might think that "A" is a big pointy wedge with an horizontal stroke but from the point of view of Unicode, "A" is a number (65) and a name ("LATIN CAPITAL LETTER A") and some properties ("Letter", "Uppercase", "Narrow", "Left-to-right"). the facts that "A" is usually this triangley thing, but in some styles A looks more like a round oval with a tail, and in blacktext A looks more like an U shape—all that mean nothing to Unicode. all of those are merely graphical variations ("glyphs") of 65, LATIN CAPITAL LETTER A.

    this gets of course fuzzy at the edges. The character 骨, "bone", can be written with the top component facing left, or facing right. This is unarguably a "graphic variation"—it's still the same "abstract character"—so Unicode leaves that for the font to decide. Unfortunately it has become custom in the modern era (but not in historical texts) that mainland China draws it to the left, whereas Japan and Taiwan and the others do it to the right. This means that when people changed their systems from legacy encodings to Unicode, suddenly their characters would be drawn in the hated Chinese way / the hated Japanese way, and since Unicode is a "foreign imposition" they would blame foreigner ignorance of their cultural nuances. In fact the Unicode hànzì team was made of specialists from East Asia and the reasoning for this bug was perfectly logical for nerds: if your system is set to Japanese it should be using Japanese fonts with the glyph to the right, it's not our fault if Microsoft/Linux/etc. is getting the wrong fonts. but in your legacy system it would "just work" and look right; upgrade to Unicode, problems happen. the dorks at Unicode would have endless discussions over this and reject the idea of adding "Chinese 骨" and "Japanese 骨" as different characters because that's technically Wrong, these are the same abstract character.

    multiply that by a thousand. imagine 20 years of strict gatekeeping like this, with people constantly proposing new characters from this and that source and the guardians of Unicode rejecting them because they can be understood as merely graphical variations of existing characters, or as too obscure to be worthy encoding, etc. (it took so long to get hentaigana into Unicode, like ~8 years between proposal and finally having the characters encoded! you can't represent any premodern manuscripts without it!)

    --

    then Japanese people start making cellphones with Internet, before everybody else.

    and they put "picture" (e) "characters" (moji) because they're cute. each company makes their own emoji set, incompatible on purpose so you have to buy into their special, incompatible little internets.

    see, the only situation where Unicode would make exceptions to their strict gatekeeping was "round-trip compatibility". a character like ª is just an especially typeset 'a' and thus should not count as an abstract character. but some previous text encodings like ISO-8859-1 already had an 'ª' separated from 'a'. so if you converted a text file from ISO-8559-1 and Unicode had no 'ª', it would become 'a', and now you can't distinguish it from regular 'a', so there's no way to convert it back to ISO-8859-1. you cannot "round-trip" between encodings. so in this case and in only ☝️ this case, the Consortium would allow breaking the usual gatekeeping rules, carefully and case-by-case.

    then a guy from Google asked to add all the Japanese emoji from every vendor. after all, without that you couldn't represent Japanese meeru messages in Unicode and convert them back. the Consortium obviously refused all those silly pictures as out of scope. so Google teamed up with Apple and kinda highkey threw their weight, financially and otherwise, transparently because they wanted this feature in the nascent smartphone consumer culture, and powerful interests completely overrode the cabal of writing hobbyists who had hitherto kept Unicode so pure. after years of elaborate technical criteria refusing tons of characters that people proposed for serious use, Unicode 6 (2010) included the first set of emoji.

    fast forward to now, and all of those Unix greybeards and linguistics associates just nod sadly in a corner from the purely ceremonial Consortium chairs at whatever Big Tech mandarins came up with this year, like, "yeah sure that's what we need, U+1FAE9 FACE WITH BAGS UNDER EYES 🫩, whatever. U+1FAC8 HAIRY CREATURE 🫈, why not at this point."

    In conversation about 18 hours ago from transmom.love permalink
    • GreenSkyOverMe (Monika) repeated this.
    • Embed this notice
      snacks (snacks@netzsphaere.xyz)'s status on Thursday, 20-Aug-2026 16:35:29 JST snacks snacks
      in reply to
      • omen of instance annihilation
      • OCTADE
      @coolbean @octade @elilla how would you fit the chinese characters in 8 bits?
      In conversation about 9 hours ago permalink
    • Embed this notice
      omen of instance annihilation (coolbean@brain.worm.pink)'s status on Thursday, 20-Aug-2026 16:35:30 JST omen of instance annihilation omen of instance annihilation
      in reply to
      • OCTADE
      @elilla @octade yea, if anything my biggest complaint about unicode is that by starting at iso8859-1 while hanzu are in like the 3 byte range makes it still to eurocentric by simply encoding east asian languages less efficiently
      In conversation about 9 hours ago permalink
    • Embed this notice
      elilla&, triumphant over the precepts (elilla@transmom.love)'s status on Thursday, 20-Aug-2026 16:35:31 JST elilla&, triumphant over the precepts elilla&, triumphant over the precepts
      in reply to
      • OCTADE

      @octade Unicode is a wonderful standard and ASCII is extremely Euro- and Anglocentric.

      you generally don't have to parse unicode yourself because the algorithms are already given (in the technical annexes / UAX) and reference implementations are already provided (e.g. libicu).

      In conversation about 9 hours ago permalink
    • Embed this notice
      OCTADE (octade@soc.octade.net)'s status on Thursday, 20-Aug-2026 16:35:36 JST OCTADE OCTADE
      in reply to
      A few years ago I wrote a unicode parser for a hash verification program. That was _interesting_. I miss plain old ASCII.

      CC: @elilla@transmom.love
      In conversation about 9 hours ago permalink
    • Embed this notice
      elilla&, triumphant over the precepts (elilla@transmom.love)'s status on Thursday, 20-Aug-2026 18:34:34 JST elilla&, triumphant over the precepts elilla&, triumphant over the precepts
      in reply to
      • cogito ergo mecagoendios

      @elrohir oh that's very easy; your programming language should be defining identifiers by categories such as L* (Letter) and not S* (Symbol):

      unicodedata.category('m')
      'Ll' # Letter, lowercase
      unicodedata.category('😝')
      'So' # Symbol, other

      this was already the case from the start, since even without Unicode, without that you don't have a way to know that 米 (category "Lo") is a letter that should be allowed for identifier tokens, but ※ (category "Po": Punctuation, other) isn't.

      the fact that many Anglocentric programmers didn't bother to consider the existence of characters beyond ISO-8859-1 worth accounting for is not Unicode's fault, they told you what to do from the start. UAX #31, "Identifier and Pattern Syntax" gave everyone a ready-made recipe of how to do Unicode identifiers twenty-five years ago.
      https://www.unicode.org/reports/tr31/

      In conversation about 7 hours ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: www.unicode.org
        UAX #31: Unicode Identifiers and Syntax
    • Embed this notice
      cogito ergo mecagoendios (elrohir@mastodon.gal)'s status on Thursday, 20-Aug-2026 18:34:35 JST cogito ergo mecagoendios cogito ergo mecagoendios
      in reply to

      @elilla The funniest thing about dumping such a truckload of emojis in the standard character encoding table is that it makes programming languages have to take active steps to prevent me from writing

      def 👀( 😝 ):
      return( 😝+1 )

      and it being a valid

      In conversation about 7 hours ago permalink
      GreenSkyOverMe (Monika) repeated this.
    • Embed this notice
      Moritz Negwer (moritz_negwer@mstdn.science)'s status on Thursday, 20-Aug-2026 18:40:39 JST Moritz Negwer Moritz Negwer
      in reply to

      @elilla so *that's* what this #relevantxkcd refers to: https://m.xkcd.com/1726/

      In conversation about 7 hours ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: imgs.xkcd.com
        xkcd: Unicode

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.