does using a long delimiter multiple times degenerate encryption security?

I need to condense multiple distinct pieces of data into a single encrypted string that can be decrypted and separated out later.

Before encrypting, I need to separate the data with some kind of delimiter that will never be confused with the data.

I have chosen to use a single, constant 20 character hexadecimal delimiter. For example:

data_piece
data_item
data_obj

becomes

data_piece214c1a16bb5236e7090cdata_item214c1a16bb5236e7090cdata_obj

which then becomes

vjXC4Xd7LU6aZX4QClZkU330XT39hnoLoQYIFNov39tPX96OKsid7mOBHwoVb4KspyvMpVPrsfHCUd1zbzXyETtgW5yF4b0oaK8Q%2FZCZN2XBvbfL3vooD%2FDLOza3%2FSrSNNzIW8oALZhv08LBzeg3DvgUgC8fg0xv4%2BCAEIQLIhM%3D

after running it through a standard Rijndael encryption algorithm with a 256 bit key and a url encoder.

Does this repetition of a single delimiter degenerate the security of the encryption if there are occasions when it may be used two dozen times? If so, should I use an array of unique delimiters so that they are never repeated within the same string, or does the difference really not matter for practical encryption purposes?

UPDATE:

The reason I chose to use a long delimiter instead of a small one is for cases like this:

delimiter = |
data1 = mydata\\\\
data2 = \|\|\|data

unescaped: mydata\\\\|\|\|\|data

escaped: mydata\\\\\\\\|\\\|\\\|\\\|data

writing code to unescape that and separate it out is not very straightforward. It is possible to do, but there will have to be a loop that continually looks for an end to sequence of escape characters preceding the delimiter, then unescapes it only if the number of escape characters in the sequence is odd.

Since this involves checks before every unescape function, I thought a long delimiter was better, because it can be practically guaranteed to never occur in the data, and allows the separation process to be as simple as possible.

SHORT ANSWER:

Yes. But the encryption (using AES-256) is still strong enough to withstand real world brute force attacks, so the added weakness is negligible.

This long delimiter technique can be improved by using a random delimiter for each string of condensed data.

However, using a long delimiter is not the best technique for any circumstance. A one character delimiter is sufficient and better for both security and memory usage. To mitigate the issue I described above, use the following procedure:

delimiter = |
data1 = mydata\\\\
data2 = \|\|\|data

encode data separately to remove delimiter character altogether
(ex. using php rawurlencode)
mydata%5C%5C
%5C%7C%5C%7C%5C%7Cdata

serialize the data
mydata%5C%5C|%5C%7C%5C%7C%5C%7Cdata

encrypt the serialization
8XcaEW2st4qBZhGB1MbO200eLbhhoOV3V4MCpa9k6ODiN6dcJypTWabq2YsUwBC2tnkKdaUOU7jviilahNQ2B+DRvtLMYDrFNp3qHh0oWMUAuAnjCcKuHfE9tIcd/Jhv

If you reverse that process, it is very straightforward to separate the data and get it back to its original form.

Notice that the final encrypted string is 30% shorter than the one that used the long delimiter.

See lserni's answer for more details and space saving methods.