search

todotxt / todo.txt

‼️ A complete primer on the whys and hows of todo.txt.
GNU General Public License v3.0
2.41k stars 103 forks source link

Spec should specify an encoding #10

Open mpcjanssen opened 7 years ago

mpcjanssen commented 7 years ago

The spec should include the expected encoding of a proper todo file. At the moment a client cannot properly open a todo.txt file created on a system with a different encoding.

There are two ways to fix this:

  1. Include encoding metadata in the todo.txt file
  2. Specify UTF-8

My preference would definitely be number 2.

karbassi commented 7 years ago

My vote is UTF-8.

This would solve the line ending problems as well.

mpcjanssen commented 7 years ago

For line endings I would allow \r \n and \r\n.

heX16 commented 6 years ago

My vote is "UTF-8 with BOM".

Because "UTF-8" some times have problem with encoding detection (and incorrect definitions like ANSI (and damage to characters)).

koppor commented 3 years ago

I am working in a project for reference management. We store bibliographic data in BibTeX files, which are plain-text sort-of-key-value files.

We also stored the encoding information at the beginning of the file. We came to the conclusion that UTF-8 is widely adopted and thus, we support UTF-8 only. Most users should be able to use recode (or Notepad++ and alike) to change the encoding.

IMHO BOM should not be enforced. A todo.txt file is still a text file which should be editable by any text editor and versionable by any version control system.

mpcjanssen commented 3 years ago

BOM is really only needed for broken windows tools (such as Excel) but it would mean any todo.txt file is not a valid ASCII file anymore (even when only characters in the ASCII range are used).