ASCII / ANSI编码 [英] ASCII / ANSI encoding

查看:77
本文介绍了ASCII / ANSI编码的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述




我正在使用旧的基于DOS的

SunAccounts系统转换数据(不要请问!)进入SQL Server。


数据已作为数百个SunAccounts

备份文件的集合发送给我,它很简单(然而非常费力!)依次打开每个备份文件的过程,逐行读取文件,将其分成

到其组成部分,然后喷入SQL Server。


但是,我遇到了一个问题,因为Sun是一个基于DOS的系统,

使用ASCII编码。具体来说,英镑的旧栗子

标志,Sun认为是十六进制9c(即Alt-156)。但是,使用ANSI编码的Windows

将此字符视为o而不是£(Alt-163)。


如果我将文件打开到StreamReader对象而没有指定

编码,C#似乎使用ASCII编码。这具有

的效果,完全忽略了这个字符,反过来又会抛出剩余的

导入的内容,因为文件格式是固定宽度的,不是分隔的。


因此,任何人都可以告诉我在将文件读入StreamReader对象时我应该使用什么编码?我已经尝试了几个,但到目前为止,似乎没有人能够正常工作。有些人将角色渲染为问号或

空白方块,虽然不正确,但至少不会停止其余的工作...... 。


感激不尽的任何帮助。


马克

解决方案

< blockquote>嗨Mark,

我经历过这样的痛苦,但我的问题却没有什么不同。好吧

老兄我会说你不能在你的情况下使用StreamReader。你必须使用BinaryReader读取整个文件,而不是使用

System.Text.ASCIIEncoding将数据恢复为WINDOWS ASCII

格式。


这应该可行。




Mark Rae写道:



如果从旧的DOS转换数据,我正在进行中基于
SunAccounts系统(不要问!)进入SQL Server。

这些数据已作为数百个SunAccounts
备份文件的集合发送给我了。一个简单(但非常费力!)的过程依次打开每个备份文件,逐行读取文件,将其拆分成组成部分,然后将其喷入SQL Server。但是,我遇到了一个问题,因为Sun是一个基于DOS的系统,它使用ASCII编码。具体来说,英镑的旧栗子标志,太阳认为是十六进制9c(即Alt-156)。


ASCII是一个7位字符系统,并没有定义任何字符

代码高于127(十六进制7F)。谷歌快速戳了一下,表示9C

是微软DOS代码页437中的英镑符号。嗯,或者说是850.

看看< http ://en.wikipedia.org/wiki/Category:DOS_code_pages>

及其中的链接自行决定。

但是,Windows
使用ANSI编码看到这个字符为o而不是£(Alt-163)。


我真的不是这方面的专家,但我很确定

''使用ANSI编码的Windows''不是'''具体到足以令人尴尬。

如果我在没有指定
编码的情况下将文件打开到StreamReader对象中,C#似乎使用ASCII编码。这样就可以完全忽略角色,这反过来会抛出其余的导入,因为文件格式是固定宽度的,不是分隔的。
因此,任何人都可以告诉我在将文件读入StreamReader对象时应该使用什么编码?


如果我对原始编码是DOS代码页437是正确的,你

应该使用由

创建的编码System.Text.Encoding.GetEncoding(437)。或者尝试850.

我已经尝试了几个,但到目前为止没有一个可以正常工作。有些人将角色渲染为问号或空白正方形,虽然不正确,但至少不能阻止其他人继续工作......
感激不尽的任何帮助。




编码是一场噩梦。祝你好运!


-

Larry Lard

回复团体请


" Larry Lard" < LA ******* @ hotmail.com>在消息中写道

news:11 ******************** @ g49g2000cwa.googlegrou ps.com ...


嗨Larry,

System.Text.Encoding.GetEncoding(437)




工作得很好!非常感谢。


Mark


Hi,

I''m in the process if converting the data out of an old DOS-based
SunAccounts system (don''t ask!) into SQL Server.

The data has been sent to me as a collection of hundreds of SunAccounts
backup files and it''s a simple (yet extremely laborious!) process of opening
each backup file in turn, reading the file line by line, splitting it up
into its constituent parts, and then squirting it into SQL Server.

However, I''m experiencing a problem because Sun, being a DOS-based system,
uses ASCII encoding. Specifically, the old chestnut of the British pound
sign, which Sun considers to be hex 9c (i.e. Alt-156). However, Windows
using ANSI encoding sees this character as o instead of £ (Alt-163).

If I open the files into a StreamReader object without specifying an
encoding, C# appears to be using ASCII encoding. This has the effect of
ignoring the character completely which, in turn, throws the rest of the
import of of kilter because the file format is fixed-width, not delimted.

Therefore, can anyone please tell me what encoding I should use when reading
the file into a StreamReader object? I''ve tried several, but none appears to
work correctly so far. Some render the character as a question mark or a
blank square which, although not correct, at least doesn''t stop the rest of
the import from working...

Any assistance gratefully received.

Mark

解决方案

hi Mark,
i''ve gone through such pain but my problem was little different. well
dude i would say you can not use StreamReader in your case. you have to
use BinaryReader to read whole file and than should use
"System.Text.ASCIIEncoding" to retrive the data into the WINDOWS ASCII
format.

this should work.



Mark Rae wrote:

Hi,

I''m in the process if converting the data out of an old DOS-based
SunAccounts system (don''t ask!) into SQL Server.

The data has been sent to me as a collection of hundreds of SunAccounts
backup files and it''s a simple (yet extremely laborious!) process of opening
each backup file in turn, reading the file line by line, splitting it up
into its constituent parts, and then squirting it into SQL Server.

However, I''m experiencing a problem because Sun, being a DOS-based system,
uses ASCII encoding. Specifically, the old chestnut of the British pound
sign, which Sun considers to be hex 9c (i.e. Alt-156).
ASCII is a 7-bit character system, and does not define any character
code higher than 127 (hex 7F). A quick poke at Google suggests that 9C
is the pound sign in Microsoft''s DOS codepage 437. Hmm, or maybe 850.
Take a look at <http://en.wikipedia.org/wiki/Category:DOS_code_pages>
and links therefrom to decide for yourself.
However, Windows
using ANSI encoding sees this character as o instead of £ (Alt-163).
I''m really no expert on these matters, but I''m fairly sure that
''Windows using ANSI encoding'' isn''t specific enough to be amgibuous.

If I open the files into a StreamReader object without specifying an
encoding, C# appears to be using ASCII encoding. This has the effect of
ignoring the character completely which, in turn, throws the rest of the
import of of kilter because the file format is fixed-width, not delimted.

Therefore, can anyone please tell me what encoding I should use when reading
the file into a StreamReader object?
If I''m right about the original encoding being DOS codepage 437, you
should use the Encoding created by
System.Text.Encoding.GetEncoding(437). Or try 850.
I''ve tried several, but none appears to
work correctly so far. Some render the character as a question mark or a
blank square which, although not correct, at least doesn''t stop the rest of
the import from working...

Any assistance gratefully received.



Encodings are a nightmare. Best of luck!

--
Larry Lard
Replies to group please


"Larry Lard" <la*******@hotmail.com> wrote in message
news:11********************@g49g2000cwa.googlegrou ps.com...

Hi Larry,

System.Text.Encoding.GetEncoding(437)



Worked perfectly! Thanks very much.

Mark


这篇关于ASCII / ANSI编码的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