<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>regexp &#8211; Karl Jepertinger IT Consulting</title>
	<atom:link href="https://www.jepertinger-itconsulting.de/tag/regexp/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.jepertinger-itconsulting.de</link>
	<description>Consultant as a Service!</description>
	<lastBuildDate>Thu, 12 Oct 2017 11:27:46 +0000</lastBuildDate>
	<language>de-DE</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.0.1</generator>
	<item>
		<title>Regular Expressions und Top Level Domains</title>
		<link>https://www.jepertinger-itconsulting.de/2017/10/04/regular-expressions-und-top-level-domains/</link>
		
		<dc:creator><![CDATA[Karl Jepertinger]]></dc:creator>
		<pubDate>Wed, 04 Oct 2017 19:20:00 +0000</pubDate>
				<category><![CDATA[Programmierung]]></category>
		<category><![CDATA[domain]]></category>
		<category><![CDATA[email]]></category>
		<category><![CDATA[länge]]></category>
		<category><![CDATA[prüfung]]></category>
		<category><![CDATA[regexp]]></category>
		<category><![CDATA[validierung]]></category>
		<guid isPermaLink="false">https://www.jepertinger-itconsulting.de/?p=766</guid>

					<description><![CDATA[Eine häufige Aufgabe in der Programmierung ist das suchen/validieren von Email-Adressen. Mal davon abgesehen, dass ein regulärer Ausdruck nur bedingt dazu benutzt werden kann, funktionieren filtern grobe Näherungen schon mal die meisten. Dies ist eine grobe Näherung wie sie in vielen &#8230; <a href="https://www.jepertinger-itconsulting.de/2017/10/04/regular-expressions-und-top-level-domains/">Weiterlesen <span class="meta-nav">&#8594;</span></a>]]></description>
										<content:encoded><![CDATA[<p>Eine häufige Aufgabe in der Programmierung ist das suchen/validieren von Email-Adressen. Mal davon abgesehen, dass ein regulärer Ausdruck nur <a href="http://www.regular-expressions.info/email.html" target="_blank" rel="noopener">bedingt </a>dazu benutzt werden kann, funktionieren filtern grobe Näherungen schon mal die meisten. <span id="more-766"></span>Dies ist eine grobe Näherung wie sie in vielen Programmen bereits hinterlegt ist. Auch im Internet finden sich noch oft Ausdrücke wie dieser (<a href="https://stackoverflow.com/questions/29392621/regex-to-extract-email" target="_blank" rel="noopener">Quelle</a>):</p>
<p><code><span class="pln">strPattern  </span><span class="pun">=</span> <span class="str">"^([a-zA-Z0-9_\-\.]+)@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$"</span></code></p>
<p>In diesem Blogpost geht es mir im besonderen um das Matching der Toplevel-Domain. Dabei ist vielfach noch hinterlegt, dass diese zwischen zwei und drei Buchstaben lang sein muss. Das gilt aber leider nur bei &#8222;country code top level domains&#8220;, die eben einem Land gehören. Generische Top Level Domains sind meist länger. Eine&#8220;.info&#8220;-Domain ist valide, würde aber von obigem Regex nicht gematcht.</p>
<p><code><span class="pln">strPattern  </span><span class="pun">=</span> <span class="str">"^([a-zA-Z0-9_\-\.]+)@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]<strong>{2,}</strong>)$"</span></code></p>
<p>Obiger Regex ist derweil immer noch nur eine Näherung an den IEEE-Standard, filtert aber längere Toplevel-Domains nicht mehr aus.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Oracle SQL String Split in mehrere Zeilen/Rows</title>
		<link>https://www.jepertinger-itconsulting.de/2017/05/25/oracle-sql-string-split-in-mehrere-zeilen-rows/</link>
		
		<dc:creator><![CDATA[Karl Jepertinger]]></dc:creator>
		<pubDate>Thu, 25 May 2017 16:31:56 +0000</pubDate>
				<category><![CDATA[Oracle]]></category>
		<category><![CDATA[regexp]]></category>
		<category><![CDATA[regular expression]]></category>
		<category><![CDATA[substr]]></category>
		<category><![CDATA[substring]]></category>
		<guid isPermaLink="false">http://www.jepertinger-itconsulting.de/?p=605</guid>

					<description><![CDATA[Auch mit dem besten Datenbankmodell gibt es Importe und Situationen in denen in einem Feld mehrer Werte durch Separatoren getrennt hinterlegt sind. Um diese Werte in Zeilen umzuwandeln gibt es genügend Varianten im Internet zu finden: z.b. auf Stackoverflow. Die &#8230; <a href="https://www.jepertinger-itconsulting.de/2017/05/25/oracle-sql-string-split-in-mehrere-zeilen-rows/">Weiterlesen <span class="meta-nav">&#8594;</span></a>]]></description>
										<content:encoded><![CDATA[<p>Auch mit dem besten Datenbankmodell gibt es Importe und Situationen in denen in einem Feld mehrer Werte durch Separatoren getrennt hinterlegt sind.</p>
<p>Um diese Werte in Zeilen umzuwandeln gibt es genügend Varianten im Internet zu finden: z.b. auf <a href="https://stackoverflow.com/questions/14328621/splitting-string-into-multiple-rows-in-oracle#27137629" target="_blank" rel="noopener noreferrer">Stackoverflow</a>. Die meisten Lösungen arbeiten dabei mit regulären Ausdrücken und der Funktion &#8222;regexp_substr&#8220;. Die gehen einfach von der Hand, wirken sich bei größeren Datenmengen, wie sie in einem Datawarehouse vorkommen, aber durchaus auf die Performance aus. Um nicht mit Kanonen auf Spatzen zu schießen, läßt sich das Splitten alternativ mit einfachen Stringfunktionen lösen.<span id="more-605"></span></p>
<p>Im folgenden Beispiel gilt es den String &#8222;12,22,3&#8220; in 12 &#8211; 22 &#8211; 3 zu teilen.</p>
<pre class="brush: sql; title: ; notranslate">
with input as
(
select '12,22,3' str from dual
)
select level, str,
trim(',' from substr(str, instr(str,',',1,level), instr(str,',',1,level+1)-instr(str,',',1,level)))
,instr(str,',',1,level), instr(str,',',1,level+1)
from input
connect by instr(str,',',1,level+1) != 0 ;
</pre>
<p>Um nun den Separator nicht noch mehrfach zu wiederholen, wäre es noch schön diesen in einem eigenen Block auszulagern. Das würde hier aber der Leserlichkeit schaden.</p>
<p>Reguläre Ausdrücke sind eine prima Sache, müssen aber mit Bedacht eingesetzt werden. Manch harmloser Ausdruck kann auch durchaus die Datenbank auf Anschlag belasten. Wenn möglich sind einfache, berechenbare Funktion vorzuziehen.</p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
