Powershell Script does not Write Correct Umlauts - Powershell itself does - powershell

I want to dump (and later work with) the paths of the locally changed files in my SVN repository. Problem is, there are umlauts in some filenames (like ä, ö, ü).
When I open a powershell window in my lokal trunk folder, I can do svn status and get the result with correct umlauts ("ü" in this case):
PS C:\trunk> svn status -q
M Std\ClientComponents\Prüfung.xaml
M Std\ClientComponents\Prüfung.xaml.cs
M Std\ClientComponents\PrüfungViewModel.cs
When I do the same in my powershell script, the results are different.
Script "DumpChangedFiles.ps1":
foreach ( $filename in svn status -q )
{
Write-Host $filename
}
Results:
PS C:\trunk> .\DumpChangedFiles.ps1
M Std\ClientComponents\Pr³fung.xaml
M Std\ClientComponents\Pr³fung.xaml.cs
M Std\ClientComponents\Pr³fungViewModel.cs
Question: Why are the umlauts wrong? How do I get to the correct results?
Hex-Dump:
ef bb bf 4d 20 20 20 20 20 20 20 53 74 64 5c 43 6c 69 65 6e 74 43 6f 6d 70 6f 6e 65 6e 74 73 5c 50 72 c2 b3 66 75 6e 67 2e 78 61 6d 6c 0d 0a 4d 20 20 20 20 20 20 20 53 74 64 5c 43 6c 69 65 6e 74 43 6f 6d 70 6f 6e 65 6e 74 73 5c 50 72 c2 b3 66 75 6e 67 2e 78 61 6d 6c 2e 63 73 0d 0a 4d 20 20 20 20 20 20 20 53 74 64 5c 43 6c 69 65 6e 74 43 6f 6d 70 6f 6e 65 6e 74 73 5c 50 72 c2 b3 66 75 6e 67 56 69 65 77 4d 6f 64 65 6c 2e 63 73
Here's the output of the script DumpChangedFiles.ps1 compared to the output of your desired command:
PS C:\trunk> .\DumpChangedFiles.ps1
M Std\ClientComponents\Pr³fung.xaml
M Std\ClientComponents\Pr³fung.xaml.cs
M Std\ClientComponents\Pr³fungViewModel.cs
PS C:\trunk> $PSDefaultParameterValues['*:Encoding'] = 'utf8'; svn status -q
M Std\ClientComponents\Prüfung.xaml
M Std\ClientComponents\Prüfung.xaml.cs
M Std\ClientComponents\PrüfungViewModel.cs
Output of SVN--version is:
PS C:\trunk> svn --version
svn, version 1.14.0 (r1876290)
compiled May 24 2020, 17:07:49 on x86-microsoft-windows
Copyright (C) 2020 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/
The following repository access (RA) modules are available:
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- using serf 1.3.9 (compiled with 1.3.9)
- handles 'http' scheme
- handles 'https' scheme
The following authentication credential caches are available:
* Wincrypt cache in C:\Users\reichert\AppData\Roaming\Subversion

