I wonder why vfat in kconfig does not select these options:

• CONFIG_NLS_CODEPAGE_437
• CONFIG_NLS_ISO8859_1

Noticed this while putting together #systemd image. You really cannot use FAT meaningfully without 437, so there should be IMHO either depends or select relation between these and FAT kconfig options.

In my opinion selecting VFAT in 2024 from kconfig should lead to selecting all the options that are required for filenames at minimum because it has exactly two use cases:

1. USB sticks
2. ESP

In both cases proper interpretation of filenames is required.

PS. I also wonder why systemd does not list them as its required CONFIG_*. They are not obvious kconfig options in the context of kernel QA ;-) I always begin with tinyconfig and add up from there when doing this. Using ESP is required by practical means with systemd-boot so all three options should exist in this file: https://github.com/systemd/systemd/blob/main/README. I used it as a reference and failed.

#linux #kernel #vfat #codepage #437

Und sowas noch in 2024!

#utf8 #unicode #codepage

I made a pair of web applications:

1. https://gate.uber.space/dkq/cgi-bin/xencode takes a piece of text and shows how it would be represented in various encodings that it knows about.

2. https://gate.uber.space/dkq/cgi-bin/xdecode does the opposite. It takes a sequence of bytes (in hex) and shows what text it represents in various encodings.

By the way, if you find a way to exploit these (particularly HTML injection/XSS), please tell me!

(Idea inspired by @foone, who once asked for something like this.)

#encoding #unicode #codepage

Just released dos2ansi v0.4, with lots of #DOS #codepage s supported and a testmode to display them.

The next nice feature would be to use the actual terminal capabilities if output goes there. Very simple on *nix-like systems (#Linux, #FreeBSD, ...), just link #curses and use the termcap functions.

Thinking about #Windows again, either I keep relying on #UTF8 support (since #win7 IIRC? and still a bit buggy) and #ANSI sequences support (since #win10) .... OR I attempt to use the native #Console #API there (using special functions to write in #UTF16 and other special functions to set colors, which would require a major refactoring first 🙄)

https://github.com/Zirias/dos2ansi/releases/tag/v0.4

New pre-release of dos2ansi: v0.2

* Works on #Windows, win32 binary (cross-compiled on #FreeBSD) attached
* Selectable input #codepage (so far only #cp437, #cp850 and #cp858)
* Selectable output format, #utf8, #utf16 or #utf16le, with or without #BOM

Still a few things to add, e.g. use #termcap/#terminfo or Windows Console API for "color output" when applicable ... we will see 😎

https://github.com/Zirias/dos2ansi/releases/tag/v0.2

Remember these specific #ASCIIart misrenderings using the wrong #codepage? Made actually a good testcase after adding codepage selection to my new "dos2ansi" tool 😜
https://github.com/Zirias/dos2ansi

Screenshot from #konsole (#KDE) running on #FreeBSD and using Microsoft's #Consolas font.

Everything you've always wanted to know about computer text but you were too afraid to ask

https://www.youtube.com/watch?v=gd5uJ7Nlvvo

#software #computers #unicode #ascii #codepage #pikematchbox

@bkastl

Aaaah ... XÖV ... ich wäre mir an deren Stelle mal nicht so sicher, dass das "Ö" in irgendwelchen Behärdensystemen keine #Codepage-Probleme macht! 🤣

#degitalisierung