删除双反斜杠C＃（用于ESC / POS编程）

Question

I've seached a long time, and it seems that my problem is world-wide known. But, all the answers that are given, won't work for me. Most of the time, people say 'there is no problem'.

The problem: I'm programming a POS solution, and I'm using a Epson POS printer. To print the buttom to the receipt, I'm storing a string in the database. This is, so users can adjust the text at the bottom of the receipt. But, when I'm pulling the string out of the database, C# adds slashes to the string, so my excape characters won't work. I know, that usualy is not a problem, but in my case it is, because my ECS/POS commands won't work.

I've already tried some scripts, which replaces the double \\ with a single \\, but they don't work. (eg. String.Replace(@'\\\\',@'\\').

Problem:

I have a sting: "foo \\n bar"

Needs to print as:

foo

bar

C# adds slashes: "foo \\\\n bar"

Now it's printed as: foo \\n bar

Anyone an idea?

Answer 1

The problem is a misunderstanding of how C# handles strings. Take the following sample code:

string foo = "a\nb";
int fooLength = foo.Length; \\ 3 characters.
int bar = (int)(foo[1]); \\ 10 = linefeed character.

versus:

string foo = @"a\nb"; \\ NB: @ prefix!
int fooLength = foo.Length; \\ 4 characters.
int bar = (int)(foo[1]); \\ 92 = backslash character.

The first example uses a string literal ( "a\\nb" ) which is interpreted by the C# compiler to yield three characters. The second example uses a verbatim string literal , due the prefix @, that suppresses the interpretation of the string.

Note that the debugger is designed to add to the confusion by displaying strings with escape codes added, eg string foo = "a\\nb" + (Char)9; results in a string that the debugger shows as "a\\nb\\t" . If you use the "text visualizer" in the debugger (by clicking on the magnifying glass when examining the the variable's value) you can see the difference between literal and interpreted characters.

Databases are, as a rule, designed to accept and return string values without interpretation. That way you needn't worry about names like "Delete D'table". Neither the presence of a SQL keyword, nor punctuation used in SQL statements, should present a problem in a data column.

Now the OP's issue should be becoming clearer. The string retrieved from the database does not contain a linefeed, but instead contains the characters '\\' and 'n'. .NET has no reason to change those values when the string is read from the database and written to a printer. Unfortunately, the debugger confounds the difference. (Use the text visualizer as described above.)

The solution involves adding code to reproduce the C# compiler's processing of escape sequences. (This should include escaping escape characters!) Alternatively, tokens can be added that are suitable for the application at hand, eg occurrences of «ESC» could be replaced with an ASCII escape character. This can be employed for longer sequences, for example if a print uses several characters to introduce a font change then write the code to replace «SetFont» with the correct sequence. More generally, you can replace a snippet with a dynamic value, eg «Now» could be replaced with the current date/time when the receipt is being printed. (Register number, cashier name, store hours, ... .) This makes the values in the database more human readable than embedded Unicode oddities and more flexible than fixed strings.

Left as an exercise for the reader: extend snippets to support formatting and null value substitution. «Now|DD.MM.YY hh:mm» to specify a format, «Discount|*|n/a» to specify a value ("n/a") to be displayed if the field is null.