2

I am having problems with the chr() function. My code first takes the user input, puts it into an array and then uses the ord function to convert it to the corresponding number value and does the same with a keyword. It then uses the zip function to add both arrays together to get numbers and uses the chr function on it to put it back to text. The problem is that the chr function outputs incorrectly

E.g

the number value of c is 99

the number valueof h is 104

They add together to make 203

my code outputs \xcb

when I made a separate code that is just

leb = chr(203)
print leb

That outputs 203 as Ë which is a singular character and what I need for decoding it

Here is my code

num_string = raw_input("enter what you would like to encrypt")
num_list = []
for num in num_string:
    num_list.append(ord(num)) 
    print num_list

key_string = raw_input("enter the keyword")
key_list = []
for key in key_string:
   key_string = key_list.append(ord(key)) 
   print key_list

end_string = [x + y for x, y in zip(num_list, key_list)]
end_list = []
print end_string
for end in end_string:
    end_list.append(chr(end)) 
print end_list

When this is run this is the output

enter what you would like to encrypt cat

[99]

[99, 97]

[99, 97, 116]

enter the keywordhat

[104]

[104, 97]

[104, 97, 116]

[203, 194, 232]

['\xcb', '\xc2', '\xe8']

Why is my code doing this and how do I fix this?

Community
  • 1
  • 1
  • ASCII codes run up to 127 – Pynchia Nov 23 '15 at 14:55
  • I don't know what ascii table you're looking at but even with the extended ascii table 203 doesn't equal Ë. http://www.asciitable.com/ – SirParselot Nov 23 '15 at 14:57
  • What you expect is the the character `\xcb` in a special codepage. Nothing is wrong, just your expectation of the result. – Klaus D. Nov 23 '15 at 14:58
  • Printing a list uses `__repr__`, not `__str__`, to display the contents of the list. – chepner Nov 23 '15 at 15:10
  • @Pynchia: ASCII codes run up to 127, but Python allows simple byte characters in range [0-255]. The lower part in ASCII, interpretation or the upper part depends on the system encoding. In latin1, code 0xcb (203) **is** the character `u'\xcb'` or `Ë` – Serge Ballesta Nov 23 '15 at 15:32

2 Answers2

2

All is perfectly normal. It is just the difference between the value of a string (with quotes around) and the printing of the string after converting it in the system code page. In latin1 code page, the character '\xcb' (code 203) effectively prints as a Ë.

But printing a list is not the same as printing its values, lets forget for characters using codes above 127, and just look at this:

>>> l = [ 'a', 'b', 'c']
>>> print l
['a', 'b', 'c']
>>> print ','.join(l)
a,b,c

So when printing a list of strings, Python prints each element in its representation form, that is enclosed in quote. So in your example, (assuming your system encoding is latin1), you can write:

...
print end_list
print ''.join(end_list)

and you will get as expected:

['\xcb', '\xc2', '\xe8']
ËÂè
Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
1

As suggested in this SO question(python: extended ASCII codes), there is no such thing as "extended Ascii".

The output is correct( \xcb = 12 * 2^4 + 11 * 2^0), but it is apparently not the encoding you are looking for, so you may want to figure out what encoding it is you are looking for and then consult the Python documentation of the built-in encode function.

Community
  • 1
  • 1
MTTI
  • 391
  • 2
  • 10
  • I made a separate piece of code and used chr on 203 which outputted Ë. So why does it output /xcb in this piece of code. Why is chr giving two different answers when given the same number? – CoolestKidAround Nov 23 '15 at 15:20