The problem comes from PowerShell ISE, the svn command in your script is executed through PowerShell ISE which encode its output with Windows-1252 (or your default windows locales).
You can go with the following to get a correct output (check your Windows locales) :
[Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding(1252)
foreach ( $filename in svn status -q )
{
Write-Host $filename
}
It seems a previous unanswered question relates to the same problem with ISE :
Powershell ISE has different codepage from Powershell and I can not change it

Related

Why don't I get output when I use __DATA__ in Perl?

Does anybody know if the Perl __DATA__ syntax on macOS Catalina is deprecated? I have perl v5.18.4 running, even a simple program like this gives no output (and no error either);
use strict;
use warnings;
while(<DATA>){
print $_;
}
__DATA__
line1
line2
line3
Edit:
This is weird. I said earlier that I have 2 Mac systems, both having the same problem. Not quite right, on one system the program works, on the other system the same program doesn’t.
Hexdump on both systems is the same:
Mac Mini:
Mac-mini-van-Theo:Programming theo$ hexdump -C test.pl
00000000 75 73 65 20 73 74 72 69 63 74 3b 0d 75 73 65 20 |use strict;.use |
00000010 77 61 72 6e 69 6e 67 73 3b 0d 77 68 69 6c 65 28 |warnings;.while(|
00000020 3c 44 41 54 41 3e 29 20 7b 0d 20 20 20 20 70 72 |<DATA>) {. pr|
00000030 69 6e 74 20 24 5f 3b 0d 7d 0d 5f 5f 44 41 54 41 |int $_;.}.__DATA|
00000040 5f 5f 0d 6c 69 6e 65 31 0d 6c 69 6e 65 32 0d 6c |__.line1.line2.l|
00000050 69 6e 65 33 0d |ine3.|
00000055
iMac:
Theo#iMac-van-Theo Programming % hexdump -C test.pl
00000000 75 73 65 20 73 74 72 69 63 74 3b 0a 75 73 65 20 |use strict;.use |
00000010 77 61 72 6e 69 6e 67 73 3b 0a 77 68 69 6c 65 28 |warnings;.while(|
00000020 3c 44 41 54 41 3e 29 7b 0a 20 20 20 20 70 72 69 |<DATA>){. pri|
00000030 6e 74 20 24 5f 3b 0a 7d 0a 0a 5f 5f 44 41 54 41 |nt $_;.}..__DATA|
00000040 5f 5f 0a 6c 69 6e 65 31 0a 6c 69 6e 65 32 0a 6c |__.line1.line2.l|
00000050 69 6e 65 33 0a |ine3.|
00000055
However, a 'cat’ or a ‘more’ shows differences:
Mac Mini:
Mac-mini-van-Theo:Programming theo$ more test.pl
use strict;^Muse warnings;^Mwhile(<DATA>) {^M print $_;^M}^M__DATA__^Mline1^Mline2^Mline3
iMac:
Theo#iMac-van-Theo Programming % more test.pl
use strict;
use warnings;
while(<DATA>){
print $_;
}
__DATA__
line1
line2
line3
The difference? The Mac Mini uses ‘bash’ as shell (where the program fails), the iMac uses ‘zsh’. So the problem is not really perl related but perl/shell related. With Catalina, Zsh is used as the default shell but the old Bash shell is still included with macOS and you can still switch to it. It seems to be related to how the shell handles line-endings, although I do not understand why this happens and moreover how to solve it.
__DATA__ is just fine, and there's no platform-specific issues with it (and there are lots of stupid tricks you can do with it).
However, if you want to know the state of any particular Perl thing, there's the perldeprecation docs. Sometimes perlexperiment is handy too.
How are you running your program?
Supply a hexdump of your program: hexdump -C program.pl. Maybe there are funny characters.

Can someone tell me why I am getting this error, is it because of the spacing (I know quotations matter)? [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 2 years ago.
Improve this question
create table product(
productid int,
description varchar(20)
);

insert into product (
productid,
description )
Values ( 42 , ' tv');
ERROR: column "description" of relation "product" does not exist
As several people pointed out in comments, there are invisible characters (sometimes called "gremlins") in your SQL that make it invalid. Here's a hex dump of the contents (after copying the code from the question, using macOS commands):
$ pbpaste | xxd -g1
00000000: 63 72 65 61 74 65 20 74 61 62 6c 65 20 70 72 6f create table pro
00000010: 64 75 63 74 28 0a 70 72 6f 64 75 63 74 69 64 20 duct(.productid
00000020: 69 6e 74 2c e2 80 a8 0a 64 65 73 63 72 69 70 74 int,....descript
^^ ^^ ^^ ^^^
00000030: 69 6f 6e 20 76 61 72 63 68 61 72 28 32 30 29 0a ion varchar(20).
00000040: 29 3b 0a e2 80 a8 69 6e 73 65 72 74 20 69 6e 74 );....insert int
00000050: 6f 20 70 72 6f 64 75 63 74 20 28 e2 80 a8 70 72 o product (...pr
00000060: 6f 64 75 63 74 69 64 2c e2 80 a8 64 65 73 63 72 oductid,...descr
^^ ^^ ^^ ^^^
00000070: 69 70 74 69 6f 6e 20 29 e2 80 a8 56 61 6c 75 65 iption )...Value
^^ ^^ ^^ ^^^
00000080: 73 20 28 20 34 32 20 2c 20 27 20 74 76 27 29 3b s ( 42 , ' tv');
00000090: 0a 45 52 52 4f 52 3a 20 20 63 6f 6c 75 6d 6e 20 .ERROR: column
000000a0: 22 64 65 73 63 72 69 70 74 69 6f 6e 22 20 6f 66 "description" of
000000b0: 20 72 65 6c 61 74 69 6f 6e 20 22 70 72 6f 64 75 relation "produ
000000c0: 63 74 22 20 64 6f 65 73 20 6e 6f 74 20 65 78 69 ct" does not exi
000000d0: 73 74 st
(Note that xxd represents bytes that don't correspond to printable ASCII characters as "." in the text display on the right. The "."s that correspond to 0a in hex are newline characters.)
The hex codes e2 80 a8 correspond to the UTF-8 encoding of the unicode "line separator" character. I don't know how that character got in there; you'd have to trace back the origin of that code snippet to figure out where they were added.
I'd avoid using TextEdit for source code (and config files, etc) . Instead, I'd recommend using BBEdit or some other code-oriented editor. I think even in BBEdit's free-demo mode it can show (and let you remove) normally-invisible characters by choosing View menu -> Text Display -> Show Invisibles.
You can also remove non-plain-ASCII characters from a text file from the macOS Terminal with:
LC_ALL=C tr -d '\n\t -~' <infile.txt >cleanfile.txt
(Replacing infile.txt and cleanfile.txt with the paths/names of the input file and where you want to store the output.) Warning: do not try to write the cleaned contents back to the original file, that won't work. Also, don't use this to clean anything except plain text files (if the file has any sections that aren't supposed to be text sections, this may mangle those sections). Keep the original file as a backup until you've verified that the "clean" version works right.
You can also "clean" the paste buffer with:
pbpaste | LC_ALL=C tr -d '\n\t -~' | pbcopy
...so just copy the relevant code from your text editor, run that in Terminal, then paste the cleaned version back into the editor.

Copying a CSV file from stdin throws "missing data for column"

I have some data that has been exported from postgres, reworked a bit using a spreadsheet and I know want the data back into a table, but I keep failing on the import:
cat extract.csv | psql -h 10.135.0.44 myapp myapp -f copy-user.sql`
psql:copy-user.sql:7: ERROR: missing data for column "email"
CONTEXT: COPY to_update, line 1: ""
The actual data is supplied below. I first converted the CSV file from DOS to Unix style line endings. It didn't seem to matter much.
copy-user.sql
COPY "to_update"
FROM STDIN
WITH DELIMITER ';' CSV;
extract.csv
bfb92e29-1d2c-45c4-b9ab-357a3ac7ad13;test#test90239023783457843.com;x
aeccc3ea-cc1f-43ef-99ff-e389d5d63b22;tester#testerkjnaefgjnwerg.no;x
9cec13ae-c880-4371-9b1c-dd201f5cf233;bloblo#gmail.com;x
aeada2bc-a362-4f3e-80f2-06a717206802;vet#gmail.com;x
fb85ddd8-7d17-4d41-8bc3-213b1e469506;navnnavnesen#ptflow.com;x
528e1f2e-1baa-483b-bc8c-85f993014696;kklk#hotmail.com;x
dbc8a9c1-56cf-4589-8b2c-cf1a2e0832ed;ghiiii#hotmail.com;x
fbf23553-baa2-410a-8f96-32b5c4deb0c7;lala#lala.no;x
e22ec0de-06f9-428a-aa3e-171c38f9a1f7;x2#gmail.com;x
8e8d0f73-8eb7-43b4-8019-b79042731b97;mail#mail.com;x
table definition for to_update
create table to_update(id text, email text, text char);
-- also tried this variant, but same error
-- create table to_update(id uuid, email text, text char);
EDIT: Additional info
It seems this exact same thing doesn't throw on my local machine:
$ cat extract.csv | psql postgres -f copy-user.sql
Timing is on.
Line style is unicode.
Border style is 2.
Null display is "[NULL]".
Expanded display is used automatically.
COPY 0
Time: 0.430 ms
It still doesn't work (as it just copies 0 rows), but at least it doesn't throw an error. That points to it being related to the environment (versions, locale settings, etc).
Local machine (which doesn't throw error)
$ psql --version
psql (PostgreSQL) 10.6
$ psql postgres -c "SHOW server_version;"
Timing is on.
Line style is unicode.
Border style is 2.
Null display is "[NULL]".
Expanded display is used automatically.
┌────────────────┐
│ server_version │
├────────────────┤
│ 10.6 │
└────────────────┘
(1 row)
Time: 40.960 ms
$ printenv | grep LC
LC_CTYPE=UTF-8
Remote server(s) (which throws error)
$ psql --version # this is the client, not the same physical server as the db
psql (PostgreSQL) 9.5.12
$ psql -h 10.135.0.44 myapp myapp -c "SHOW server_version;"
Password for user pete:
server_version
----------------
9.5.12
(1 row)
$ printenv | grep LC
LC_ALL=C.UTF-8
LC_CTYPE=UTF-8
LANG=C.UTF-8
Hex dump of extract.csv (all 7 lines)
$ wc -l extract.csv
10 extract.csv
$ hexdump -C extract.csv
00000000 62 66 62 39 32 65 32 39 2d 31 64 32 63 2d 34 35 |bfb92e29-1d2c-45|
00000010 63 34 2d 62 39 61 62 2d 33 35 37 61 33 61 63 37 |c4-b9ab-357a3ac7|
00000020 61 64 31 33 3b 74 65 73 74 40 74 65 73 74 39 30 |ad13;test#test90|
00000030 32 33 39 30 32 33 37 38 33 34 35 37 38 34 33 2e |239023783457843.|
00000040 63 6f 6d 3b 78 0a 61 65 63 63 63 33 65 61 2d 63 |com;x.aeccc3ea-c|
00000050 63 31 66 2d 34 33 65 66 2d 39 39 66 66 2d 65 33 |c1f-43ef-99ff-e3|
00000060 38 39 64 35 64 36 33 62 32 32 3b 74 65 73 74 65 |89d5d63b22;teste|
00000070 72 40 74 65 73 74 65 72 6b 6a 6e 61 65 66 67 6a |r#testerkjnaefgj|
00000080 6e 77 65 72 67 2e 6e 6f 3b 78 0a 39 63 65 63 31 |nwerg.no;x.9cec1|
00000090 33 61 65 2d 63 38 38 30 2d 34 33 37 31 2d 39 62 |3ae-c880-4371-9b|
000000a0 31 63 2d 64 64 32 30 31 66 35 63 66 32 33 33 3b |1c-dd201f5cf233;|
000000b0 62 6c 6f 62 6c 6f 40 67 6d 61 69 6c 2e 63 6f 6d |bloblo#gmail.com|
000000c0 3b 78 0a 61 65 61 64 61 32 62 63 2d 61 33 36 32 |;x.aeada2bc-a362|
000000d0 2d 34 66 33 65 2d 38 30 66 32 2d 30 36 61 37 31 |-4f3e-80f2-06a71|
000000e0 37 32 30 36 38 30 32 3b 76 65 74 40 67 6d 61 69 |7206802;vet#gmai|
000000f0 6c 2e 63 6f 6d 3b 78 0a 66 62 38 35 64 64 64 38 |l.com;x.fb85ddd8|
00000100 2d 37 64 31 37 2d 34 64 34 31 2d 38 62 63 33 2d |-7d17-4d41-8bc3-|
00000110 32 31 33 62 31 65 34 36 39 35 30 36 3b 6e 61 76 |213b1e469506;nav|
00000120 6e 6e 61 76 6e 65 73 65 6e 40 70 74 66 6c 6f 77 |nnavnesen#ptflow|
00000130 2e 63 6f 6d 3b 78 0a 35 32 38 65 31 66 32 65 2d |.com;x.528e1f2e-|
00000140 31 62 61 61 2d 34 38 33 62 2d 62 63 38 63 2d 38 |1baa-483b-bc8c-8|
00000150 35 66 39 39 33 30 31 34 36 39 36 3b 6b 6b 6c 6b |5f993014696;kklk|
00000160 40 68 6f 74 6d 61 69 6c 2e 63 6f 6d 3b 78 0a 64 |#hotmail.com;x.d|
00000170 62 63 38 61 39 63 31 2d 35 36 63 66 2d 34 35 38 |bc8a9c1-56cf-458|
00000180 39 2d 38 62 32 63 2d 63 66 31 61 32 65 30 38 33 |9-8b2c-cf1a2e083|
00000190 32 65 64 3b 67 68 69 69 69 69 40 68 6f 74 6d 61 |2ed;ghiiii#hotma|
000001a0 69 6c 2e 63 6f 6d 3b 78 0a 66 62 66 32 33 35 35 |il.com;x.fbf2355|
000001b0 33 2d 62 61 61 32 2d 34 31 30 61 2d 38 66 39 36 |3-baa2-410a-8f96|
000001c0 2d 33 32 62 35 63 34 64 65 62 30 63 37 3b 6c 61 |-32b5c4deb0c7;la|
000001d0 6c 61 40 6c 61 6c 61 2e 6e 6f 3b 78 0a 65 32 32 |la#lala.no;x.e22|
000001e0 65 63 30 64 65 2d 30 36 66 39 2d 34 32 38 61 2d |ec0de-06f9-428a-|
000001f0 61 61 33 65 2d 31 37 31 63 33 38 66 39 61 31 66 |aa3e-171c38f9a1f|
00000200 37 3b 78 32 40 67 6d 61 69 6c 2e 63 6f 6d 3b 78 |7;x2#gmail.com;x|
00000210 0a 38 65 38 64 30 66 37 33 2d 38 65 62 37 2d 34 |.8e8d0f73-8eb7-4|
00000220 33 62 34 2d 38 30 31 39 2d 62 37 39 30 34 32 37 |3b4-8019-b790427|
00000230 33 31 62 39 37 3b 6d 61 69 6c 40 6d 61 69 6c 2e |31b97;mail#mail.|
00000240 63 6f 6d 3b 78 0a |com;x.|
00000246
I think you want \copy ... from pstdin... on a single line. Both the starting backslash and pstdin instead of stdin are on purpose.
This mailing-list thread: psql -f COPY from STDIN explains the problem and the solution.
COPY FROM STDIN expects data inline after the COPY command, as in a dump file, not from the standard input of the psql process.
Relevant snippet from the mailing list summing up the alternatives
I'd like the store the COPY command in a separate file without
specifying an input file name. I want to feed it the data from the
shell script that calls psql
"STDIN: All rows are read from the same source that issued the
command"
- As I understand now, this applies to both COPY and \COPY. In other words the input file must contain command and data.
I have found a few solutions to achieve my objective:
1) using COPY FROM STDIN cat event.csv | psql -c "$(cat event.sql)"
2) using COPY FROM STDIN psql -f <(cat event.sql event.csv)
3) using \COPY FROM PSTDIN cat event.csv | psql -f event.sql
4) using \COPY FROM STDIN psql -f <(cat event.sql event.csv <(echo
"."))
What I don't like about \COPY is that it has to be on one line. Indeed
it can't be split over multiple lines
following works in my setup:
cat extract.csv | psql -d db_name -U user_name -c "copy to_update from stdin with delimiter ';' csv"
or
psql -d db_name -U user_name -c "\copy public.to_update(id, email, text) from '/path_to/extract.csv' with delimiter ';' csv"
With regards to the actual thrown error, after some debugging, I found that this error only happens with Postgres 9.5.12, not my local database running 10.6. That's using the exact same script in the sql file.
Postgres 9.5.12 doesn't handle multi-line COPY FROM STDIN statements! Deleting the newlines so that the entire expression was on a single line made it run. It still didn't work, though, as it still showed 0 rows being copied, but that is really a different question ... Krishna was onto something though ... I'll post a separate question for that and link it up.

Can I tell GitHub (or eq.) to use ASCII to make my binary files readable?

I want to host a binary file on a web-based hosting service for git (i.e. GitHub) so I can easily see any changes made to it.
The binary file in question uses the common ASCII character encoding so that this binary
73 63 6F 70 65 20 68 75 72 72 72 20 69 6E 69 74 69 61 6C 69 7A 65 72 20 64 65 72 70 0D 0A 20 20 20 20 66 75 6E 63 74 69 6F 6E 20 64 65 72 70 20 74 61 6B 65 73 20 6E 6F 74 68 69 6E 67 20 72 65 74 75 72 6E 73 20 6E 6F 74 68 69 6E 67 0D 0A 20 20 20 20 20 20 20 20 63 61 6C 6C 20 53 65 74 53 74 61 72 74 4C 6F 63 50 72 69 6F 28 24 42 2C 24 41 2C 24 41 2C 4D 41 50 5F 4C 4F 43 5F 50 52 49 4F 5F 48 49 47 48 29 0D 0A 20 20 20 20 65 6E 64 66 75 6E 63 74 69 6F 6E 0D 0A 65 6E 64 73 63 6F 70 65
becomes this readable text (†)
scope hurrr initializer derp
function derp takes nothing returns nothing
call SetStartLocPrio($B,$A,$A,MAP_LOC_PRIO_HIGH)
endfunction
endscope
The problem is that services like GitHub will only show me the raw binary when I want to view the file in-browser (or have me download and open it in a text editor):
Right now, to have any changes made, I have to download the changed binary file, convert it to readable text, then use diff to see what changes have been made. This is tedious and loses the beautiful web interface that GitHub has.
So my question is this: Can I tell GitHub (or any equivalent service) to translate a binary file to readable text?
--
(†) For anyone interested in trivia, this is indeed vJass syntax for WarCraft III.

Base64 encode - decode issue

I read that Base64 is deterministic algorithm, and produce unique results. Consider these two encoded base64 values:
KFNjcmlwdCBYU1MpIFVSTDogaHR0cDovL2xvY2FsaG9zdDo4MDgwL2h0bWxQYXJzZXIvLiB8IElEOiBUaGlzIGlzIElEMC4gfCBDbGFzczogVW5hdmFpbGFibGUuLiB8IFRleHQgQ29udGVudDogCgogICAgRGF0YTogPGlucHV0IG1heGxlbmd0aD0iOTk5OTkiIG5hbWU9ImRhdGEiIHR5cGU9InRleHQiPiA8YnI+CiAgICA8aW5wdXQgdmFsdWU9InN1Ym1pdCIgdHlwZT0ic3VibWl0Ij4KICAgIAogIDxpbnB1dCBvbmNsaWNrPSJqYXZhc2NyaXB0OmFsZXJ0KCdJbnB1dCBJRCBYU1MgLSBtb3VzZWNsaWNrJykiIGF1dG9mb2N1cz0iIj4gIAogICAgIAogICA8c2NyaXB0IGNsYXNzPSJmZmYiPmphdmFzY3JpcHQ6YWxlcnQoJ1NjcmlwdCBGT1JNIFhTUycpPC9zY3JpcHQ+
&
KFNjcmlwdCBYU1MpIFVSTDogaHR0cDovL2xvY2FsaG9zdDo4MDgwL2h0bWxQYXJzZXIvLiB8IElEOiBUaGlzIGlzIElEMC4gfCBDbGFzczogVW5hdmFpbGFibGUuLiB8IFRleHQgQ29udGVudDogDQoNCiAgICBEYXRhOiA8aW5wdXQgbWF4bGVuZ3RoPSI5OTk5OSIgbmFtZT0iZGF0YSIgdHlwZT0idGV4dCI+IDxicj4NCiAgICA8aW5wdXQgdmFsdWU9InN1Ym1pdCIgdHlwZT0ic3VibWl0Ij4NCiAgICANCiAgPGlucHV0IG9uY2xpY2s9ImphdmFzY3JpcHQ6YWxlcnQoJ0lucHV0IElEIFhTUyAtIG1vdXNlY2xpY2snKSIgYXV0b2ZvY3VzPSIiPiAgDQogICAgIA0KICAgPHNjcmlwdCBjbGFzcz0iZmZmIj5qYXZhc2NyaXB0OmFsZXJ0KCdTY3JpcHQgRk9STSBYU1MnKTwvc2NyaXB0Pg==
These both give me same decoded output. How is this possible? I couldn't find any visible difference between decoded format of these two values.
Is it related to encoding and decoding schemes like UTF 8 and ASCII?
Decoded strings are different -- they have different CR/LF sequences at the end of lines: \n\n (0a0a) vs \r\n\r\n (0d0a0d0a):
00000060 20 54 65 78 74 20 43 6f 6e 74 65 6e 74 3a 20 0a | Text Content: .|
00000070 0a 20 20 20 20 44 61 74 61 3a 20 3c 69 6e 70 75 |. Data: <inpu|
00000060 20 54 65 78 74 20 43 6f 6e 74 65 6e 74 3a 20 0d | Text Content: .|
00000070 0a 0d 0a 20 20 20 20 44 61 74 61 3a 20 3c 69 6e |... Data: <in|
Hint: use hexdump -C <file> to get such output.