{"id":19577580,"url":"https://github.com/emoun/racp","last_synced_at":"2026-07-11T05:31:02.258Z","repository":{"id":134696355,"uuid":"89949301","full_name":"Emoun/racp","owner":"Emoun","description":"Revised ASCII Codes for Programming - A new character set for the modern programming environment","archived":false,"fork":false,"pushed_at":"2020-04-11T07:55:57.000Z","size":173,"stargazers_count":3,"open_issues_count":1,"forks_count":1,"subscribers_count":0,"default_branch":"master","last_synced_at":"2025-10-26T23:33:04.752Z","etag":null,"topics":["ascii","character-encoding","character-set","encoding","racp","specification"],"latest_commit_sha":null,"homepage":null,"language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Emoun.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-05-01T18:10:57.000Z","updated_at":"2020-04-20T14:26:25.000Z","dependencies_parsed_at":null,"dependency_job_id":"3efac4af-6a74-4a43-8da9-d7a1a9682b11","html_url":"https://github.com/Emoun/racp","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/Emoun/racp","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Emoun%2Fracp","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Emoun%2Fracp/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Emoun%2Fracp/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Emoun%2Fracp/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Emoun","download_url":"https://codeload.github.com/Emoun/racp/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Emoun%2Fracp/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":35352623,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-07-11T02:00:05.354Z","response_time":104,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ascii","character-encoding","character-set","encoding","racp","specification"],"created_at":"2024-11-11T07:07:09.295Z","updated_at":"2026-07-11T05:31:02.212Z","avatar_url":"https://github.com/Emoun.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# RACP\n**R**evised **A**SCII **C**odes for **P**rogramming - \nA character set for the modern programming environment.\n\n## Motivation\n\nThe use of the ASCII character set has been ongoing for about 50 years now\u003csup\u003e1\u003c/sup\u003e and it seems time for a modernisation.\nI find that ASCII no longer fits the role it has as the de facto character set. It was designed for use with teletypes\u003csup\u003e2\u003c/sup\u003e, but is now used for so much more. This begs the question: why? The short answer is that it's what we have always done. But, this answer hinders progress and innovation, so I have decided to try and modernise ASCII for the current software development environment.\n\nASCII uses 7-bit character codes, i.e. 128 codes in total, but about a quarter of those are control codes which are rarely used\u003csup\u003e3\u003c/sup\u003e. A huge waste. \nRACP aims at repurposing those codes for useful endevours and additionally define rules which solve some of the annoyances programmers face today. Like: \n\n*\"Why does this file not use the proper new-line;* \u003cinsert *\\n* or *\\r\\n* at your discretion\u003e *?\"*\n\n*\"Is that number in hexadecimal, decimal, or, god forbid, binary?\"*\n\nand everyones favorite: \n\n*\"Was this file tabbed with 2-, 4-, or 8-space tabs?\"*\n\nASCII is not all bad, I must admit. Most characters are well thought out and many are ingeniously placed. \nTherefore, for all non-useless characters ( which is essentially all non-control characters \u003csup\u003e4\u003c/sup\u003e ) are also found in RACP, though they may be repositioned. No reason to reinvent the wheel, just the spokes.\n\nLastly, I must acknowledge that this is probably a futile endevour, as it is excruciatingly unlikely that the world will switch from using ASCII. But, at least I will know that there is a better solution out there - even though no one wants to use it.\n#\n\n1: https://en.wikipedia.org/wiki/ASCII\n\n2: http://www.asciitable.com/\n\n3: This is actually just an assumption of mine. (\u003csup\u003e2\u003c/sup\u003e) does hint at its correctness, but is not definitive.\n\n4: The exception is the pseudo character 'Accent Grave' which will be replaced by a proper character.\n\n## FAQ\n\n#### *Why not use all 256 values available in a byte and add more characters?*\n\nThe primary reason is that of future compatability. By having one bit free, we will able to, in the future, define a Unicode like character set or encoding which always has that bit set to 1. This makes it trivial to figure out which of the two incodings a string is written in. \n\nThe second reason is that it does not really add that much functionality. 128 different characters seems more than enough for all current use cases, when remembering that we use ASCII for everything today, which has 31 less characters (that are usable).\nAdditionally, character bloat is a real thing. There are only so many keys on a keyboard, and even with only 128 characters I have spent a considerable amount of time trying to find new key combinations to use for the new characters. \nAlso, can we really expect programmers to remember 256 characters? Can we even expect them to remember 128? If programmers can't remember which characters are at their disposal and how to type them, they will never use them.\n\nIf I could, I would have less characters. Since we cannot have undefined characters in the 7 bit range, and 64 (6-bit) is strictly too few, 128 is the answer.\n\n#### *Why is there no* NULL *character?*\n\nWhat does *NULL* mean? the lack of a character? how can a character be the lack of a character? shouldn't there just *not* be a character?\n\n*\"How will you implement null-terminated strings without a NULL character?\"*\n\nYou shouldn't. Null-terminated strings have been called many things. I will now call them an abomination.\n\n#### *What use cases is the character set designed for?*\n\nRACP should be used anywhere a programmer needs to read or edit text. \nSource code is the most obvious and prevalent situation. \nEven though protocols are intended for machine reading, programmers must be able to read what is sent and received when developing or debugging applications using the protocol.\n\n#### *Why are Elastic Tabstops a requirement and not just a recommendation?*\n\nBecause recommendations are ignored\u003csup\u003e5\u003c/sup\u003e and this is Better\u003csup\u003eTM\u003c/sup\u003e.\n\n#### *Why use the names* Jamb *and* Lath *for the new brackets?*\n\nI wanted short names which are not widely used in computer science (yet). \nI searched for bracket synonyms and they came up. \nTheir real world meanings are also comfortably close to what they should be used for (though many might disagree with this).\n\n#### *What are those weird characters you use for the first 9 hexadecimals?*\n\nThey are used when writing numbers in Arabic.\u003csup\u003e6\u003c/sup\u003e\nSince I speak and write Arabic they seemed as an obvious choice. \nI tried inventing my own characters but I am apparently not a very creative person.\n\n#### *Many of the new characters have no Graphics representation. Why is that?*\n\nThey are characters which do not have an established unique graphical representation. \nThe specification does not yet seek to mandate their graphical representation, though the reference editor does propose (non-mandatory) representations.\n\nNo graphical representation of *any* character is mandated by this specification.\n\n#### *Terminals often use the so-called unused control characters*\n\nThis is true. Though, any terminals using RACP would have probably been written from scratch to do so, which is a great opportunity to instead implement a proper interface that does not rely on specific characters.\nI do not see this as a problem, as all applications should distinguish between characters and commands. In RACP, no character should be interpreted as a command, not even TAB or NL.\n\n#### *Its \u003c insert current year \u003e, why make a new character set that does not support all natural languages?*\n\n_Warning: Very subjective opinion._\n\nRACP is designed for programmers to use in source/protocol code. Therefore, non-technical users are not expected to\never read pure RACP. Internationalization is not a goal of the character set. \nIn reality, RACP is specifically designed to minimize internationalization so that all of the world's programmers can converge on a single\nnatural language, English. This is an important goal, as it will allow all programmers to always be able to read other programmers' code.\nThe obvious choice of language is English, and therefore RACP only supports strictly English characters.\nAnyone who want to argue against the use of English must provide extraordenary evidence that shows that most source code today or ever is written in another language that should be used instead.\n\nThe proliferation of Unicode in programming language sources is bad for the world. \nIt means that programmers from different human language backround can isolate themselves by writing their programs using their native language, which is unreadable to all non-native programmers. \nAdditionally, it actually allows the use of emojis as variable names. If anyone seriously thinks that is a good idea, I urge them to rethink their life choices.\n\n#\n5: https://en.wikipedia.org/wiki/Metric_Conversion_Act\n\n6: https://en.wikipedia.org/wiki/Eastern_Arabic_numerals\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Femoun%2Fracp","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Femoun%2Fracp","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Femoun%2Fracp/lists"}