summaryrefslogtreecommitdiff
path: root/issues/fix-broken-utf8-chars.gmi
diff options
context:
space:
mode:
authorMunyoki Kilyungi2022-12-15 17:16:17 +0300
committerMunyoki Kilyungi2022-12-15 17:17:32 +0300
commitfebba2f0bf6ca00cc82119e9349f65859714b183 (patch)
tree502fd0acdc5ca860bb2bd7c2c8dc0f4f63c1fa19 /issues/fix-broken-utf8-chars.gmi
parentf35e10744cf218b1402d8fb2a7414e4023cadf69 (diff)
downloadgn-gemtext-febba2f0bf6ca00cc82119e9349f65859714b183.tar.gz
Document why utf-8 is broken in SQL/RDF and possible fixes
Diffstat (limited to 'issues/fix-broken-utf8-chars.gmi')
-rw-r--r--issues/fix-broken-utf8-chars.gmi4
1 files changed, 4 insertions, 0 deletions
diff --git a/issues/fix-broken-utf8-chars.gmi b/issues/fix-broken-utf8-chars.gmi
index beef2c2..0baeef3 100644
--- a/issues/fix-broken-utf8-chars.gmi
+++ b/issues/fix-broken-utf8-chars.gmi
@@ -13,3 +13,7 @@ We have jumbled up text in our database and this has been the case for years. I
This thread has some really nice ideas
=> https://stackoverflow.com/questions/1476356/detecting-utf8-broken-characters-in-mysql Detecting broken characters in mysql
+
+An example of a broken unicode character is: ">". The character ">" appears broken because it is not a valid Unicode character. This can happen for a number of reasons, such as a mistake when typing or pasting the character, corruption during transmission (most likely the case) or storage, or a lack of support for the character in the font or software being used to display the text.
+
+To find the correct replacement for the character ">", or any other character for the matter, you can look up its Unicode code point. In this case, the code point for ">" is "U+2273", which corresponds to the character "≥". You can then use this code point to search for and replace the broken character with the correct character in the text.