DOS Command and Character Set
jdokdo
Posted messages
3
Status
Member
-
jdokdo Posted messages 3 Status Member -
jdokdo Posted messages 3 Status Member -
Hello,
Text files (notepad txt) created by redirecting DOS commands in a command line window are not created in the correct character set (like: "dos_command > file.txt" such as "dir /s /b path > list_fich.txt" to get a list of files in a directory tree).
This makes the created file difficult to read. Example: "," instead of "é", "..." instead of "à", "^" instead of "ê", etc...
It seems that the files are created with the "Western Europe (DOS/OS2-850/International)" character set.
At least that is what I observed when attempting to import into Open.Office.Calc, as the characters seem to match. However, since I need to create scripts with the information retrieved from the "redirected" files, going through the import into a spreadsheet is not the right solution.
I also cannot control the use of accented characters by the users.
The simplest solution would be to parametrize the creation of text files with the correct character set.
Is there anyone who has an opinion on this, or knows how to proceed to obtain a correctly written file during redirection? Or a copy of the created txt file with the correct character set this time.
Subsidiary question: what is the standard character set in text files (notepad txt)?
Best regards
JD
Text files (notepad txt) created by redirecting DOS commands in a command line window are not created in the correct character set (like: "dos_command > file.txt" such as "dir /s /b path > list_fich.txt" to get a list of files in a directory tree).
This makes the created file difficult to read. Example: "," instead of "é", "..." instead of "à", "^" instead of "ê", etc...
It seems that the files are created with the "Western Europe (DOS/OS2-850/International)" character set.
At least that is what I observed when attempting to import into Open.Office.Calc, as the characters seem to match. However, since I need to create scripts with the information retrieved from the "redirected" files, going through the import into a spreadsheet is not the right solution.
I also cannot control the use of accented characters by the users.
The simplest solution would be to parametrize the creation of text files with the correct character set.
Is there anyone who has an opinion on this, or knows how to proceed to obtain a correctly written file during redirection? Or a copy of the created txt file with the correct character set this time.
Subsidiary question: what is the standard character set in text files (notepad txt)?
Best regards
JD
Configuration: Windows 7 / Firefox 3.6
4 answers
-
Thank you Dubcek for your response.
I don't believe this is the case; I have Windows 7 and it’s quite recent.
Moreover, if I don’t redirect the output of the command to a file but display it on the screen and copy the result into a file, there is no character set issue.
Another observation in different circumstances: in email messages, this type of mishap frequently occurs with an unreadable received message. It is not due to the age of DOS.
Between UNIX, Linux, DOS, Windows, etc., there are often this type of problem, just like on the internet during exchanges of information between different platforms, or for interfaces between data management systems.
Although I am not a specialist in these conversion issues, I have noticed in the past this type of problem, most often resolved by a good computer technician who is a bit sharp on the basics.
I suspect a character set configuration issue since specifying the character set, as previously mentioned, when importing CSV into open.office.org.calc resolves the problem (Western Europe (DOS/OS2-850/International)). This indicates that the encoding of accented characters is well integrated into the file (the character "," or "..." are actually not a comma or points, but special characters).
The question would then be: how to translate a file from one to another using the correspondence between the two sets, the source and the destination?
The source set being identified, remains a subsidiary question: what is the destination set, that is to say, the one used by default in Windows to create a text file?
Here is a nice puzzle to solve in the sets ;-)), a nice challenge to take on.
Who is up for it?
Thank you for your help and patience.
Sincerely
JD -
hello
generate files in Unicode?
cmd /u/c "command > file.txt" -
Thank you Dubcek for this suggestion.
I tested it, but unfortunately the issue is not resolved by this parameter: whether it is /u or /a, the result is the same as before.
There seem to be subtle differences between ANSI, UNICODE, and Windows character sets.
Suggestions are always welcome.
Thanks in advance to anyone who would like to propose something else.
(Standards still have a long way to go in computing. I can't imagine how difficult it would be to change tires without standardization! We would quickly go back to using horses...) -
DOS is old and not designed for accents and extended characters.
