Line ending charactor LFs are automatically changed to CRLFs in HTML textarea
I noticed that all LFs are automatically changed to CRLFs if I put them into a HTML textarea.
■ Questions:
where and what causes this behavior?
- is this because of Windows Operation system, i.e. it will not happen if using a different Operating system such as MacOS? (I just experienced this on a windows machine, not yet tested on a Mac though...)
- or is this something which depends on Browser? (I have seen this behavior on Chrome, IE, and Firefox. Not yet tested on Safari...)
- or is this something only happens on my editor? (i.e I am using sakura editor)
If possible, how to preserve the LF so that it does not get changed into CRLF?
■ Steps to reproduce this:
find a textarea where you can input, for example the following w3school website.
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textareaprepare a text that at least 2 lines with some LFs using an editor which can detect the line ending charactors (so that you can make sure you have some LFs).
※ I am using Sakura editor as an example.copy and paste the text prepared in step 2 to the textarea.
once text is copied into the textarea, this time, copy the entire content of the textarea.
paste the content of the textarea back to your editor.
the line ending characters all become CRLFs.
■ P.S.
Please see the screenshots for details
- left side is original text with 3 LFs
- right side is the content copied back from the textarea and all LFs becomes CRLFs)
- 「↓」indicated LF
- 「⏎」indicated CRLF
Thanks
html browser operating-system textarea text-editor
add a comment |
I noticed that all LFs are automatically changed to CRLFs if I put them into a HTML textarea.
■ Questions:
where and what causes this behavior?
- is this because of Windows Operation system, i.e. it will not happen if using a different Operating system such as MacOS? (I just experienced this on a windows machine, not yet tested on a Mac though...)
- or is this something which depends on Browser? (I have seen this behavior on Chrome, IE, and Firefox. Not yet tested on Safari...)
- or is this something only happens on my editor? (i.e I am using sakura editor)
If possible, how to preserve the LF so that it does not get changed into CRLF?
■ Steps to reproduce this:
find a textarea where you can input, for example the following w3school website.
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textareaprepare a text that at least 2 lines with some LFs using an editor which can detect the line ending charactors (so that you can make sure you have some LFs).
※ I am using Sakura editor as an example.copy and paste the text prepared in step 2 to the textarea.
once text is copied into the textarea, this time, copy the entire content of the textarea.
paste the content of the textarea back to your editor.
the line ending characters all become CRLFs.
■ P.S.
Please see the screenshots for details
- left side is original text with 3 LFs
- right side is the content copied back from the textarea and all LFs becomes CRLFs)
- 「↓」indicated LF
- 「⏎」indicated CRLF
Thanks
html browser operating-system textarea text-editor
add a comment |
I noticed that all LFs are automatically changed to CRLFs if I put them into a HTML textarea.
■ Questions:
where and what causes this behavior?
- is this because of Windows Operation system, i.e. it will not happen if using a different Operating system such as MacOS? (I just experienced this on a windows machine, not yet tested on a Mac though...)
- or is this something which depends on Browser? (I have seen this behavior on Chrome, IE, and Firefox. Not yet tested on Safari...)
- or is this something only happens on my editor? (i.e I am using sakura editor)
If possible, how to preserve the LF so that it does not get changed into CRLF?
■ Steps to reproduce this:
find a textarea where you can input, for example the following w3school website.
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textareaprepare a text that at least 2 lines with some LFs using an editor which can detect the line ending charactors (so that you can make sure you have some LFs).
※ I am using Sakura editor as an example.copy and paste the text prepared in step 2 to the textarea.
once text is copied into the textarea, this time, copy the entire content of the textarea.
paste the content of the textarea back to your editor.
the line ending characters all become CRLFs.
■ P.S.
Please see the screenshots for details
- left side is original text with 3 LFs
- right side is the content copied back from the textarea and all LFs becomes CRLFs)
- 「↓」indicated LF
- 「⏎」indicated CRLF
Thanks
html browser operating-system textarea text-editor
I noticed that all LFs are automatically changed to CRLFs if I put them into a HTML textarea.
■ Questions:
where and what causes this behavior?
- is this because of Windows Operation system, i.e. it will not happen if using a different Operating system such as MacOS? (I just experienced this on a windows machine, not yet tested on a Mac though...)
- or is this something which depends on Browser? (I have seen this behavior on Chrome, IE, and Firefox. Not yet tested on Safari...)
- or is this something only happens on my editor? (i.e I am using sakura editor)
If possible, how to preserve the LF so that it does not get changed into CRLF?
■ Steps to reproduce this:
find a textarea where you can input, for example the following w3school website.
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textareaprepare a text that at least 2 lines with some LFs using an editor which can detect the line ending charactors (so that you can make sure you have some LFs).
※ I am using Sakura editor as an example.copy and paste the text prepared in step 2 to the textarea.
once text is copied into the textarea, this time, copy the entire content of the textarea.
paste the content of the textarea back to your editor.
the line ending characters all become CRLFs.
■ P.S.
Please see the screenshots for details
- left side is original text with 3 LFs
- right side is the content copied back from the textarea and all LFs becomes CRLFs)
- 「↓」indicated LF
- 「⏎」indicated CRLF
Thanks
html browser operating-system textarea text-editor
html browser operating-system textarea text-editor
asked Nov 14 '18 at 10:41
zaozaoer
7210
7210
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I think I find myself the answer at least some helpful information, i will just leave a record in case there are people seeking for the answer for similar questions.
- where and what causes this behavior?
For historical reasons, the element’s value is normalized in three different ways for three different purposes. The raw value is the value as it was originally set. It is not normalized. The API value is the value used in the value IDL attribute. It is normalized so that line breaks use U+000A LINE FEED (LF) characters. Finally, there is the value, as used in form submission and other processing models in this specification. It is normalized so that line breaks use U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs, and in addition, if necessary given the element’s wrap attribute, additional line breaks are inserted to wrap the text at the given width.
for more information please read:
https://www.w3.org/TR/html5/forms.html#the-textarea-element
- If possible, how to preserve the LF so that it does not get changed into CRLF?
I guess there are a lot of ways. Using javascript to replace all /r/n to /n before submit a form will likely be a client side solution. or if it doesn't have the necessity to be handled on client side which is exactly my case, I do the replacement process on the server side to force convert all line ending characters to LF.
- If possible, how to preserve the LF so that it does not get changed into CRLF?
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53298285%2fline-ending-charactor-lfs-are-automatically-changed-to-crlfs-in-html-textarea%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think I find myself the answer at least some helpful information, i will just leave a record in case there are people seeking for the answer for similar questions.
- where and what causes this behavior?
For historical reasons, the element’s value is normalized in three different ways for three different purposes. The raw value is the value as it was originally set. It is not normalized. The API value is the value used in the value IDL attribute. It is normalized so that line breaks use U+000A LINE FEED (LF) characters. Finally, there is the value, as used in form submission and other processing models in this specification. It is normalized so that line breaks use U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs, and in addition, if necessary given the element’s wrap attribute, additional line breaks are inserted to wrap the text at the given width.
for more information please read:
https://www.w3.org/TR/html5/forms.html#the-textarea-element
- If possible, how to preserve the LF so that it does not get changed into CRLF?
I guess there are a lot of ways. Using javascript to replace all /r/n to /n before submit a form will likely be a client side solution. or if it doesn't have the necessity to be handled on client side which is exactly my case, I do the replacement process on the server side to force convert all line ending characters to LF.
- If possible, how to preserve the LF so that it does not get changed into CRLF?
add a comment |
I think I find myself the answer at least some helpful information, i will just leave a record in case there are people seeking for the answer for similar questions.
- where and what causes this behavior?
For historical reasons, the element’s value is normalized in three different ways for three different purposes. The raw value is the value as it was originally set. It is not normalized. The API value is the value used in the value IDL attribute. It is normalized so that line breaks use U+000A LINE FEED (LF) characters. Finally, there is the value, as used in form submission and other processing models in this specification. It is normalized so that line breaks use U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs, and in addition, if necessary given the element’s wrap attribute, additional line breaks are inserted to wrap the text at the given width.
for more information please read:
https://www.w3.org/TR/html5/forms.html#the-textarea-element
- If possible, how to preserve the LF so that it does not get changed into CRLF?
I guess there are a lot of ways. Using javascript to replace all /r/n to /n before submit a form will likely be a client side solution. or if it doesn't have the necessity to be handled on client side which is exactly my case, I do the replacement process on the server side to force convert all line ending characters to LF.
- If possible, how to preserve the LF so that it does not get changed into CRLF?
add a comment |
I think I find myself the answer at least some helpful information, i will just leave a record in case there are people seeking for the answer for similar questions.
- where and what causes this behavior?
For historical reasons, the element’s value is normalized in three different ways for three different purposes. The raw value is the value as it was originally set. It is not normalized. The API value is the value used in the value IDL attribute. It is normalized so that line breaks use U+000A LINE FEED (LF) characters. Finally, there is the value, as used in form submission and other processing models in this specification. It is normalized so that line breaks use U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs, and in addition, if necessary given the element’s wrap attribute, additional line breaks are inserted to wrap the text at the given width.
for more information please read:
https://www.w3.org/TR/html5/forms.html#the-textarea-element
- If possible, how to preserve the LF so that it does not get changed into CRLF?
I guess there are a lot of ways. Using javascript to replace all /r/n to /n before submit a form will likely be a client side solution. or if it doesn't have the necessity to be handled on client side which is exactly my case, I do the replacement process on the server side to force convert all line ending characters to LF.
- If possible, how to preserve the LF so that it does not get changed into CRLF?
I think I find myself the answer at least some helpful information, i will just leave a record in case there are people seeking for the answer for similar questions.
- where and what causes this behavior?
For historical reasons, the element’s value is normalized in three different ways for three different purposes. The raw value is the value as it was originally set. It is not normalized. The API value is the value used in the value IDL attribute. It is normalized so that line breaks use U+000A LINE FEED (LF) characters. Finally, there is the value, as used in form submission and other processing models in this specification. It is normalized so that line breaks use U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pairs, and in addition, if necessary given the element’s wrap attribute, additional line breaks are inserted to wrap the text at the given width.
for more information please read:
https://www.w3.org/TR/html5/forms.html#the-textarea-element
- If possible, how to preserve the LF so that it does not get changed into CRLF?
I guess there are a lot of ways. Using javascript to replace all /r/n to /n before submit a form will likely be a client side solution. or if it doesn't have the necessity to be handled on client side which is exactly my case, I do the replacement process on the server side to force convert all line ending characters to LF.
- If possible, how to preserve the LF so that it does not get changed into CRLF?
answered Nov 23 '18 at 5:47
zaozaoer
7210
7210
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53298285%2fline-ending-charactor-lfs-are-automatically-changed-to-crlfs-in-html-textarea%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown